Is there a way to trigger workflow on Access Requests state changes to COMPLETED?

Looking to send email notifications upon the completion of Access Requests. There doesn’t seem to be an OOTB email template for this. So thinking I’ll need a trigger…but can’t seem to find a workflow trigger, nor under trigger subscription.

Can you use Provisioning Completed after Access Request is completed ?

Don’t want to fire the workflow on a per provisioning action…especially if the request has multiple access items on difference targets/sources. End users don’t need to be notified multiple times due to backend mechanics.

At the moment, the only ‘workaround’ (in the lack of a suitable trigger that I know of) is to handle this out of band, tracking current pending (i.e. EXECUTING) vs previously known pending access requests. If a request was previously known to exist, and is now not pending, then lookup it’s current status. If it’s COMPLETED, then send an email to the requestee.

But one would think there ought to be a better way to implement this.

I believe @David_Norris is correct that you would need to handle this as a work around.

Could you explain a little bit more about what type and how many emails you intend to send when it changes to COMPLETED? This would help other suggest better workwrounds, and also for SP Employees who might read it to understand.

I would also recommend seeing if there is an Idea on the Ideas board for this (I believe there is) and you can vote on it, or if there isn’t, you can create one and link it here so others can help vote it up.

The end goal is to notify requestees that requests regarding them have completed (whether they’re requests for themselves or requests on their behalf).

e.g. View this as “Your order is delivered” kind of messaging.

I would have expected this to be an OOTB / no-code configuration from a leading IGA solution. Like, supposed a 20+ years of IdM / IGA lesson learnt / best practices / UX use case is lost to product team for some reason.

The volume of emails isn’t as relevant. It’s the bundled experience expected from an overall Access Request use case. (It’s a fulfillment / delivery - It’s done, kind of thing) The notification, if we take a customer experience approach (instead of workforce approach), it should allow end-user to opt-in/out on a per user basis.

The " Notify users by email when an access request is complete" has been on the IDEAS portal since “Oct 6, 2022”…it’s going nowhere.

The lack of this notification to drive end-user activity on ISC (to actively look at request status) to skew usage interaction statistics doesn’t make it a better product as it introduces daily micro-friction to users.

Imagine if this was a “Get some milk” order from my wife. If I didn’t get the milk in time, I sleep on the couch. If I didn’t tell her there’s no milk at the shop, I sleep on the couch. If I got the milk, but didn’t tell her about it until she had to ask about it, I sleep on the couch. (“Don’t wait until I ask about it”) You get the idea. Someone else’s wife might be different…and that’s the point. Opt-in/out as needed.

Can you put together an Search in a workflow and iterate through the results, sending an email to the completed requests?

A search like this maybe to start:
action:“Access Request” AND stage:completed AND created:[now-1d TO now]

The issue would be that there is not enough info in the Search to do much with.
I would look at calling the request API’s from the workflow (HTTP Request) as well and see if that is an option.

Technically, you can…but, potentially two issues:

  1. Loop limitation in workflow.
  2. There’s assumption that the notification on the previous workflow execution completed successfully, no gap.

If you shorten that -1d to, say, last 5 minutes, you can potentially remediate the first concern (a workaround). But the 2nd point, you would need to check the workflow’s last successful execution time, and adjust your search span period accordingly.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.