Workflows
Workflows are used to implement long-running processes. Typically associated with requests, certifications, and fulfillment.
A workflow consists of an orchestrated and repeatable pattern of business activity enabled by the systematic organization of resources into processes that transform materials, provide services, or process information. ~Wikipedia
In IDM we shall define the following workflows to be used in different processes.
Type | Name | Short Description | Input | Definition |
---|
Catalog Request | Manager | Manager | User, Catalog Items |
|
Catalog Request | Manager+1 | Manager + Business Owner | User, Catalog Items |
|
Catalog Request | Manager+2 | Manager + Business Owner + Technical Owner | User, Catalog Items |
|
Catalog Request | Manager+3 | Manager + Business Owner + IAMS + CISS | User, Catalog Items |
|
Catalog Request | RSA | Manager + Business Owner + RSA Team | User, Catalog Items |
|
Application Request | Application | IAMS + EWS | Application |
|
Role Request | Role | IAMS + EWS | Role |
|
Entitlement Request | Entitlement | IAMS + EWS | Entitlement |
|
Use Case
Notification Process - HR Process
Use Case | Notification Process - HR Process |
---|
Brief Description | The IDM System provides email notifications to users and groups to communicate required actions, statuses, and system activities. |
---|
Actors | |
---|
Trigger Events | |
---|
Preconditions | - The request was made to perform a task by IDM
|
---|
Post-Conditions | Success - Notification is sent to the beneficiary and requester
Fail - The notification could not be sent
|
---|
Basic Flow | The basic flow for notification is explained as follows: - The user operates on below:
- New User
- Update User
- Terminated User
- Transferred User
- Converted User
- Rehired User
- The user triggers the notification process
- IDM triggers an email notification to the designated Approver(s) or Approver team(s) to complete the review and approval of the request. See Notification Templates for all trigger events
- The request ID is generated for all request
- IDM adds hyperlink of Request ID in the body of the notification
- IDM adds the comment that was provided while the request was submitted, in the notification
- IDM sends the most recent comment in the notification for every approval/ revoke notification triggers
|
---|
Notification Process -Access Request
Use Case | Notification Process - Access Request |
---|
Brief Description | The IDM System provides email notifications to users and groups to communicate required actions, statuses, and system activities. |
---|
Actors | |
---|
Trigger Events | |
---|
Preconditions | - The request was made to perform a task by IDM
|
---|
Post-Conditions | Success - Notification is sent to the beneficiary and requester
Fail - The notification could not be sent
|
---|
Basic Flow | The basic flow for notification is explained as follows: - The user operates on below:
- Application or System Entitlements
- Application of System Access and Provisioning
- Adding, Expired or Expiring Proxy Users
- Requests submitted by Beneficiaries
- The user triggers the notification process
- IDM triggers an email notification to the designated Approver(s) or Approver team(s) to complete the review and approval of the request. See Notification Templates for all trigger events
- The request ID is generated for all request
- IDM adds hyperlink of Request ID in the body of the notification
- IDM adds the comment that was provided while the request was submitted, in the notification
- IDM sends the most recent comment in the notification for every approval/ revoke notification triggers
|
---|
Notification Process -Scheduled Automated Process
Use Case | Notification Process - Scheduled Automated Process |
---|
Brief Description | The IDM System provides email notifications to users and groups to communicate required actions, statuses, and system activities. |
---|
Actors | |
---|
Trigger Events | |
---|
Preconditions | - The request was made to perform a task by IDM
|
---|
Post-Conditions | Success - Notification is sent to the beneficiary and requester
Fail - The notification could not be sent
|
---|
Basic Flow | The basic flow for notification is explained as follows: - The user operates on below:
- Certification Reminders and Sign-Off\Closure
- Request Reminders
- The user triggers the notification process
- IDM triggers an email notification to the designated Approver(s) or Approver team(s) to complete the review and approval of the request. See Notification Templates for all trigger events
- The request ID is generated for all request
- IDM adds hyperlink of Request ID in the body of the notification
- IDM adds the comment that was provided while the request was submitted, in the notification
- IDM sends the most recent comment in the notification for every approval/ revoke notification triggers
|
---|
Notification Process -IDM Actions and Activities
Use Case | Notification Process - IDM Actions and Activities |
---|
Brief Description | The IDM System provides email notifications to users and groups to communicate required actions, statuses, and system activities. |
---|
Actors | |
---|
Trigger Events | |
---|
Preconditions | - The request was made to perform a task by IDM
|
---|
Post-Conditions | Success - Notification is sent to the beneficiary and requester
Fail - The notification could not be sent
|
---|
Basic Flow | The basic flow for notification is explained as follows: - The user operates on below:
- Request Submitted
- Action Required
- Request Approved
- Request Rejected
- Request Completed
- Manual Provisioning Required
- Offboarding Notice
- Proxy User Created
- The user triggers the notification process
- IDM triggers an email notification to the designated Approver(s) or Approver team(s) to complete the review and approval of the request. See Notification Templates for all trigger events
- The request ID is generated for all request
- IDM adds hyperlink of Request ID in the body of the notification
- IDM adds the comment that was provided while the request was submitted, in the notification
- IDM sends the most recent comment in the notification for every approval/ revoke notification triggers
|
---|
Notification Management
Use Case | Notification Management |
---|
Brief Description | The Management Console allows IDM Admins and Power Users to manage email notifications for IDM. |
---|
Actors | IDM - Management Admin Console
|
---|
Trigger Events | |
---|
Preconditions | - User has permission in Admin Console
|
---|
Post-Conditions | Success - Template creation, notification services, and rules able to perform and modify
Fail - Template creation, notification services, and rules unable to perform and modify
|
---|
Basic Flow | The basic idea for notification is explained as follows: - The user enters the Admin Console
- Use clicks on Notifications option
- The user observes Notification Templates, an option to create and manage email notification templates
- The user also observes Notification Services, through which management of the notification services is done, such as starting, stopping, and revising notification schedules.
- The user also observes Notification Rules: defining and configuration of rules for notifications is available in the Management Console.
|
---|
Workflow Management - Request Workflow
Use Case | Workflow Management - Request Workflow |
---|
Brief Description | The Admin Console provides IDM Administrators with the ability to configure and manage workflow rules. Workflows in IDMIDM are streamlined to have a defined beginning and end state |
---|
Actors | IDM - Management Admin Console
|
---|
Trigger Events | |
---|
Preconditions | - User has permission in Admin Console
|
---|
Post-Conditions | Success - Workflow rules and flow to perform and modify
Fail - Workflow rules and flow unable to perform and modify
|
---|
Basic Flow | Request Workflow - A request is submitted through IDM.
- IDM checks if the operation is a bulk request
- If the request is a bulk, requests are created, and the Authorization Workflow is invoked if necessary, followed by the Approval Workflow.
- If the request is not a bulk operation, a request ID is generated, and it is evaluated for authorization workflow rules. After evaluation, the Approval workflow is invoked unless it is a request that does not require approval, which then routes for provisioning immediately
|
---|
Workflow Management - Authorization Workflow
Use Case | Workflow Management - Authorization Workflow |
---|
Brief Description | The Admin Console provides IDM administrators with the ability to configure and manage workflow rules. Workflows in IDMIDM are streamlined to have a defined beginning and end state. |
---|
Actors | IDM - Management Admin Console
|
---|
Trigger Events | |
---|
Preconditions | - User has permission in Admin Console
|
---|
Post-Conditions | Success - Workflow rules and flow to perform and modify
Fail - Workflow rules and flow unable to perform and modify
|
---|
Basic Flow | Authorization Workflow: - Catalog items are configured through catalog metadata to require authorization checks. (Authorization checks are validations that the user can receive the access requested)
- Before requests routing for approval, IDM checks for any training or qualifications necessary.
- If the user does not have that access, the request is rejected, and the user is notified that they cannot receive access without completing the prerequisites
- If the operation is allowed, it will route to the approval step
|
---|
Workflow Management - Approval Workflow
Use Case | Workflow Management - Approval Workflow |
---|
Brief Description | The Admin Console provides IDM administrators with the ability to configure and manage workflow rules. Workflows in IDMIDM are streamlined to have a defined beginning and end state. Approval Policy defines the rules to take upon a specific action in IDM, such as a request or the approval of a request. Workflow rules specify which attributes to verify, what approvals are required, and what fulfillment activities must be completed for each catalog item |
---|
Actors | IDM - Management Admin Console
|
---|
Trigger Events | |
---|
Preconditions | - User has permission in Admin Console
|
---|
Post-Conditions | Success - Workflow rules and flow to perform and modify
Fail - Workflow rules and flow unable to perform and modify
|
---|
Basic Flow | Approval Workflow: - Rules can be configured for all supported operations in IDM: Create, Modify, Disable, or Delete Users, Roles, Accounts, or Entitlements; all Bulk Requests.
- Each Approval Workflow may have multiple rules which are defined and processed in a specific order.
- Approval workflow rules specify a Condition and an Outcome.
- Condition: a rule-based condition defined based on allowed inputs such as role membership
- Outcome: a workflow ID is generated, which is the SOA ID to be initiated for the operation.
|
---|
IDM System Configuration
Use Case | IDM System Configuration |
---|
Brief Description | The Management Console allows modifications to majorly IDH, IDM components, and attributes |
---|
Actors | IDM - Management Admin Console
|
---|
Trigger Events | |
---|
Preconditions | - User has permission in Admin Console
|
---|
Post-Conditions | Success - Able to modify all the items listed in the basic flow below
Fail - Unable to modify all/ some of the items listed in the basic flow below
|
---|
Basic Flow | The basic idea is explained as follows: IDM System Administrators shall have the ability to modify: - All components of the IDH
- IDM menus and screens, list data
- Roles
- Custom attributes
- Policies
- Forms
- Schedules
- Connectors
- Application instances
|
---|