Workflows

PAM provides the ability to associate workflows to users to request control which requires approval before their request is enabled or their task can be executed. 

When a user is bound by a workflow, instead of them having the ability to immediately perform a permissible action, they must request and receive approval before this action can be performed. 

Workflows can also be used to restrict access based on time, days, IP addresses and other configuration options.

For more information and workflow examples, we encourage you to read our articles about Workflow configuration and use.

Components

To begin understanding Workflows, it is important to understand the various components that are used to construct, design, bind and use throughout the system.

• Core Workflow – The core workflow itself contains several building blocks

  • Templates - The workflow’s template contains the type of workflow, the steps (who approves the request) and the ranking of each principal (how many approvals are required to advance the workflow to the next step). Templates can only be created, managed and deleted by System Administrators.

  • Bindings - The workflow’s binding is the association between a template (the process) and its principal (who, what and when) that will require approval to perform an action. The binding contains of the associated template, the associated user or group that will be assigned the workflow and its configuration. Bindings can be applied globally by System Administrators or they can be applied to individual records (or multiple using inheritance) by those users with the required object permissions.

  • Instances - A list of all active and completed workflows in the system. This includes who initiated the workflow, with which record, at what time and any additional details. The Workflow Instance page can also be used to terminate pending or previously approved requests.

• Requester - The requester is the user who initiates a workflow by requesting an action like Connect, Unlock or Edit. The requester is associated to a workflow by being listed as a User in the workflow’s Binding.

• Approver - The approver is the user who approves or rejects a step in the workflow. Approvers are defined in the steps of the workflow’s Template. If an Approver rejects a request at any step, then the workflow is immediately completed, and the requested access is not granted to the requester.

• Status - The status of the workflow displays the current step as well as previous approval or rejection comments. The status is visible only to the Requester, Auditors and System Administrators.

• My Workflows - The personal area of the system where Approvers will find workflows that require their approval and Requesters will find details of their active and historical requests.

Managing Templates

To manage workflow templates, you must first login with your System Administrator account and then navigate to the Administration > Workflows > Templates tab.

Create a New Template

To create a new workflow template, select the Templates tab on the Workflow page and then click the Add button. 

Configure your workflow template as required.

Name	Enter a unique name for your template.
Type	Select from the available types: Automatic Approval – the system will automatically approve the request. No human interaction required. Interactive Approval – requires user approval in the form of one or more approval steps. Restrict Access - creates a template that restricts access to options based on who and what is bound to the template. For example, this type would be used if you did not want users to Connect to a system after business hours. Delegated Approval- allows users to delegate their approval action to the system.
Step n	Defines the list of approvers per step. Each listed approver will be notified when there is a request pending their approval. When using Groups as an approver, each member of the group will be notified of pending requests. Rank determines how many “approves” are required in total to advance the workflow to the next step. When the last step is fully approved, only then will the requester gain the needed approval to use their request operation. A requester may be included in their own approval template; however, they will not be permitted to approve their own request. To add additional steps, click the Add Step button.

Click the Save button when you are finished.

New templates are created in a Draft state which means they cannot be used in a binding until it is published. To publish your new template, open its Action menu and select the Publish option.

Edit a Template

To edit an existing template, navigate to the Administration > Workflows > Templates tab, locate your template from the list, open its Action menu and select the Edit option. 

Make the required updates to your template and then click the Save button. 

Edited templates are automatically returned to the Draft state and must be Published before they can be used in new bindings.

To publish your updated template, open its Action menu and select the Publish option.

Delete a Template

To delete an existing template, navigate to the Administration > Workflows > Templates tab, locate your template from the list, open its Action menu and select the Delete option.

You cannot delete a template that is currently being used in any binding.

Manage Bindings

To manage workflow bindings, you must be able to access the Manage > Workflows options which requires Owner or System Administrator permissions.

Create a New Binding

To create a binding, you must decide on which objects you wish to restrict. 

Workflow bindings take advantage of container inheritance, so if you apply your binding to the All Records or Root Folder for example, then it will inherit down to every object in your system’s vault (which inherits from its parent). 

This may, or may not, be the desired goal so consider which object(s) you want to apply workflows to first.

1. When you decided on the object to apply the workflow, select its Manage > Workflows option.

• For containers, first navigate inside this container and then select the Manage > Workflows option from the options along the top.

• For records, first view or open the record and then select the Manage > Workflows option.

2. On this Workflow Bindings page, click the Add button to create a new binding.

3. Configure your binding as required by populating all the necessary options.

