Please share any images or screenshots, if relevant.
NA
Please share any other relevant files that may be required (for example, logs).
NA
Share all details about your problem, including any error messages you may have received.
Hi All,
I wanted to discuss the following scenario:
Roles containing Logiplex Entitlement and Master Application do not have a Logiplex Provisioning Rule entry.
After performing an Identity Refresh with the Role Related option, the Account Request in the provisioning plan shows a “Create” operation—even though it’s a Logiplex application and the Master application already has the user account. As a result, Role Provisioning fails.
However, in the case of a request via LCM Workflow, the Account Request correctly shows a “Modify” operation, and the entitlement is provisioned successfully.
Interestingly, if we add the LogiplexProvisioningRule in the Master application, then after the refresh workflow, the Account Request shows “Modify”, which is the expected behavior. According to the Logiplex documentation, if no rule is specified, the connector should handle the operation by default.
I wanted to check if anyone else has observed this behavior. If yes, could you share the reason behind it?
@harsh_gupta4 During role provisioning, IIQ does not trust the connector to infer Create vs Modify unless a provisioning rule explicitly tells it how. So:
Without a provisioning rule → IIQ defaults to Create
With a rule → IIQ allows Modify
LCM bypasses this limitation by resolving the account earlier
Why this happens -
Role provisioning ≠ LCM provisioning
Although both end up calling provisioning, the plan is built differently:
LCM workflow
IIQ explicitly:
Resolves the existing account link
Knows the account already exists
Builds a Modify AccountRequest
LogiPlex connector gets a clean, well-formed request
Everything works as expected
Identity Refresh with Role-related option-
IIQ uses role delta evaluation
It does not re-run full account correlation logic
The provisioning plan is built using:
Role → Application → Entitlement mapping
Limited awareness of existing accounts unless explicitly instructed
At this stage, IIQ does not know how to decide between Create vs Modify?”
**************
Why the missing LogiplexProvisioningRule matters
For LogiPlex:
The connector can handle Create vs Modify automatically
BUT during role provisioning, IIQ does not defer that decision to the connector
Instead, IIQ expects the Application-level provisioning rule to:
Detect existing accounts
Override the operation type if needed
So when:
No LogiplexProvisioningRule exists → IIQ assumes Create
Rule exists (even on the Master application) → Rule detects the account → switches to Modify
This is why adding the rule to the Master app “magically” fixes it.
***************
The documentation says the connector should handle it by default…” That statement is true—but only in certain flows.
Applies to:
LCM
Direct provisioning
Explicit account requests
Does not fully apply to:
Role-based provisioning during Identity Refresh
Any flow where IIQ pre-determines the operation type
In role provisioning, IIQ decides first, connector executes later.
LCM workflow