Implementing A Request Response Type Trigger in Workflows

[benjaminoriold]

@colin_mckibben

A caveat of request response type triggers is that you can only have a single subscription at a time, while fire and forget triggers can have up to 50. Because of this limitation, you probably won’t want to apply a filter to the event trigger subscription, and instead do some if/else logic in your workflow to handle the different types of requests. Once your logic is in place, enable all the trigger subscription and both workflows to start managing your access requests!

This right here is the real problem, not the fact that we don’t have a built in Trigger action in workflows for this. If this isn’t fixed this will always be an issue. I’ve submitted an idea here https://ideas.sailpoint.com/ideas/GOV-I-3395 explaining my reasoning. But essentially without a “Fire and Forget” version of this trigger this whole guide doesn’t even really do much for us and I imagine many others who want to use this Trigger.

It is entirely unreasonable to expect us to handle ALL of our use cases for this trigger in a SINGLE workflow with a million if statements at the beginning. Not only would that be impossible and a nightmare to even try to upkeep, it’s just poor implementation practice for this kind of thing.