The Workflow List page serves as a comprehensive repository, showcasing a detailed overview of completed workflows, whether approved or rejected.
This tool provides at-a-glance insights into each workflow's essential information, including Task Id, Topic,Workflow Level, Status, Group Name, Requestor, and Current Assignee. Users can efficiently navigate and assess the historical progression of tasks, gaining clarity on the completion of each workflow.
With a user-friendly interface, administrators can quickly get a view of all the completed workflows for managing and analyzing completed workflows
The Actions button allows to view further details about the workflow stage and details about approval and/ or rejection
Custom workflows can be configured and customized further by creating workflow rules.These rules help defining conditions that trigger the workflow. Also these rules enable administrator to reuse a workflow grid for multiple processes and events which further reduces the reduntant effort an administrator needs to put.
To create Workflow Rules Navigate to Products -> Lifecycle Management -> Workflow -> Rules and click on the +Add New button
On the Workflow Rule Creation page as shown below, Following details need to be provided:
Name: (Mandatory)Name of the Worflow Rule
Workflow: (Mandatory) Need to select the custom workflow for which the rule will be applicable
Event: (Mandatory) Select event triggering the workflow
Mentioned below are its descriptions:
Application Provisioning: When an application is assigned to a user, this type od workflow is triggered to approve the provisioning process.
Application Deprovisioning: When an application is unassigned from a user, this type of workflow is triggered to approve the deprovisioning process.
User Creation: When a new user is created in Cymmetri, this type of workflow is triggered to approve the user creation process.
Workflow Setup: This type of workflow is triggered on the creation, updating, or deletion of mapped workflow configurations and their associated rules. It ensures that any changes to the workflow setup are reviewed and approved, maintaining the integrity and effectiveness of the workflow processes.
Application Role: When an application role is created, updated, or deleted, this type of workflow is triggered to approve the changes. This ensures that the roles are managed correctly and that any modifications are reviewed and authorized.
Application Update: When an application menu action or form submission is performed by a user, this type of workflow is triggered to approve the application update.
Decommission Device: When a device is scheduled for deletion, this type of workflow is triggered to approve the decommissioning process. This ensures that the device is properly removed from the system and that any associated data or configurations are handled appropriately.
SOD Violation: This workflow would be triggered for any SOD Violation and for taking appropriate action upon the violation. The screenshot below shows a workflow configured for this case
Description: (Optional) General description of the rule can be provided here for further understanding of the working of the rule
Conditions and filters can be added for country, department, designation, login pattern, user type, application, application role, and workflow depending upon the event selected
Multiple conditions can be combined using AND/ OR operators
Conditions can also be grouped to evaluate to true or false as a group
Meta conditions can be added for application events if meta values are added for applications.
For example, if the user's grade is a certain value, then the approval steps can be added or bypassed for access approval. Similarly, if the user's custom attribute is matched then approver associations can be changed dynamically. Other parameters that can be used are risk score of the user or checking of SoD policy violation.
The Pending Workflows List page provides a consolidated view of all ongoing workflows awaiting approval or rejection.
The comprehensive snapshot enables administrators to quickly identify pending tasks, their current status, and the associated contextual details.This tool provides at-a-glance insights into each workflow's essential information, including Topic,Workflow Level, Status, Group Name, Requestor, and Current Assignee.
By providing a centralized location for pending workflows, this page allows Administrators to effortlessly track the progression of tasks, ensuring timely reviews and approvals.
One of the very important actions provided on the Pending workflow page is Reassign Workflow. This option enables administrator to delegate the approval request to other user in cases when the current approver is not available due to various circumstances.
For reassigning the workflow to another approver the user needs to click on the reassign button and then select the new approver on the popup window as shown below:
Workflows may be configured for a number of use cases in the Cymmetri Identity Platform, primary among them being for assigning application to a user (provisioning), unassigning application to a user (deprovisioning), and running reconciliation campaigns.
Workflows in Cymmetri Identity Platform may be configured for a predefined stages of approval, (these number stages are configurable)
For each stage, the administrator may select one of the following options -
User - A particular user may approve workflow request at this stage.
Group - A user belonging to the selected Group may approve Workflow request at this stage.
Reporting Manager - The reporting manager of the user for which the approval is to be provided may approve the workflow request at this stage.
User List - A list of preselected users, these users receive the claims request and one of these users may approve the workflow. This can be used to define custom set of approver associations such as application owners, administrators, etc.
Grade - A list of users that fall in the grade range selected
Click on save to save the workflow.
Cymmetri allows flexible workflow configuration for managing closure of access requests in time bound manner. In case of escalation scenario, the next in line reporting manager will be automatically escalated based on turn around time definition for the particular workflow step. The relevant users will be alerted through email notification of the escalation of such requests.
If no escalation is defined, Cymmetri will automatically mark the request as rejected to end the request cycle. Cymmetri will alert the user of the automatic rejection via email notification.
By default Cymmetri workflows are configured to escalate an incoming request to the reporting manager in case the alternate approver is not defined or the workflow is of group approver principle.
In the case if the request is not attended to then it retires as per Turn around time defined. setting it to 0 means it will never retire.
To observe how to workflow runs in action, refer Inbox
