Skip to content

Workflow Templates

Workflow templates are pre-built workflows that you can edit to meet your needs.

Search for templates by name or description. Select one or more category tags to filter the templates by category. Select a template to start building a workflow.

This list of templates is subject to change. Some templates require integration with Data Intelligence.

Below, you can find a list of all templates currently available for workflows.

Adaptive Approvals Templates

Adaptive Approvals templates offer a starting point for building approval policies within workflows.

Hardware Provisioning Task Based Approval Policy

This workflow is triggered when a user launches an interactive process. The user is asked to complete a form with new hire information and make hardware selections. The selections then go through a 2 or 3 step approval process, depending on if hardware policy exceptions or customizations were selected.

  • This workflow is triggered when a Helpdesk user launches an interactive process.

  • Identity attributes for the HelpDesk user who launched the interactive process are retrieved.

  • The interactive Process displays an opening message.

  • The New Hire Hardware Provisioning Form is presented to the HelpDesk user who launched the interactive process. This form gathers information about the new hire and the hardware request.

  • If hardware policy exceptions or customizations were selected in the form, the department head details are retrieved from the form and the request goes through a 3-step parallel review with the manager, the department head, and the hardware provisioning team. If the request is approved, the interactive process is updated with a message and the new hire is notified of the approval via email. The workflow then completes successfully.

  • If the request is not approved, the interactive process is updated with the status of the request and the workflow completes successfully.

  • If no policy hardware exceptions were selected, the department of the new hire is confirmed and the request goes through a 2-step parallel review with the manager and the hardware provisioning team.

  • The new hire is notified that a hardware request has been submitted and the workflow ends successfully.

Multi-Step Serial Approval of Access Request

This workflow is triggered when an access request is submitted. The request is either auto-approved or goes through a multi-step approval process. If approved as an exception, a certification campaign is created to ensure all access for the recipient is necessary.

  • This workflow is triggered when an access request is submitted.

  • The recipient identity is evaluated to determine whether the recipient is in the Security department. If they are, the request is auto-approved.

  • If the recipient is not in the Security department, the request is considered an exception, and a multi-step approval is required.

  • The recipient’s manager and the manager’s manager are configured in a serial approval policy to review the request. Both must approve for the access to be approved. The reviewers will receive daily reminder notifications if they have not completed the review. They must review the request within 8 days or the request expires and the request is rejected.

  • If the request is approved, the recipient is notified via Slack. Because this access is an exception, a certification campaign is created, and the recipient’s manager is notified and must certify all access for the recipient. The workflow ends successfully.

  • If the request was rejected, the recipient is notified via Slack. The access request was reviewed, and the recipient was notified of the result. The workflow ends successfully.

Quorum Based Approval of Access Request

This workflow is triggered when an access request is submitted. An Approval Board is created to perform quorum approvals. Outlier Score data is used to branch the approval policies based on risk, requiring an extra single approval for recipients not deemed low risk.

  • This workflow triggers when an access request is submitted.

  • Identity attributes are retrieved for the recipient.

  • A list of identities with the Approval Board title are retrieved, and the first 5 Approval Board identities are used to create custom variables to be used in the Approval Policy Action.

  • An HTTP Request is used to retrieve the recipient’s outlier score. If no score exists or the recipient’s outlier score is under 0.5, the request proceeds to the low risk 60% quorum approval.

  • The low risk 60% quorum approval policy requires 60% approval to approve the request. Approvals are sent in parallel to the recipient’s manager, the access item owner, and 3 members of the approval board. The reviewers will receive daily reminder notifications if they have not completed the review. They must review the request within 8 days or the request expires and the access is rejected.

  • If the recipient’s outlier score is 0.5 or higher, a single step approval policy with approval from a Security Governance Group is required. If this approval is rejected, the recipient is notified that the request was rejected, and the workflow completes successfully. If the approval is approved, the request moves to a quorum approval.

  • The Quorum approval policy requires 60% approval to approve the request. Approvals are sent in parallel to 5 members of the approval board. The reviewers will receive daily reminder notifications if they have not completed the review. They must review the request within 8 days or the request expires and the access is rejected.

  • If the quorum approval percentage is met by the approval board, the request is approved. The recipient is notified of the approval via email, and the workflow ends successfully.

  • If the approval does not pass the quorum approval percentage, the request is rejected. The recipient is notified of the request rejection via email, and the workflow ends successfully.

Create a Certification Campaign for Detected Outliers (0.7-0.9)

This workflow is triggered when an outlier score is at or above 0.7 but less than 0.9. An email notification is sent to the outlier identity's manager and a certification campaign is assigned to the manager to review the outlier identity's access.

  • This workflow is triggered when an outlier is detected.

  • The workflow compares the outlier score to ensure it is at or above 0.7 but lower than 0.9.

  • When an outlier score is detected in this range, the workflow returns information on the outlier identity and their manager.

  • A certification campaign is created, and the identity’s manager is notified so they can review the identity’s access.

  • The workflow ends successfully when the manager has been successfully notified.

  • If the evaluated outlier score is not within this range, no further action is needed, and the workflow completes successfully