Workflow Template	Select the published template to be used from the dropdown list. Note that only Published templates will be available for selection.
Workflow Design	Displays a read-only view of the selected workflow template.
Assign to All Users	Check this box to apply this binding to all users. Checking this option will disable the Users parameter. Pay special attention to assigning a workflow to an administrative action for all users of the system because it will limit the ability to perform administrative functions without approval.
Users	Add your principals (users or groups) to whom the binding will be applied. Binded users will require approval to utilize defined actions during the configured time periods.
IP Filter	Enter an IP address(es) that act as a filter for the binding. IP Filter is a comma separated list of IP addresses (i.e. 10.0.0.12) or IP addresses with IP mask (i.e. 10.0.0.0/24) optionally preceded by a minus sign to indicate that the binding will apply to IP addresses outside of the specified range. For example, if you want the binding to only be applied to a user that comes from an IP address, then enter that address in the filter.
Actions	Select which Actions will require approval for the bound users. Administration – Requires the user to have approved access before they can make Administrative changes to the system. For a list of Administration actions, please see our Workflow Binding article. Record Control – Requires the user to have approved access before they can Unlock or Edit the object. Connect Control – Requires the user to have approved access before they can Connect to a session. Task Control - Requires the user to have approved access before they can Execute an on-demand task.
Time Selector	A selected or checked Time Selector will mean that during this time period, the bound user will need to request access while an unchecked option will mean that the binding will be disabled, and the action will be available without requiring approval. Select which time selectors to apply to this binding. A selected or checked time selector means that the binded user will require approval when requested during this time period(s). CRON EXPRESSION HELP Examples of time execution window formats: * * 1-7 ? * SUN,SAT * - between 1am and 7am, on every Sunday and Saturday * * 0,1,2,3,12,22,23 ? * MON,TUE,WED * - during 0am, 1am, 2am, 3am, 12pm, 22pm and 23pm, on every Monday, Tuesday and Wednesday System Administrators can define the time, day or date values of each time selector in Administration > Settings > Parameters.
Duration	Setting a workflow binding’s Duration value will allow a different template to be applied based on the length of time the requester submits. Duration is a threshold between applying two workflow templates. When the Duration is empty, it means any requested time period, but when you create a second near-identical binding with a duration defined, then it sets that cutoff. The duration is defined in minutes. Duration triggers this request approval workflow for long requested access time. Note that binding with duration set requires default binding created to cover the cases for short requested durations. Otherwise the system will not apply workflow requirements for the designated actions considering that no default workflow means open access. This default binding without duration could be applied to all system users or assets, or only to those with the duration set. Default binding could be defined with auto-approval workflow which would mean that only long requests would require people approval. Default and several duration-based bindings combined allow users to select emergency workflow with different approval scenarios by requesting access for shorter time. Another use of duration-based bindings is to restrict disproportionally long requests by applying Restrict Access workflow for long durations while maintaining automatic or human-approved templates for shorted requests.
Checkout	The Checkout parameter enforces accountability on records by only permitting a single user (the approved requester) to access the record actions while in the checked-out state. Disabled – The record will not be Checked Out. The option will be set to not Check Out the record and the requester cannot change this setting. Optional – The requester will decide to Check Out the record or not when making the access request. Required – The record will be forced to Checked Out. The option will be automatically set to Check Out the record and the requester cannot change this setting. The system will not perform the operation for any user with the exception of the one who checked out the record.
MFA	The MFA parameter enables the enforcement of MFA when the user attempts to use their approved action. Disabled – MFA will not be required. Required – The user will be required to use MFA when the approved action is initiated. Currently the option supports TOTP, Duo Security OTP and Radius MFA for Unlock and Connect actions.
Behavior Profile	Applies the selected Behavior Profile to the configured binding.
Ticket Types	Select which ticket types to apply to this binding. Ticket types are a comma-separated list of ticketing systems to provide related ticket information from when submitting access request governed by this binding. Precede a ticket type in the list with the asterisk character to indicate that the ticket number for this type is mandatory required to request access.
Weight	This value determines which workflow will be initiated when the same user(s) and time restriction(s) are enabled. A binding with a lower order will be applied rather than an equivalent binding of a higher value.

4. Click the Save button to save your binding.

Edit a Binding

To edit a binding, navigate to the Manage > Workflows page on the object where the binding exists, open the Actions menu and select the Edit option.

 Make the desired updates and click the Save to complete the editing process.

Delete a Binding

To delete a binding, navigate to the Manage > Workflows page on the object where the binding exists, open the Actions menu and select the Delete option. 

Confirm your binding delete operation to complete its removal.

Check Instance Status

The status and details of workflow instances can be reviewed in the system by various users.

Requester

A requestor may check the current status of their requests by one of two methods:

1. Navigate to the Management > My Workflows > My Requests tab. Locate the request in the list, open the Actions menu and select the Details option. The Workflow Instance page will display the current status and other relevant details about their request.

