# Mandatory Sunset Date

**URL:** <https://developer.sailpoint.com/discuss/t/mandatory-sunset-date/87333>\
**Category:** SHF Community Knowledge Base\
**Tags:** access-requests, workflows, event-triggers, sailpoint-identity-security\
**Created:** [October 29, 2024, 5:07pm UTC](https://developer.sailpoint.com/discuss/t/mandatory-sunset-date/87333 "2024-10-29T17:07:49Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![zeel\_sinojia](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/zeel_sinojia/32/13666_2.png) [@zeel\_sinojia](https://developer.sailpoint.com/discuss/u/zeel_sinojia)\
**Post date:** [October 29, 2024, 5:07pm UTC](https://developer.sailpoint.com/discuss/t/mandatory-sunset-date/87333/1 "2024-10-29T17:07:49Z")

</div>

Hello Everyone,

I recently had a requirement from a client to make the access request sunset date mandatory. As there is no OOTB solution for this, I created a custom workflow to achieve it.

I see an idea was submitted for this functionality, which is marked under Future Consideration, [GOV-I-1764](https://ideas.sailpoint.com/ideas/GOV-I-1764) so I believe this should be a lot more helpful for the folks looking to make the sunset date mandatory.

# Workflow file

I have attached the workflow JSON file, you could use this file as a template and customize it further as needed.  
[MandatorySunsetDateWorkflow.json](https://developer.sailpoint.com/discuss/uploads/short-url/xlIaCBEMvCkz7S9FI8DJ9cIK3Ry.json) (6.5 KB)

# Prerequisite

For a basic Access Request Submitted Trigger, please check out this post [implementing-a-request-response-type-trigger-in-workflows](https://developer.sailpoint.com/discuss/t/implementing-a-request-response-type-trigger-in-workflows/10216) by @colin_mckibben and Access Request Submitted trigger.

> **[Access Request Submitted | SailPoint Developer Community](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/access-request-submitted/)**
>
> Fires after an access request is submitted.

# Mandatory Sunset Date Workflow

 ![MandatorySunsetDate](https://global.discourse-cdn.com/sailpoint/original/3X/9/c/9cf9800855a2fac6d8379ad88d105437607f0377.png)

Building on Colin’s workflow, I added an additional API call to [list-access-request-status | SailPoint Developer Community](https://developer.sailpoint.com/docs/api/v2024/list-access-request-status/) ( Get Access Request ) which fetches the status of all the access requests.

This [list-access-request-status | SailPoint Developer Community](https://developer.sailpoint.com/docs/api/v2024/list-access-request-status/) API call is necessary because the trigger input doesn’t provide the sunset/expiration date.

The API does not allow filtering to retrieve only the access request with the specific `accessRequestId` provided by the trigger. Therefore, I used JSONPath filtering and filtered the JSON response with the expression:

```auto
$.hTTPRequest1.body.[?(@.accessRequestId == $.trigger.accessRequestId)].removeDate

```

This returns the sunset date (attribute name is _removeDate_) from the API call. We use this approach instead of sorting the response to pick the latest request, as it better support handling multiple access items.

**Note:** _I have used this API with the parameters `?count=true&limit=5&sorters=-created`. This will give me the 5 latest access request object from this API. You may adjust this number as per your requirement._

 ![image](https://global.discourse-cdn.com/sailpoint/original/3X/9/f/9f91812f48e34b3dd7ca3b7cdc1dc1aec3e8b13d.png)

After retrieving the `removeDate` value, use the **Verify Data** operator to check whether the value is null. If the value is null, it means the requested access item doesn’t have any sunset date and the request can be Denied.

```auto
{
    "output": {
        "approved": false,
        "approver": "Workflow",
        "comment": "Sunset or Expiration Date is mandatory. Please submit a new request with a sunset date."
    },
    "secret": "{{$.trigger._metadata.secret}}"
}

```

Otherwise, approve the request, and it will proceed through the configured access request approval hierarchy.

```auto
{
    "output": {
        "approved": true,
        "approver": "Workflow",
        "comment": "This access has passed workflow approval."
    },
    "secret": "{{$.trigger._metadata.secret}}"
}

```

If the request is denied, this will send an email to the requestor informing them about the denial of request and the reason.

**Get Identity Action**

 ![{7BE9A5D0-69ED-4AF3-A1FD-5EC99E63220B}](https://global.discourse-cdn.com/sailpoint/original/3X/b/a/bad02fc5906ecd53915f8857bea8dc023714722a.png)

**Send Email Action**

 ![{FF8F383D-2BF1-4C50-81E8-07A2CB581133}](https://global.discourse-cdn.com/sailpoint/original/3X/1/1/110c4ffc98c5c078d75dacf8d9fd473711cc338b.png) ![{3CFB88E4-C579-41DA-9535-AFA6D6F25DDD}](https://global.discourse-cdn.com/sailpoint/original/3X/b/f/bf16947e2136efc94bd3879fe8ff93b35f8ab1bd.png)

That’s it, now you have a workflow that will deny any access request submitted without a sunset date and inform the requestor of the same. You can modify comments and adjust the workflow logic according to your requirements.

I’ve attached the Workflow JSON file, which you could use to implement this solution. Let me know if you have any more questions.

Hope this helps!  
Thanks!

---

<div class="post-metadata">

**Author:** ![RandomUser4096](https://avatars.discourse-cdn.com/v4/letter/r/2acd7d/32.png) [@RandomUser4096](https://developer.sailpoint.com/discuss/u/RandomUser4096)\
**Post date:** [October 31, 2024, 7:05pm UTC](https://developer.sailpoint.com/discuss/t/mandatory-sunset-date/87333/2 "2024-10-31T19:05:23Z")

</div>

As much as it ‘works’ and forces a Sunset Date to become mandatory…after the fact, this is terrible UX for the requester. There ought to be native OOTB configuration (as opposed to per tenant development) for this. Product gap?

---

<div class="post-metadata">

**Author:** ![248048](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/248048/32/18898_2.png) [@248048](https://developer.sailpoint.com/discuss/u/248048)\
**Post date:** [November 3, 2024, 8:41pm UTC](https://developer.sailpoint.com/discuss/t/mandatory-sunset-date/87333/3 "2024-11-03T20:41:34Z")

</div>

Thanks you soo much Zeel. Great learning.

---

<div class="post-metadata">

**Author:** ![zeel\_sinojia](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/zeel_sinojia/32/13666_2.png) [@zeel\_sinojia](https://developer.sailpoint.com/discuss/u/zeel_sinojia)\
**Post date:** [November 4, 2024, 4:40am UTC](https://developer.sailpoint.com/discuss/t/mandatory-sunset-date/87333/4 "2024-11-04T04:40:29Z")

</div>

I agree the UX is terrible and this ought to be an OOTB solution. However, till they decide to provide us with an OOTB solution (which I don’t see happening in the near future), this feels like a good workaround.

I feel that the workflow can be modified to set a default sunset date instead of rejecting the access request to improve the UX a bit.

---

<div class="post-metadata">

**Author:** ![dpennington](https://avatars.discourse-cdn.com/v4/letter/d/b5ac83/32.png) [@dpennington](https://developer.sailpoint.com/discuss/u/dpennington)\
**Post date:** [November 8, 2024, 4:13pm UTC](https://developer.sailpoint.com/discuss/t/mandatory-sunset-date/87333/5 "2024-11-08T16:13:08Z")

</div>

Thanks for this - very helpful and worked like a charm. Agree, this is a workaround until they provide an OOTB solution, but this helps in the meantime.

---

<div class="post-metadata">

**Author:** ![TheOneAMSheriff](https://avatars.discourse-cdn.com/v4/letter/t/ee59a6/32.png) [@TheOneAMSheriff](https://developer.sailpoint.com/discuss/u/TheOneAMSheriff)\
**Post date:** [November 8, 2024, 8:12pm UTC](https://developer.sailpoint.com/discuss/t/mandatory-sunset-date/87333/6 "2024-11-08T20:12:21Z")

</div>

Decent workaround until the the feature finally gets implemented OOTB. A static time period might not be preferred from a security perspective/granting access to users to the least amount of time required, as I understand that’s why the decision was to deny the request without an expiry date in the workflow.

---

<div class="post-metadata">

**Author:** ![zeel\_sinojia](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/zeel_sinojia/32/13666_2.png) [@zeel\_sinojia](https://developer.sailpoint.com/discuss/u/zeel_sinojia)\
**Post date:** [November 9, 2024, 6:04am UTC](https://developer.sailpoint.com/discuss/t/mandatory-sunset-date/87333/7 "2024-11-09T06:04:16Z")

</div>

Yes that’s correct. The workflow will deny the access request. This is NOT a good UX. But, I see it as the only way 🙂 to make sure every access request has sunset date associated with it.

---

<div class="post-metadata">

**Author:** ![Firmman-Alexander](https://avatars.discourse-cdn.com/v4/letter/f/ee7513/32.png) [@Firmman-Alexander](https://developer.sailpoint.com/discuss/u/Firmman-Alexander)\
**Post date:** [November 20, 2024, 9:42pm UTC](https://developer.sailpoint.com/discuss/t/mandatory-sunset-date/87333/8 "2024-11-20T21:42:35Z")

</div>

@zeel_sinojia this is great! Will be testing this in my tenant soon

I would like to modify this workflow to only perform this “sunset date check” on certain access items. How best could you suggest modifying this to perform that use-case? Perhaps filtering at the Access Request Submitted external trigger step? Thanks again for this workflow as it is

edit: meant to add that I looked at the v4/access-request-status endpoint you used, but I can’t seem to figure out if you can only filter out identities and accountactivityid’s