Create and Activate a Certification Campaign

This workflow is triggered when an identity changes departments. The workflow creates and activates a certification campaign so their manager can verify their new access.

  • This workflow is triggered when an identity’s attributes change.

  • The workflow determines whether the identity’s department has changed.

  • When an identity changes departments, the workflow creates and activates a certification campaign so their manager can verify their new access.

  • The manager is notified that a certification campaign is pending.

  • The workflow ends successfully when the manager has been notified.

  • If the identity did not change departments, no further action is needed, and the workflow completes successfully.

Disable Accounts and Send an Email Notification for Detected Outlier Identities (0.9+)

This workflow is triggered when a detected outlier score is at or above 0.9. When the score is this high, all accounts for the identity are disabled and an email notification is sent to their manager to review access and investigate the exceptions.

  • This workflow is triggered when an outlier is detected.

  • The workflow compares the outlier score to ensure it is at or above 0.9.

  • When an outlier score is this high, the workflow returns all attributes, access associated with the outlier identity, and their manager.

  • Their manager is notified that the outlier is deemed an excessive risk, and all accounts are disabled until a full review can be completed.

  • The workflow ends successfully when the manager has been successfully notified and all accounts have been disabled.

  • If the evaluated outlier score is not at or above 0.9, no further action is needed, and the workflow completes successfully.

Initiate Onboarding Process When a New Identity is Created

This workflow is triggered when a new identity is created. The workflow activates accounts associated with the new identity and generates a certification campaign so their manager can verify their access.

  • This workflow is triggered when a new identity is created.

  • An HTTP step in this workflow allows you to configure a request to an external system, such as an IT system for hardware access.

  • The workflow activates the accounts associated with the identity and generates a certification campaign so their manager can verify their access.

  • Email notifications throughout the workflow can be configured to notify the user and their manager of the onboarding process’s progress.

  • The workflow ends successfully when the certification campaign has been created.

  • If the HTTP Request step fails, an email is sent to the new identity’s manager, and the workflow ends in a failed state.

Remove Access Based off Device Compliance Change

Limited Availability

Functionality available to select customers. Visit SailPoint Product News for more information.

This workflow is triggered by a Shared Signals Framework CAEP event when an identity’s device is no longer compliant. The workflow disables the identity’s accounts in response to a potential threat.

  • This workflow is triggered when a device compliance change CAEP Event is received showing an identity’s device as not compliant.

  • The workflow retrieves details about the identity and returns a list of the identity’s current accounts.

  • All returned accounts are disabled.

  • The workflow ends successfully when all the identity’s accounts are disabled.

Note

Some organizations might want to add a step to create a certification campaign prior to ending the workflow.

Remove Access When an Identity Becomes Inactive

This workflow is triggered when an identity’s lifecycle state changes to Inactive. The workflow disables the identity’s remaining accounts and notifies their manager of their inactive status.

  • This workflow is triggered when an identity’s lifecycle state changes.

  • The workflow determines if the lifecycle state attribute changed to Inactive.

  • When this attribute changes to Inactive, the workflow disables the identity’s accounts and notifies their manager of their inactive status.

  • An HTTP request allows you to configure appropriate actions to be taken on external systems.

  • The workflow ends successfully when the accounts have been disabled.

  • If the lifecycle state attribute has not changed to Inactive, no further action is needed, and the workflow ends successfully.

Native Change Detection Templates

Native Change Detection templates offer a starting point for building a workflow that triggers after an account aggregation detects that an account has been created or updated outside of Identity Security Cloud.

Revoke Entitlement Additions Detected as Native Change Account Created

This workflow is triggered when a Native Change Account Created event containing entitlement additions is detected. Each new entitlement is revoked, and a summary email is sent to the source owner.

  • This workflow is triggered when a Native Change Account Created event containing entitlement additions is detected.

  • The workflow revokes each new entitlement, and a summary email is sent to the source owner.

  • The workflow ends successfully after the source owner has been notified.

Revoke Entitlement Additions Detected as Native Change Account Updated

This workflow is triggered when a Native Change Account Updated event containing entitlement additions is detected. Each new entitlement is revoked, and a summary email is sent to the source owner.

  • This workflow is triggered when a Native Change Account Updated event containing entitlement additions is detected.

  • The workflow revokes each new entitlement, and a summary email is sent to the source owner.

  • The workflow ends successfully after the source owner has been notified.

Privileged Task Automation Templates

Privileged Task Automation templates offer a starting point for building workflows to complete tasks for which users require privileged credentials to access an application and execute a series of commands to perform the task.

Create a Security Group in Active Directory

