Possible to update a workflow wait via API?

[dmcconnell_epsilon (David McConnell)]

Hi,

We have some access profiles that provide temporary elevated access that a user can request and a current workflow that will revoke the access profile after, say 30 days. This works as expected today.

I would like to be able to send the user a notification email 5 days before the ap is revoked. In that email, I would like a button that the user could click to extend the access another 30 days.

So, is it possible to reset the first wait in the workflow via an API call? Or, restart the workflow via API?

Thanks,
David

[LEOS (Leo Soulard)]

Hi David,

Could you, please, share in this case the workflow that revoke the access profile after X days ?

---

I’m thinking about a possible idea.

1. Store Elevated Access History

To store all elevated access given to identities, you can use a Delimited File source and create an account once any access is approved.

You can use this kind of account schema to store all information about the access request :

2. Access Request Decision

For each elevated access approved (Access Request Decision), you can build a workflow to create an account inside the Delimited File as a temporary account.

This account could be correlated or not, depending on your choice .

3. Extend Access Workflow

Build a schedule worflow to check each days all accounts in this source and compare the expirationDate stored in it.

If the expirationDate is equals to 5 days before, you can launch a form and send it to the manager for extending the due date.

Validation Steps:

• If the manager choose to extend, then make another access request with a new expirationDate
• If the manager choose to not extend, then delete the history account inside the Delimited File source

---

Of course, this idea needs to be developped and adapted to your main feature

I hope my post will help you

[baoussounda (Ousmane N'DIAYE)]

There is an Access Sunset Date Reminder email Access Sunset Date Reminder Email Template - SailPoint Identity Services that automatically sends a reminder to users 7 days before the scheduled sunset date.

However, in your case, it seems you didn’t use the ISC out-of-the-box sunset date mechanism for your temporary access, but rather a custom workflow. It would be helpful if you could share the logic behind this custom workflow.

I would suggest to build a parallel workflow based on the same logic as the access revocation workflow. However, instead of checking if the 30-day period has been reached, it should check if there are 5 days remaining. Instead of revoking access, it would send a notification email.

[dmcconnell_epsilon (David McConnell)]

Hi Leo,

Thanks for the suggestion, I’ll have to try to set this up in sandbox and see if we can make it work.

Here is the current workflow:

{
	"name": "Remove access to AWS test_role roles after 30 days",
	"description": "This workflow will remove access to AWS test_role roles after 30 days",
	"modified": "2025-07-10T14:47:28.710564675Z",
	"modifiedBy": {
		"type": "IDENTITY",
		"id": "xxxxx",
		"name": "xxxxx"
	},
	"definition": {
		"start": "Get Identity",
		"steps": {
			"End Step - Success": {
				"actionId": "sp:operator-success",
				"displayName": "",
				"type": "success"
			},
			"Get Access": {
				"actionId": "sp:access:get",
				"attributes": {
					"accessprofiles": true,
					"entitlements": false,
					"getAccessBy": "specificIdentity",
					"identityToReturn.$": "$.trigger.requestedFor.id",
					"roles": false
				},
				"description": "Get access profile",
				"displayName": "",
				"nextStep": "Manage Access",
				"type": "action",
				"versionNumber": 1
			},
			"Get Identity": {
				"actionId": "sp:get-identity",
				"attributes": {
					"id.$": "$.trigger.requestedFor.id"
				},
				"description": "Get the identity data for the identity that the access was requested for.",
				"displayName": "",
				"nextStep": "Wait",
				"type": "action",
				"versionNumber": 2
			},
			"Manage Access": {
				"actionId": "sp:access:manage",
				"attributes": {
					"comments": "Remove access due to timeout",
					"removeIdentity.$": "$.trigger.requestedFor.id",
					"requestType": "REVOKE_ACCESS",
					"requestedItems": {
						"id": "{{$.trigger.requestedItemsStatus[*].id}}",
						"name": "{{$.trigger.requestedItemsStatus[*].name}}",
						"type": "ACCESS_PROFILE"
					}
				},
				"description": "Remove access",
				"displayName": "",
				"nextStep": "End Step - Success",
				"type": "action",
				"versionNumber": 1
			},
			"Wait": {
				"actionId": "sp:sleep",
				"attributes": {
					"duration": "30d",
					"type": "waitFor"
				},
				"description": "Wait for 30 days",
				"displayName": "",
				"nextStep": "Get Access",
				"type": "action",
				"versionNumber": 1
			}
		}
	},
	"creator": {
		"type": "IDENTITY",
		"id": "xxxxx",
		"name": "xxxxx"
	},
	"trigger": {
		"type": "EVENT",
		"attributes": {
			"filter.$": "$.requestedItemsStatus[?(@.name contains 'test_role - Temporary' && @.operation=='Add')]",
			"id": "idn:access-request-post-approval"
		}
	}
}

Thanks!

[dmcconnell_epsilon (David McConnell)]

Hi Ousmane,

I’ll have a look at the Sunset date reminder. I think the issue with this might be that the access technically doesn’t expire unless the workflow revokes it. I assume in this case, there may not actually be a ScheduledSunsateDate.

Thanks!