Webservice SaaS – Bypass GetObject During Account Disablement

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

You are right that there’s no $account.email$ or similar placeholder that reads from ISC’s cached account data. The documented keywords only resolve values from the provisioning plan, previous endpoint responses, source configuration, or the getobject identity. Your Before Operation Customizer testing lines up with this too, since it only receives the application config and current request endpoint, not the cached account object.

I have seen the workaround that might solve this without needing a custom connector, though. You can inject the email into the provisioning plan through a Disable provisioning policy with a dummy field name. If the field name matches an existing account attribute, ISC filters it out because the value already exists on the account. Using a name that doesn’t match any account attribute avoids this. How to add extra attributes to the provisioning plan of the Disable account operation walks through this exact problem, and Web Services rule to reference account attribute not in provisioning plan confirms the same pattern.

{
  "name": "Disable Account",
  "usageType": "DISABLE",
  "fields": [
    {
      "name": "emailLookup",
      "transform": {
        "type": "identityAttribute",
        "attributes": { "name": "email" }
      },
      "isRequired": false,
      "type": "string",
      "isMultiValued": false
    }
  ]
}

Then instead of a standalone Get Object, you could try the two-endpoint Disable pattern where both endpoints are Disable Account type, so $plan.*$ should be available in both:

  • Disable Account -1: calls your search/list API with $plan.emailLookup$ as the email filter
  • Disable Account -2: uses $response.*$ from endpoint 1 to do the actual disable

This sidesteps the standalone Get Object requirement entirely. The workaround was confirmed on the VA-based connector. Provisioning policies are platform-level so the behavior should be the same on SaaS, but I’d test in non-prod first.

If it doesn’t work, the custom connector route is still viable, but StdAccountDisableInput also only contains the account key/identity, not cached attributes. So a custom connector would still need its own way to resolve UUID-to-email.