Hi all,
We have loopback connector configured in the IIQ environment.
When we set the inactive attribute to true for an identity, the SailPoint app link does not go to disabled state immediately even after a refresh on the identity, but goes to disabled state after sometime
Is there a reason/some other task that makes this switch to disabled state?
Thanks in advance
@rishavghoshacc I think you need to run Account Aggregation for loopback accounts to be updated. are you doing that?
hi @rishavghoshacc Yes, this is expected behavior.
In IIQ, setting inactive=true doesn’t disable the application link right away. An Identity Refresh mainly updates identity data the actual disablement happens when lifecycle or provisioning logic runs (like LCM workflows or disable‑account tasks).
With the Loopback connector, this often shows up as a delay because the link state only changes once that provisioning evaluation kicks in.
If you need the link disabled immediately, you will need to trigger the Manage Accounts → Disable Account (QuickLink) or Invoke the LCM Disable workflow programmatically (via workflow launch or rule)., not just an Identity Refresh.
how is the inactive status being checked with the account attribute in the Loopback connector?
This is expected behavior with the Loopback connector in IIQ. Setting “inactive=true” updates the account attribute, but the application link may not show as disabled immediately. In most cases, the link state updates after Account Aggregation, Identity Refresh, or when a provisioning/lifecycle workflow processes that change. If you need it disabled right away, try triggering a Disable Account action from Manage Accounts, and also check whether any lifecycle workflow is configured to handle the inactive flag.
@rishavghoshacc - The delay you observe is due to the need for a separate process typically an Account Aggregation or a specific LCM workflow to translate the identitys inactive=true status into the account link’s IIQDisabled=true status. The immediate refresh on the identity only updates the identity object, not necessarily the linked application account’s status.
Regards,
Kannan
The delayed disabled status on the SailPoint Loopback application Link is expected because setting inactive=true on the Identity updates the Identity Cube, but it does not immediately update the application Link status. The Link disabled state is usually updated only after the Loopback application is aggregated again. During that aggregation, the Loopback connector reads the Identity data, detects that the identity is inactive, and maps that condition to the account-disabled indicator, typically IIQDisabled=true, which then causes the SailPoint application Link to show as disabled.
An Identity Refresh may recalculate the Identity Cube, but it does not necessarily re-read or update the Loopback account Link. That is why the Identity may show inactive immediately, while the SailPoint app Link changes to disabled later when a scheduled Loopback Account Aggregation or a Sequential Task containing aggregation runs. So the task most likely responsible for the delayed switch is the Loopback Account Aggregation task, possibly followed by Identity Refresh.
@rishavghoshacc If you query is resolved, please consider marking your post as resolved. In case you figured out a workaround other than mentioned in the post, please do share it for everyone reference. This’ll help fellow sailors facing the similar issues.