ISC: Enforcing Mandatory End Dates & Validating Access Requests via Role Metadata (with Auto-Cancellation)

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

Hi everyone,

I have a few questions regarding Role configuration, access request validation, and lifecycle controls in SailPoint Identity Security Cloud (ISC).

We want to enforce strict governance over certain sensitive roles so that users cannot retain access indefinitely and requests meet specific compliance prerequisites. Specifically, I would like to confirm the following points:

  1. Mandatory End Date (Expiration) for Roles
    Role Definition / Configuration: When creating or configuring a Role in ISC, is there an out-of-the-box setting or policy to make specifying an End Date mandatory (or enforce a maximum expiration/sunset duration)?

image
image2258×734 114 KB

Request Center Behavior: If an end date can be enforced, does the Request Center require the user to pick an end date before submitting the access request?

  1. Access Request Validation Based on Role Metadata & Auto-Cancellation
    Role Metadata Validation: We have custom metadata (or specific attributes) defined on our Roles. Is there a native feature or recommended approach to validate access requests against these Role metadata values during the request process?

Automatic Cancellation / Rejection: If the validation criteria are not met (for example, the requester/target identity does not satisfy the conditions dictated by the role’s metadata), can the request be automatically cancelled or rejected before approval/provisioning?

  1. Recommended Architecture / Best Practice
    If either of these requirements is not supported natively in the standard Role configuration or Access Request UI:

Would utilizing ISC Forms attached to an Access Request be the right approach to capture and validate these inputs?

Regarding ISC Workflows:

We considered using the Access Request Submitted trigger to validate requests. However, this seems impractical/limited for our use case because having to configure and maintain workflow logic for each individual role every time a role is created is not scalable.

Is there a more centralized or scalable way to handle this validation and auto-cancellation (via Forms, centralized Workflow logic, or API policies)?

Any guidance, recommended patterns, or references to relevant documentation would be greatly appreciated.

Thank you in advance!

2

Hello Jin. I would suggest handling the end-date requirement natively and using centralized validation only where custom role metadata is involved.

1. Mandatory End Date and Maximum Duration: Go to Admin > Access Model > Roles > Edit > Access Requests. Enable Require End Date and optionally configure a maximum duration. Request Center enforces the end date before submission, and ISC initiates revocation when it expires. No custom form or workflow is needed for this.

A few things to consider:

  • Existing assignments and automatically assigned roles are not covered.
  • Settings apply per access item, not automatically to underlying entitlements requested separately.
  • For API/workflow requests missing an end date, ISC applies the maximum duration if configured. Otherwise, set fallbackAccessDurationInDays in access-request-config when an end date is required.

2. Role Metadata Validation and Auto-Denial: If you are using Access Model Metadata, I would first check Access Request Policies in Policy Center. Policies support automatic denial, approval, and adaptive workflow routing. However, I could not confirm whether custom role metadata is available as a policy match criterion, so I would verify that first. Also, policies exclude bundled provisioning, dynamic role requests, ServiceNow plugin requests, and revocations. Global approvals must be enabled, and the latest Access Request UI currently requires opting in.

3. Centralized Validation Without Per-Role Workflows: If policies cannot handle your metadata conditions, you could use one external subscriber for the Access Request Submitted REQUEST_RESPONSE event.

The subscriber would:

  1. Read requestedItems and requestedFor.
  2. Retrieve the role using GET /roles/v1/{id} and read its accessModelMetadata.
  3. Compare the metadata with the target identity attributes.
  4. Return approved: false with comment and approver when validation fails, or approved: true to continue normal approvals.

This keeps the validation centralized. Only one subscriber is supported, so I would also check whether one already exists. Since the response is request-level, test how requests containing multiple items behave. If an Access Request Decision subscription is also active, approver must be an existing identity’s username.

Alternatively, you can associate one reusable Adaptive Approval Workflow with multiple roles through Require Approval > Workflow, using Approval Policy for reviewer routing. Unlike the external subscriber, it runs only for linked access items. I would keep Forms for business justification or compliance inputs rather than metadata validation.

My suggestion is to start with native end-date enforcement and Access Request Policies, then use the centralized subscriber only if your metadata conditions cannot be handled natively.