ISC Workflow - Grant access only until a fixed expiryDate after delayed approval

SailPoint Human Fabric (SHF) SHF Discussion and Questions
, ,
1

I’m building an access workflow in SailPoint ISC and have a requirement where the access duration should be based on the remaining time until a predefined expiry date, not a fixed duration from the time the role is granted.

Example

The external trigger sends the following payload:

{

  "identity": "john.doe",
  "roleID": "cb4f5634cc7d488b8a4528c4b9e92957",
  "startDate": "2026-06-19T10:30:00Z",
  "expiryDate": "2026-06-19T11:30:00Z",
  "expiry": "1h"
}

The workflow raises an approval. The problem is that the approval may not be completed immediately.

For example:

  • Request submitted: 10:30

  • Approval completed: 11:00

  • Expiry date: 11:30

In this case, I want the role to be assigned for only the remaining 30 minutes, not for the original 1 hour.

Currently, sp:access:manage only accepts a fixed removeDuration, for example:

"removeDuration.$": "$.trigger.expiry"

My questions

  1. Is there any supported way in ISC Workflow to calculate:

    expiryDate - current time

    and use the result as removeDuration?

  2. Although JSONPath provides $.now(), I couldn’t find any built-in function for date/time arithmetic. Is there an ISC-supported approach for this?

  3. Has anyone implemented this requirement without using an external API?

  4. Is the recommended approach instead to:

    • Wait until startDate

    • Grant the role without removeDuration

    • Wait until expiryDate

    • Revoke the role using another sp:access:manage action

I’d appreciate any guidance or examples from anyone who has implemented JIT access with approval delays.

2

Hi @RadhikaM

The recommended approach would be to grant the role after approval without a removeDuration, then use a Wait Until step based on the expiryDate and perform a second sp:access:manage action to revoke the role. This ensures the access expires at the intended absolute time regardless of approval delays.

3

What if the expiry date gap is 4 to 5 days? Each trigger of the workflow will run for 4-5 days. Is that a good idea?

4

That’s a good point. For expiry periods of 4–5 days, each workflow instance would remain active until the access is revoked.

5

This is not a recommended practice to keep the workflow waiting for 5 days

6

That’s correct. If possible, you can try rerouting it with a scheduled trigger. Otherwise, this will be the only option.

7

Hello Radhika,
Did you happen to look at the Submit Access Request API? It supports a removeDate field which takes an absolute UTC timestamp.

image
image1530×834 113 KB

So, ISC removes the access at that fixed time regardless of when the approval actually completes.

Instead of the Manage Access action, try using an HTTP Request step after approval and call POST /v3/access-requests with your trigger’s expiryDate directly as removeDate:

{
  "requestedFor": ["<identityId>"],
  "requestType": "GRANT_ACCESS",
  "requestedItems": [
    {
      "id": "{{$.trigger.roleID}}",
      "type": "ROLE",
      "removeDate": "{{$.trigger.expiryDate}}"
    }
  ]
}

That way you don’t need to calculate expiryDate - now at all. ISC handles the sunset on its own at that exact time. No duration math, no long running Wait steps, no second revoke call.

I would suggest to add a Compare Dates check after approval to make sure expiryDate is still in the future before firing the request. If the approver took too long and the window already passed, the API will reject it since removeDate needs to be a future timestamp. Better to catch that early and notify the requester than let it fail silently.