I thought so but was hopping I can control approval requirement in Requests as well.
Ok will wait for that
In theory, you could also autoapprove requests using a workflow action. But then you need to include wait steps in the workflow for the actual approval steps to be created and potentially factor in multi-approval steps.
All in all, I’d recommend going for the Access Certs approach as it is a single & simple auto-completing campaign. You can very easily use this campaign (whether empty or had some items) to demonstrate to auditors that your leaver process was triggered for each leaver and access has been revoked.
It’s a fair workaround (certification).
Thank u
נשלח מ- Outlook עבור Android
Hi @mostafa_helmy,
Thank you for providing the workflows. We are successfully using the simple Leaver workflow, and it functions as expected. However, we are encountering issues with the Leaver - ChildAccessRequests workflow.
While we do not see any explicit errors in the workflow, it is not revoking any of the entitlements assigned to the user. The result from the “Get Standalone Entitlements” step appears unusual—it seems to be an HTML response, which is unexpected. The query being used works perfectly fine in Postman, so we’re unsure what might be causing the issue.
For your reference, I’ve attached the rule execution output. Below is the request body we’re using for the “Get Standalone Entitlements” step:
{
“indices”: [“identities”],
“query”: {
“innerHit”: {
“query”: “source.name:"Active Directory" AND type:"ENTITLEMENT"”,
“type”: “access”
},
“query”: “id:"{{$.trigger.id}}"”
}
}
We would greatly appreciate any insights or assistance you can provide to help us troubleshoot and resolve this issue.
LeaverWorkflowChildAccessRequestsRemoveStandingAccessExecution20250120.csv (29.0 KB)
I can see the request URL you are using is missing the .api part.
Instead of https://<yourtenant>.identitynow.com/v3/search make sure you change it to https://<yourtenant>.api.identitynow.com/v3/search
Also I noticed you changed the entitlements search query itself to filter only AD entitlements, which is fine. Just make sure you also include the AND standalone:true otherwise it will return entitlements that are part of Roles/Access Profiles. Those cannot be removed this way, as they are handled by the next step in the workflow which removes the parent Roles/Access Profiles.
Oh, I see! Thank you for bringing that to my attention, and I really appreciate the quick response. I will correct it and test the workflow again.
You’re right, I hadn’t used standalone:true in the query. I’ll incorporate it as you suggested. However, our current plan is to revoke access after ‘X’ days, during which time all roles assigned as birthright or through assignment criteria should already be revoked during the identity refresh task when the user becomes inactive.
Essentially, by the time this workflow is triggered, there shouldn’t be any entitlements tied to roles or access profiles. That said, as a precautionary measure, I’ll make the adjustments you mentioned. Thanks again for the valuable insights!
LeaverWorkflowChildAccessCertificationsRemoveStandingAccessExecution20250204.csv (9.4 KB)
Hi @mostafa_helmy,
We are currently using the Master - Child Access Certification workflow to revoke access. The workflow has been running successfully for the past few days. However, I have noticed some failed executions, and all of them show the same error—updating the campaign deadline fails with the following error:
{"error":"task failed: activity error (type: sp:external:http:v2, scheduledEventID: 29, startedEventID: 30, identity: 1@sp-workflow-worker-stg-us-east-1-7ddbffdb9-2dmxq@sp-workflow-engine): request failed (type: HTTP Response Returned a Client Error, retryable: false): request failed: 400 - 400 Bad Request - {\"detailCode\":\"400.1.1 Illegal update attempt\",\"trackingId\":\"f706f8d80bd243d9935142668b676ca9\",\"messages\":[{\"locale\":\"und\",\"localeOrigin\":\"REQUEST\",\"text\":\"Illegal attempt to modify \\\"campaign\\\" field.\"},{\"locale\":\"en-US\",\"localeOrigin\":\"DEFAULT\",\"text\":\"Illegal attempt to modify \\\"campaign\\\" field.\"}],\"causes\":[]}"}"
I am not entirely sure what is causing this issue, as it only fails intermittently for certain users. When I run the API call via Postman to update the deadline with the same values as in the workflow execution output, I do not encounter this error.
I have also compared the workflow execution output between failed and successful executions. The API calls, headers, and request body all appear correct, and I don’t see any discrepancies that could be causing this.
Have you encountered this type of error before? If you could check the execution output and identify any potential issues, please let us know. PFA output for the failed execution.
Thanks in advance for your help!
Hi Mostafa,
I have used the Simple Implementation workflow to remove all the access of the inactive identity.But for some reason the entitlements are not removed at all. I have attached the execution details here.
And is it because these entitlements are not attached to any access profiles and are directly added from the AD level?
LeaverRemoveAllstandingaccessExecution20250207.csv (21.4 KB)
@Soundary I don’t see any errors in your workflow execution. It seems the certification campaign was correctly generated and closed. Were those entitlements captured as part of the campaign? Are there any provisioning errors from the connector?
@RohanBhat10 I also realized that I did not update the Child Workflow definition to include a fix that was provided in the SImple workflow ( added waits ). I will update the attached workflows later today.
Hi @mostafa_helmy,
Thanks for the updates. We have identified the root cause of the issue.
The problem seems to occur during the “Campaign Completed” check. Since all subsequent steps are triggered within few seconds of the “Create Campaign” step, the certification campaign might still be in an Activating or Completing state(If there are no access items for a user). Since these states are not checked by the “Campaign Completed” step, leading to a failure in the workflow.
This caused the “Update Deadline” step to throw an Illegal Modify Error, as per the API documentation, the deadline can only be updated when the certification is in Active or Staged status.
To address this, we have introduced a wait step after the “Create Campaign” step to ensure that the certification has fully processed all necessary data before proceeding.
Hi Mostafa,
I don’t see any provisioning errors. How do I understand if the entitlements were part of the campaign or not?
Hi @Soundary,
You can verify the certification campaign to check if there were any entitlements included. If no entitlements are present, it’s likely that the user didn’t have any access assigned and hence campaign didn’t have any entitlements to revoke.
Since we are not using any search query within the workflow, there wouldn’t be any errors related to query search failure during certification creation.
Additionally, you can confirm the user’s access by navigating to the Identity > Access tab to check if the user has any entitlements assigned.
Hope this helps you!
Hi Rohan,
Thank you for the input. I was able to resolve the issue
In the Get identity if there are more then 100 identities that are inactive then will the workflow take more then 100 users to the campaign?
The workflow is designed to trigger on an event basis and clean-up leaver access.
As of today, workflow loops have a maximum of 250 iterations. If you use the v1.1 workflow, the scheduled workflow will pick up the first 250 identities and process them. The next scheduled iteration will pickup the next 250 identities and so on.
If you expect thousands of leavers to have access (initial cleanup), I would recommend you trigger a one-time manual certification campaign using search query such as:
@access(revocable:true OR standalone:true) AND attributes.cloudLifecycleState:inactive
Once the campaign is active, simply complete it and choose any undecided items to be revoked.
As you would expect. Please verify that the above query works for you and returns the expected results before removing anyone’s access in production 
@all the workflow definitions have been updated to v1.1 which include all the minor fixes some customers have faced. Please make sure you are using the v1.1 workflows before trying to troubleshoot any problems you may have with older versions of these workflows.
Hi Mayur,
I am having the exact same issue in my workflow too! what was the resolution you built?
Is there a variant of this workflow where it doesn’t need to make REST calls via the HTTP Actions?
(Facing this issue, and opening the tenant to potentially other tenants in the region is not desirable)
I have successfully implemented the workflow which is leaver- remover all access. But I see on issue there in the campaign filters I see this issue. Which is “The account was deleted or changed before the campaign was completed”.
Is there any way to tackle this issue?
Regards,
Soundarya
Hi @mayurSuresh
I see a similar issues as yours. You mean you added search campaign after the create certificate campaign step? Or increased the wait time?
Has anyone faced issues with Okta group removal? The workflow does not attempt to revoke the okta group entitlement from the identity when the leaver - simple - remove all access workflow runs.
I tested it using roles. I manually added the user to a role with an okta group entitlement. The role successfully added the okta group entitlement. Then I removed the user from the role and the okta group entitlement was removed. So not a permission issue.
I also checked the okta logs. I don’t see anything attempting to remove a user from a group when the leaver - simple - remove all access workflow runs.
One thing to note: okta account aggregations and entitlements do take a bit long to run. Not sure if that is related.