Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.
Please consider addressing the following when creating your topic:
What have you tried?
We currently make of an ConnectorAfterModify to execute an powershell script stored on our IQService to perform specific actions towards the EXO mailbox and Entra ID account in case we Disable the account on our Entra ID / EXO source, as disable account sources action configured on our leaver/left lifecycle states.
This solution is working as desired, however, in some cases we have an emergency offboarding at which, in order to speed up things here, in the Active lifecycle state we directly disable the account on all applicable sources. In such a scenario, we do not want this powershell script to be executed. Based on https://developer.sailpoint.com/discuss/t/using-before-provision-rule-for-a-delete-operation/88951/9 I therefore attached to our EXO source:
At which I was now expecting that within the iqservice powershell script, in case of Disable account on active lifecycle state, you would get value Yes within $requestObject.Attributes.EmergencyOffboarding however $requestObject.Attributes is empty.
What errors did you face (share screenshots)?
None
Share the details of your efforts (code / search query, workflow json etc.)?
See above
What is the result you are getting and what were you expecting?
In case of Disable account on active lifecycle state, you would get value Yes within $requestObject.Attributes.EmergencyOffboarding as part of the IQService powershell script attached to the source via connector rule
You would have to filter in your AfterModify rule to check if LCS = Active.
In other words some filter to check if
operation = modify/disable
attribute = lcsAttr → active
== Do nothing.
(If i understand your case correctly)
You can do this either by provisioning LCS value to an attribute in AD/Entra (Maybe you do this already) and use this attribute to check against when AfterModify triggers.
You could also do the filtering on the server-side after the AfterModify script as executed to check if account is disabled natively (userAccountControl in AD or accountEnabled in Entra).
We don’t want to check if account is disabled natively. As part of emergency offboarding, our current working procedure is that from within identity security we directly disable the account on applicable sources, we don’t do this one within for example entra id directly.
What you’re seeing is expected in the sense that the IQService AccountRequest for Disable often arrives with an empty metadata map ($requestObject.Attributes) and no AttributeRequests, so there’s nothing in PowerShell to branch on. In other words, your AddArgument config isn’t being carried through into the IQService request for this operation.
The reliable way to solve this is to do the filtering in the ConnectorAfterModify rule itself (on the VA), before triggering any downstream PowerShell actions:
If Operation == Disableand identity cloudLifecycleState == active (your emergency offboarding path), then skip the script execution.
Otherwise run your current script as normal.
That way you don’t depend on $requestObject.Attributes being populated for Disable. SailPoint’s own guidance for these rules is to keep the rule logic minimal and use it to control whether you invoke the external script.
If you must branch inside PowerShell, the workaround is to provision a real “flag” attribute to the target (e.g., an extensionAttribute) as part of the emergency workflow and check for that in the IQService script — but the simplest/cleanest is the rule-side filter.
If you want you can send a snippet of your afterModify logic and we can take a look.
Thanks for your detailed response @Swegmann, excluding active lifecyclestate within our powershell invoke sounds like our desired fix, however, how do I retrieve the cloudLifecycleState within an ConnectorAfterModify rule?
I tried to modify it towards
## Do not call our modify script in case of our current lifecyclestate is active
$cls = $resultObject.Attributes.cloudLifecycleState
If ($cls -eq \"active\") {
# Do nothing
} Else {
$commandWithArgs = \"$command -requestString '$requestAsString'\"
Invoke-Expression $commandWithArgs
}
What you can try is to pass cloudLifecycleState into the request as an AccountRequest argument, then read it using request.getArguments().get("cloudLifecycleState") and skip the invoke when it’s Disable + active.
Something like this:
import sailpoint.object.Attributes;
Attributes args = request.getArguments();
String cls = null;
if (args != null) {
Object v = args.get("cloudLifecycleState");
if (v != null) cls = v.toString();
}
log.info("cloudLifecycleState from AccountRequest arguments = " + cls);
if ("active".equalsIgnoreCase(cls) && request.getOperation() != null
&& "Disable".equalsIgnoreCase(request.getOperation().toString())) {
log.info("Skipping IQService call: Disable + cloudLifecycleState=active");
return result; // do nothing; do NOT invoke powershell
}
// else proceed with your normal invoke logic...
String commandWithArgs = command + " -requestString '" + requestAsString + "'";
connector.common.Util.runCommand(commandWithArgs); // (or your existing invocation method)
return result;
Looking at our log file $env:request currently only exists of
Request as XML object is: <AccountRequest application="Entra ID / EXO ACC [source]" op="Disable" nativeIdentity="<guid>"> <ProvisioningResult status="committed" /> </AccountRequest>
I’m beginning to wonder if it might be difficult to go for the “Disable” operation itself as you get no attributeRequests.
An idea is to include something detectable, e.g.:
set an AD/Azure attribute like extensionAttribute15 = "EmergencyOffboarding" (or similar)
this creates a Modify request with <AttributeRequest> entries
then AfterModify can read those and decide whether to run the downstream script
This is the “provision a flag” approach (not necessarily LCS itself). It’s ugly, but it works. You would instead filter the afterModify powershell rule on a modification event rather than a disable operation.
Another idea would be to leverage Workflow + GraphAPI httpRequest to do your Emergency off-boarding, bypassing a “disable” event in ISC, but you would loose traceability in ISC.
Thanks a lot for your feedback @Swegmann , I’ve discussed this one internally and we decided to resolve this one by calling the search api of idsec within our exo script to fetch the desired lifecyclestate, we retrieve the clientsecret securely by getting the value from our password vault solution.
Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.