2. On the object where your request was submitted. The original Request button is now displayed as Requested, clicking this Requested button will open the Workflow Instance page displaying the current status and other relevant details about their request.

Auditor

An account with the Auditor global role may review, but not take any actions against, Workflow Instances by opening the Requests report in the Reports section of the menu. In this report, this Auditor will be able to review all Pending, Active and Completed workflow requests and use the Details option to view information about a specific request. 

The Sessions option in this same Actions menu and on the Details page will generate a report of all remote sessions, if any, that were established during the time of this workflow instance.

System Administrator

An account with the System Administrator global role may review and take actions against Workflow Instances by opening the Requests report in the Reports section of the menu.

In this report, this System Administrator will be able to review all Pending, Active and Completed workflow requests and use the Details option to view information about a specific request. 

The Sessions option in this same Actions menu and on the Details page will generate a report of all remote sessions, if any, that were established during the time of this workflow instance.

Terminate Requests Before Approval

A submitted request can be terminated or cancelled before it is approved by either the Requestor or a System Administrator.

Requestor

A requestor may terminate their own submitted request before its approval by navigating to the Management > My Workflows > My Requests tab.

Locate the request you would like to terminate, open its Action menu and select the Terminate option.

Provide a reason why you are terminating your request and finally click Reject to complete the process.

System Administrator

A System Administrator may terminate a submitted request of another user by navigating to the Reports > Requests report. 

Locate the request you would like to terminate, open its Action menu and select the Details option. 

On the Details page, confirm this is the request that you wish to terminate and then click the Terminate button. 

Provide a reason why you are terminating the request and finally click Reject to complete the process.

Terminate Requests After Approval

A request can be terminated or cancelled after it is approved by either the Requestor, Approvers or a System Administrator.

Requestor

A requestor may terminate their own approved request by navigating to the Management > My Workflows > My Requests tab.

Locate the request you would like to terminate, open its Action menu and select the Terminate option. 

Provide a reason why you are terminating your request and finally click Reject to complete the process.

Approver

An approver may terminate an approver request of another user (even if they did not originally approve it) by navigating to the Management > My Workflows > My Requests tab. 

Locate the request you would like to terminate, open its Action menu and select the Terminate option. 

Provide a reason why you are terminating the user’s request and finally click Reject to complete the process.

System Administrator

A System Administrator may terminate a submitted request of another user by navigating to the Reports > Requests report. 

Locate the request you would like to terminate, open its Action menu and select the Details option. 

On the Details page, confirm this is the request that you wish to terminate and then click the Terminate button. 

Provide a reason why you are terminating the request and finally click Reject to complete the process.

Approve or Reject Requests

A user who is included in the Workflow Template as an approver, whether individually or as a group member, will receive a notification when there is a request pending their approval. 

For multi-step approval templates, approvers will only be notified when the workflow instance reaches their step, i.e. Step 2 approvers will not be notified until the workflow advances to past Step 1, if it ever does.

Interactive Approval

To approve or reject a request, navigate to the Management > My Workflows > Requests for Approval tab. 

This page will display all requests that are pending your approval.

For the request, open its Actions menu and select either Approve or Reject from the menu. 

Be careful with either selection as once you submit your decision, it cannot be rescinded.

• If you decide to Approve the request, you will simply need to click OK on the confirmation dialog box to submit your approval.

• If you decide to Reject the request, you will be required to submit a reason for the rejection and then you may click the Reject button to submit your rejection.

Email Approval

To approve or reject a request with an email response, once you receive the email notification regarding the Requestor’s request, simply reply to this same email with one of the following case insensitive words in the first line of the email body:

To Approve the Access Request	To Reject the Access Request
Yes	No
Approve	Reject
Approved	Rejected
Ok	{Anything other than the listed Approve words will also reject the request}

 

Notes about the Access Request Email Approval Response:

• This Email Approval feature has to be enabled in PAM. Please talk to your PAM System Administrator to determine if this feature is available for use.

• Approvers can use standard desktop email clients or mobile email apps and respond to the approval request email by sending a reply with the above words, without requiring the Approver to first login to PAM.

• The Approver must reply using the same email address that received the email approval request.

• All words contained in the first line of the email body may be included in the Reason field for the Approval or Rejection action.

• Any words contained in the first line of the email body that are not one of the above Approval words will be detected as a Rejection response.

• Periods or other punctuation marks are allowed at the end of the word.

After your decision is submitted, the request will be removed from your Request for Approval page for this step.

If this is a multi-step workflow template and you are an Approver in a future step of this same request, you may receive an additional notification and this request may be required again, pending your approval.