I have a workflow using the Provisioning Completed trigger and I’m looking for a scalable way to minimize workflow executions.
My use case is:
If the user is provisioned to Source A with Entitlement A, assign User Levels A.
If the user is provisioned to Source A with Entitlement B, assign User Levels B.
If the user is provisioned to Source A with Entitlement C, assign User Levels C.
Currently, the workflow gets triggered for every provisioning event and I perform the checks later in the workflow using operators. While this works functionally, it increases workflow execution counts significantly.
I attempted to use trigger-level JSONPath filters based on:
Source
Entitlement
Provisioning Result
but the workflow still appears to trigger for unrelated events.
My questions are:
Is there a reliable JSONPath filter for the Provisioning Completed trigger that can evaluate both source and entitlement?
Are nested attributeRequests supported in trigger filters?
What is the recommended design pattern for handling multiple entitlement-specific actions?
Separate workflows per entitlement?
One workflow with trigger filters?
One workflow with a switch/decision tree after the trigger?
How are others reducing workflow execution counts for entitlement-based provisioning events?
I tried below filters but it didn’t work.
Filter 1:
$.accountRequests[?(@.source.name==‘Corporate Active Directory’ && @.attributeRequests[0].attributeValue==‘CN=EntitlementA,OU=Groups,DC=company,DC=com’)]
I ran into the same limitation in SailPoint ISC. Unfortunately, the Provisioning Completed trigger doesn’t reliably evaluate nested attributeRequests in JSONPath filters, so filtering by both source and entitlement usually doesn’t work as expected.
What has worked best for me is filtering only on the source (and provisioning result if needed), then handling the entitlement logic inside the workflow using a operators step. For example:
$.accountRequests[?(@.source.name=="Corporate Active Directory")]
It’s not as efficient as filtering directly on the entitlement, but with the current workflow engine, it’s the most reliable and maintainable approach. If anyone has found a supported way to filter on nested attributeRequests, I’d be interested to know as well.
Test the above two filters in your sandbox and then let me know the outcome.
Note: Do not copy and paste the filter above, as the workflow will fail validation. Copying changes the quotation mark formatting; instead, please type the double quotes manually when creating the filter.
Hello Amrit, The reason your filters aren’t working is because ISC’s JSONPath doesn’t reliably evaluate a [?()] filter when you nest it inside another [?()]. So when you put the attributeRequests filter inside the accountRequests filter, the entitlement part doesn’t get evaluated properly and the trigger fires for everything on that source.
The fix is to chain them instead of nesting. First filter accountRequests, then chain .attributeRequests[?()] as a separate step after it:
Using source.id instead of source.name is safer. Source names can be renamed, IDs don’t change.
@.operation == "Add" makes sure it only fires when entitlements are being added, not removed.
The in operator is supported in trigger filters since they use Jayway JSONPath, so you can list all three entitlement values in one filter.
The actual provisioningResult value in real payloads is committed (the official sample shows SUCCESS but that’s not what you’ll see in practice). For attributeName, pull one real payload from your workflow execution history and confirm whether it’s memberOf or something else in your environment.
For the design pattern, one workflow with this chained trigger filter is the cleanest approach. The filter controls whether it fires, then inside the workflow use a Compare or Choice step to figure out which entitlement was provisioned and assign the right User Level accordingly.
Is this filter can be only tested by real-time provisioning?
Can it be not tested with test workflow feature? I tried test workflow but this filter gets executed for all if condition met or not.
Yes, this is expected with Test Workflow. The trigger filter is evaluated when the workflow is enabled and ISC receives a real Provisioning Completed event. If the filter doesn’t match during real execution, the workflow won’t start.
But Test Workflow uses the test input you provide and runs the workflow steps directly, so it’s not a reliable way to confirm whether the trigger filter will block the workflow from starting. To properly test the trigger filter, either trigger an actual provisioning event or validate the filter expression separately using the JSONPath Evaluator or the Test Subscription Filter API.
Your Check Provisioning Status and Check Source steps inside the workflow are still good as a safety check. Keep those in place.
