Hey all — hoping someone has run into this before I sink more time into it or wait on a support ticket.
Setup: IIQ 8.4p2
Web Services connector application (custom REST target, loosely SCIM-shaped but not fully RFC-conformant). Schema attribute groups is flagged Managed, Entitlement, Multi-Valued, type group. Backing target returns group membership as an array of objects like {"value":"6465","display":"Standard"} on GET — nothing unusual for a non-conformant SCIM implementation.
Symptom: First real access request through this app (single “Add Entitlement” for one group) provisions correctly — confirmed on the target app itself, and the Provisioning Transaction log shows committed all the way through. But the parent IdentityRequest never closes: it sits at completionStatus="Pending", executionStatus="Verifying" indefinitely.
Digging into the Identity cube via Debug, the Link’s groups attribute is stored as a raw stringified version of the target’s response object:
{"value":"6465","display":"Standard"}
instead of a flat scalar/list of IDs.
Running Group Aggregation + Account Aggregation cleans this up perfectly — Link shows a proper <List><String>6465</String></List>. But the moment Perform Identity Request Maintenance runs (with “Verify provisioning for requests?” enabled), it flips right back to the malformed Map-shaped string, and logs a Native Change Detection event for it — even though nothing changed on the target side.
What I’ve ruled out:
- No Before/After Rules on Get Object, Account Aggregation, or Add Entitlement doing this transformation
- No Customization Rule on the app
- Response Attribute Mapping on Get Object is a clean, direct passthrough (
groups → $.groups) - No persisted
IdentityEntitlementrow exists for this identity/app/attribute (queried directly via Debug) — so it’s not a stale cache being re-synced - Identity Refresh (with entitlement/exception refresh options on) successfully rebuilds everything clean; it’s specifically the maintenance task’s verification step that re-breaks it
This really looks like the verification logic in Perform Identity Request Maintenance does its own live connector fetch that bypasses the app’s configured Response Attribute Mapping, and writes the raw unmapped response straight onto the Link.
Questions for the group:
- Has anyone seen this specific pattern — verification corrupting a multi-valued Managed+Entitlement attribute on a WS connector?
- Anyone know if provisioning verification uses a different/internal fetch path than standard aggregation?
- Any known workarounds short of restructuring the schema (we need to keep this attribute multi-valued) or disabling verification (hard no in our SOX environment)?
I will be opening a support case as well, but curious if this is a known quirk of WS connectors + entitlement-type multi-valued attributes on 8.4p2 specifically, or something version-specific/patchable. Happy to share more of the XML if useful.
Thank You!
