Webservice Connector - During Rehire account is trying to create

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hi everyone,

We have a one of the downstream application with Webservice connector in ISC is trying to create the new account instead of correlation with the existing account during Rehire.

Error is like ID is already present with provided details in disabled state, enable Associate to use.

Do we need correlation rule for this or we need afterOperation rule to stop creation ?

2

Hey Sai,

Make sure the existing (disabled) account on the Web Services source is correlated to the identity before the rehire provisioning runs, and that the source supports an Enable Account operation.

If the account is linked, ISC will send Enable, not Create. Use a Correlation (match) rule or simple attribute mapping only if you can’t express correlation with the UI criteria. An After Operation rule can’t prevent creation (it runs after the call), but it can catch the “already exists/disabled” response and trigger an Enable as a fallback. If you want to stop the create before it happens, use a Before Provisioning cloud rule.

Questions for you:

  1. Which attribute(s) are you using for correlation today?
  2. Does your aggregation include disabled accounts on that Web Services source?
  3. Do you already have an Enable Account operation configured and working on the connector?

Answers to your questions:

  1. Do you need a correlation rule? - Only if the UI correlation options are not sufficient,
  2. Do you need an after operation rule? - Not strictly, If you want to prevent the create call altogether, use a Before Provisioning rule; if you want an automatic recovery, use an After Operation rule to trigger Enable on the target when the create fails with “already exists.”
3

Hi @saikumarS ,

To handle rehires and avoid creating duplicate accounts, you should implement a custom correlation rule that:

  1. Searches for the existing disabled account by your unique attribute (e.g., employeeID).

  2. Re-enables the existing Link instead of letting SailPoint create a new one.

Here’s a snippet you can start with (replace attribute names and connector name as needed):

SailPointContext context = sailpointContext
String incomingID = attributeContext.getAttribute("employeeID")
List<Identity> matches = context.getObjects(Identity.class,
    "employeeID == \"" + incomingID + "\"")
if (!matches.isEmpty()) {
    Identity existing = matches.get(0)
    Link link = existing.getLink(attributeContext.getApplication().getName())
    if (link && link.getStatus() == Link.DISABLED) {
        link.setStatus(Link.ENABLED)
        context.saveObject(link)
        return link
    }
}
return null

Attach this rule to your WebService connector under Correlation Rule, and SailPoint will re-enable the disabled account on rehire.

Using a correlation rule is preferable to an afterOperation rule because it prevents duplicate creation altogether.

Hope this helps!

4

Hey Sai,

Thanks for the message with additional information. What I understand:

  • Downstream app uses web services connector to ISC
  • During rehire, the account still exists in target system (disabled), but ISC tries to create a new account instead of correlating the existing one
  • The error message from the target confirms this: “ID is already present with provided details in disabled state, enable Associate to use.”
  • You had a filter in the source config: “Account Enable Status Attribute = Enabled=true” (meaning disabled accounts were excluded from aggregation, so ISC never “saw” them)
  • After removing the filter and aggregating, the count didn’t change (likely because the aggregation was optimized (delta)) - previously skipped accounts weren’t reprocessed.

Next steps for you:

  1. Ensure the filter is removed or adjusted
    1. If you want ISC to manage disabled accounts, remove the “Enabled=true” filter or change it to include both enabled and disabled states
  2. Run a full aggregation with optimizations disabled (I do this with vscode, you can do it via API or UI as well)
    1. This forces ISC to pull in all accounts, including previously filtered ones.
  3. Check correlation
    1. If the account shows as uncorrelated, check your correlation mapping: (e.g., identityAttribute = uid ←→ accountAttribute = userId)
    2. If the mapping isn’t enough (e.g., you need to check multiple attributes), create a Correlation Rule
  4. Test Rehire
    1. After full aggregation and correlation, reassign the access
    2. ISC should now link the existing account instead of creating a new one
5

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.