I’m using the ‘Identity Attributes Changed’ trigger for a workflow, but I want to limit the workflow triggers to only those identities that have a specific identity attribute with a value.
I see that $.trigger.identity is one possible variable to use, but it does not contain the attributes object under it, if I’m not wrong. Is there a way I can avoid the workflow from executing for all users that do not have a particular identity attribute?
Note that there’s a workaround available where we can do a compare string operation after the trigger starts the workflow to check for an identity attribute, but I’m looking to restrict the execution itself.
In order to help you understand JSONPath, I recommend learning more about it here. You can also get a dump of all the data you have the ability to transverse by doing a ‘Test Workflow’.
I have reviewed the documentation, but my question was more around whether it is possible to still use the attributes object if it is not present in the JSON:
It doesn’t look like I can reference any identity attributes (like cloudLifecycleState, or say a custom one like employeeType). Wanted to confirm if my understanding is correct.
The “Identity Attributes Changed” trigger will only contain the attributes that have changed, not the full list of attributes. Therefore, you can only filter events based on attributes that have changed, and not on any arbitrary attribute that the identity may have.
You will have to take the approach that @bostelmann suggested and use the “Get Identity” action after your receive the event to lookup the full attribute list of the identity and then do a compare strings operator to decide what to do from there.
@bostelmann@colin_mckibben Yup exactly, we can do this AFTER the workflow has triggered.
Looks like we cannot get any other attributes apart from the ones that changed in the input to the trigger at the moment: I was looking to limit the triggers from triggering right at the source with JSON based filters, but that’s not a huge problem.
You can create a custom attribute specifically for triggering the workflow. Like if you want to trigger the workflow if the “future_term_date” has changed only for users in the IT department, then concatenate the “future_term_date” and “department” together into a single Identity Attribute and look for that attribute to change.
Absolutely @KevinHarrington, that definitely works as well! Good idea. I’m trying to think about how this scales.
While this might be a pretty useful workaround if we have a one-off requirement, imagine creating a ton of such concatenated identity attributes that you might want to use in other workflows: We might end up cluttering the identity details tab (unless we can hide them). You can also just designate one identity attribute to have all the possible concatenations done, but then that would affect readability and might need special callouts in documentation of the IAM solution.