This privileged interactive workflow creates a new Active Directory security group using the LDAPS protocol. The user will be asked to provide some group details using a pre-configured interactive form.

  • This workflow is triggered when a user launches an interactive process.

  • The workflow uses the interactive process to keep the user informed of the progress.

  • The Privileged Action Gateway retrieves organizational units from Active Directory. There must be at least one organizational unit for the workflow to continue.

  • The user provides details for the new group in an interactive form.

  • The Privileged Action Gateway verifies that the provided group name is unique and therefore available to be used. 

  • The Privileged Action Gateway finds the provided manager’s account in Active Directory. 

  • The Privileged Action Gateway creates the new group in Active Directory.

  • The Privileged Action Gateway sets the manager as the manager for the new group. 

  • An email is sent to the manager notifying them that they have been assigned as the manager of the new group. If no email was configured in Active Directory, the user enters the manager’s email address in an interactive form and the email is sent. 

  • The new group details are displayed in a message to the user within the interactive process. 

  • The workflow ends successfully when the group is created and able to be found in Active Directory, and the manager is set and notified of the new group.

Update an Inbound Firewall Rule State on a Windows Server

This privileged interactive workflow allows you to enable or disable an inbound firewall rule on a Windows server using the WinRM protocol. The user will be asked to choose whether to enable or disable a rule, then select the rule to update using a pre-configured interactive form.

  • This workflow is triggered when a user launches an interactive process.

  • The workflow uses the interactive process to keep the user informed of the progress.

  • The user chooses whether to enable or disable an inbound firewall rule using an interactive form. 

  • The Privileged Action Gateway retrieves all rules from the target server that are in the opposite state of the user’s selection.

  • The user selects which rule to update using an interactive form.

  • Based on the user’s selections, the Privileged Action Gateway updates the selected inbound firewall rule.

  • The workflow ends successfully when the selected rule is in the desired state and the user is notified of the update.

Update the State of a Windows Service

This privileged interactive workflow allows you to stop, start, or restart a Windows service using the WinRM protocol. The user will be asked to choose the service and operation using a pre-configured interactive form.

  • This workflow is triggered when a user launches an interactive process.

  • The workflow uses the interactive process to keep the user informed of the progress.

  • The Privileged Action Gateway retrieves all services from the target server.

  • The user selects which service to update and whether to stop, start, or restart that service using an interactive form.

  • Based on the user’s selections, the Privileged Action Gateway updates the selected Windows service state.

  • The workflow ends successfully when the selected service is in the desired state and the user is notified of the update.

Remove Access When an Identity Becomes Inactive

This workflow is triggered when an identity’s lifecycle state changes to Inactive. The workflow disables the identity’s remaining accounts and notifies their manager of their inactive status.

  • This workflow is triggered when an identity’s lifecycle state changes.

  • The workflow determines if the lifecycle state attribute changed to Inactive.

  • When this attribute changes to Inactive, the workflow disables the identity’s accounts and notifies their manager of their inactive status.

  • An HTTP request allows you to configure appropriate actions to be taken on external systems.

  • The workflow ends successfully when the accounts have been disabled.

  • If the lifecycle state attribute has not changed to Inactive, no further action is needed, and the workflow ends successfully.

Send an Email Notification for Detected Outlier Identity (0.5-0.7)

This workflow is triggered when an outlier score of higher than 0.5 but lower than 0.7 is detected. An email notification is sent to their manager to inform them the identity is an outlier.

  • This workflow is triggered when an outlier is detected.

  • The workflow compares the outlier score to ensure it is above 0.5 but lower than 0.7.

  • When an outlier score is detected in this range, the workflow returns information on the outlier identity and their manager.

  • The manager is notified that the identity is an outlier.

  • The workflow ends successfully when the manager has been successfully notified.

  • If the evaluated outlier score is not within this range, no further action is needed, and the workflow completes successfully.

Send an Email when an Access Request is Decided

This workflow is triggered when an access request is approved or denied. An email is sent to the user and their manager to notify them of the access change.

  • This workflow is triggered when an access request is decided.

  • The workflow sends an email to the user and their manager to notify them of the access change.

  • This workflow ends successfully when the identity’s manager has been notified.

Update and Certify Access When an Identity Changes Departments

This workflow is triggered when an identity changes departments. The workflow retrieves the access associated with their new role and grants that access to the identity. It also starts a certification campaign to ensure that the access no longer relevant to them is removed.

  • This workflow is triggered when one or more identity attributes have changed.

  • The workflow pauses to allow provisioning activities to be completed.

  • The workflow then compares the attributes to assess whether the department attribute was updated.

  • When the department attribute has changed for an identity, this workflow returns role and access information for the identity’s new department.

  • The new access is added for the identity and their manager is notified of their new access.

  • A certification campaign is created so the manager can verify the identity has the correct access needed for their new department.

  • The workflow ends successfully when the certification campaign has been created.

  • If the identity’s department was not changed, no further action is needed, and the workflow ends successfully.

Documentation Feedback

Feedback is provided as an informational resource only and does not form part of SailPoint’s official product documentation. SailPoint does not warrant or make any guarantees about the feedback (including without limitation as to its accuracy, relevance, or reliability). All feedback is subject to the terms set forth at https://developer.sailpoint.com/discuss/tos.