Introduction
The request process is the process of requesting accounts, entitlements, and roles within the IDM. After process approval, users’ access gets provisioned on the target systems or device
Following are the main features of this process
- Self Request: Here, the user can do the following:
- Request self-access for Accounts, Entitlement, and Roles
- Request to remove self-access for Accounts, Entitlement, and Roles
- Request to add a Delegate (To perform tasks on behalf of the user)
- Request to add a Proxy (To manage access requests, certification tasks, and completion of approval requests)
- Request for Others:
- Request access for Accounts, Entitlement, and Roles for other users
- Request to remove access for Accounts, Entitlement, and Roles
- Ability to save and resume work in progress
- Requests made for access (Both Self & Others) can be:
- Drafted - Can be used later to submit
- Withdrawn - Closed by the user before approval is made
- Closed - Closed by the IDM Administrator or 'UserHelpDesk'
Request Process Use cases:
Catalog Search
Use Case | Catalog Search |
---|
Brief Description | The process of searching for accounts, entitlements, and roles in IDM to request |
---|
Actors | |
---|
Trigger Events | |
---|
Preconditions | - Active user in IDM
- Catalog item is available in IDM
- User has permission to view the catalog item in IDM
|
---|
Post-Conditions | Success - Catalog item is finalized/ selected for request from IDM
- Request is Drafted
Fail - Could not view catalog items
- Could not select catalog items
|
---|
Basic Flow | The basic flow for the catalog is explained as below: - User clicks on create request link to request for a catalog item from Dashboard or Left Menu Panel
- IDM searches for the catalog item through the following:
- Wildcard search using * or % only (To view complete list)
- Text Search (For a string search)
- Combination of Wildcard and Text Search (Prefix and Suffix search using a wildcard)
- IDM displays the search result
- The user selects the relevant catalog item and adds to the cart
- User clicks on View Cart to view the list of items in the cart
- User observes:
- Checkout button to move to the next section
- Save as Draft button to save for the future change in request before submitting
|
---|
Modify Draft Request
Use Case | Modify Draft Request |
---|
Brief Description | The process of changing a saved request for access to accounts, entitlements, and roles in IDM. |
---|
Actors | |
---|
Trigger Events | |
---|
Preconditions | - Active user in IDM
- Catalog item is available in IDM
- Draft Request was made & saved by the user
|
---|
Post-Conditions | Success - Request is re-saved
- Draft Request is Submitted
Fail - Items do not match from the selected and saved items
- Unable to view items in Catalog Search
- Unable to add more items to cart
- Unable to re-save once the draft is opened
- Unable to submit the request
|
---|
Basic Flow | The basic flow for modify draft request process is explained as follows: - User searches for Draft Requests from the Request Track page
- User opens Draft created earlier
- The user observes a cart with selected access requests saved
- User clicks on adding more item to cart
- User searches for an item from the catalog search
- The user adds more items to the cart
- The user removes an item from the cart saved earlier
- The user observes the 'Check out' and 'Save as draft' button
- The user checks out by clicking on the 'Check out' button
- The user observes the 'Request for Self/Other' option
- User searches for another user from multiple search criteria
- The user adds another user for the requested item
- User remove previously added user from the selected item
- User enter the required details and add justification
- The user observes the 'Ready to Submit' and 'Save as draft' button
- The user clicks on the "Ready to submit" button for form validation.
- Users submit the request
- IDM creates a unique Request ID
- The user receives access to catalog item and desired roles, accounts, and entitlements post-approval and validation process
|
---|
Withdraw Request
Use Case | Withdraw Request |
---|
Brief Description | The process of withdrawing submitted access request for accounts, entitlements, and roles in IDM |
---|
Actors | |
---|
Trigger Events | |
---|
Preconditions | - Active user in IDM
- The request is submitted in IDM
|
---|
Post-Conditions | Success - The submitted request is withdrawn by the requester
- Beneficiary unable to withdraw request
Fail - The request is withdrawn by the beneficiary
- Request withdrawn for request with status as Completed, Expired, Pending Fulfillment status
- Requester and Beneficiary receives the notification of Withdraw Request
|
---|
Basic Flow | The basic flow for the withdraw request process is explained as follows: - User searches for Submitted Request
- The user observes Request Status as Pending Approval
- User clicks on Actions that can be performed on the Request
- User clicks on 'Withdraw' to withdraw the request
- The user enters comments/ justification on the popup for the reason of withdrawing the request
- The user confirms withdrawal of request by clicking on 'Confirm'
|
---|
Closing Request
Use Case | Closing Request |
---|
Brief Description | The process of closing a submitted access request for accounts, entitlements, and roles in IDM |
---|
Actors | IDM - Requester
- IDM Administrator or UserHelpDesk
|
---|
Trigger Events | - The request is submitted in IDM
|
---|
Preconditions | - Active user in IDM
- The request is submitted in IDM
|
---|
Post-Conditions | Success - The submitted request is closed
- Status for request changed to Closed
Fail - Beneficiary able to view submitted request
- Request closed by beneficiary or requester
- Request closed for request that had status as Completed, Expired, Pending Fulfillment status
|
---|
Basic Flow | The basic flow for the closing request process is explained as follows: - IDM Administrator or 'UserHelpDesk' searches for Submitted Request
- The user observes Request Status as Pending Approval
- User clicks on Actions that can be performed on the Request
- User clicks on 'Close' to close the request
- The user enters comments/ justification on the popup for the reason of the closing request
- The user confirms the closing of the request by clicking on 'Confirm'
- Requester and Beneficiary receives the notification of Closed Request
|
---|
Deleting Request
Process Name | Deleting Request |
---|
Brief Description | The process of deleting a request for accounts, entitlements, and roles in IDM |
---|
Actors | |
---|
Trigger Events | - The request is submitted in IDM
|
---|
Preconditions | - Active user in IDM
- The request is submitted in IDM
|
---|
Post-Conditions | Success - The submitted request could not be deleted
Fail - Beneficiary and requester unable to view request
- The submitted request is deleted
|
---|
Basic Flow | The basic flow for the withdraw request process is explained as follows: - User searches for Submitted Request
- The user observes Request Status
- User clicks on Actions that can be performed on the Request
- The user observes No delete option is present for the request
|
---|
Removing or revoking access request
Use Case | Removing or revoking access Request |
---|
Brief Description | The process of removing/ revoking access for accounts, entitlements, and roles in IDM |
---|
Actors | |
---|
Trigger Events | - The request is submitted in IDM
|
---|
Preconditions | - Active user in IDM
- User has access to accounts, entitlements, and roles in IDM that needs to be revoked
|
---|
Post-Conditions | Success - The submitted request triggered the approval process
- The request ID is generated
Fail - Unable to submit the request
|
---|
Basic Flow | The basic flow for the revoke access request process is explained as follows: - User searches for an item from the My access page
- The user selects items for removing access (Account/Entitlements/Role)
- The user observes the 'Revoke/ Remove' option (Revoke for Account and Entitlement and 'Remove' for Role)
- Users submit the request
- IDM creates a unique Request ID
|
---|
Proxy Request
Use Case | Proxy Request |
---|
Brief Description | The process to add a proxy to manage access requests, certification tasks, and completion of approval requests |
---|
Actors | IDM - Requester
- Proxy-assigned user
|
---|
Trigger Events | |
---|
Preconditions | |
---|
Post-Conditions | Success - Proxy-assigned user able to perform tasks on proxy defined Start and End dates
- Requested user unable to perform tasks on proxy defined dates
Fail - Requested user able to perform tasks on proxy defined dates
- Proxy-assigned user able to perform tasks outside proxy defined Start and End dates
- Users assigned as Proxy can approve requests submitted for themselves as the user manager (approval process)
- Terminated users able to perform tasks on proxy defined dates
|
---|
Basic Flow | The basic flow for the proxy request process is explained as follows: Flow 1: - User clicks on Add Proxy
- The user observes the Add Proxy popup with the option to Add User, Add Manager & Start & End Date
- The user enters Username and dates and saves the proxy information
- Proxy-assigned user and requester receives mail notification for proxy dates
Flow 2: - Requester edits the Proxy from the 'Edit Proxy' section
- User changes Proxy information and dates and saves the proxy information
- Proxy-assigned user and requester receives mail notification for proxy dates
Flow 3: - Requester cancels the Proxy from the 'Cancel Proxy' section
- The user confirms canceling with justification provided and selects 'Confirm'
- Proxy-assigned user and requester receives mail notification for proxy dates
|
---|
Delegate Request
Use Case | Delegate Request |
---|
Brief Description | The process of searching for accounts, entitlements, and roles in IDM to request |
---|
Actors | |
---|
Trigger Events | - The user invokes a delegate request
|
---|
Preconditions | |
---|
Post-Conditions | Success - Delegated users able to perform access requests, certification tasks, and approval requests. on behalf of the user
- Requested user able to perform her/his functionalities
Fail - User's access or functionality removed once delegated within IDM
- Assigned delegates able to complete a user's unassigned activities on behalf of the user
|
---|
Basic Flow | The basic flow for the delegate request process is explained as follows: - User clicks on 'My Access' to view current accesses
- User clicks on 'Add Delegate' for the access that needs delegation
- User searches for adding delegate (other users)
- The user selects delegate and confirms by clicking on 'Confirm'
- Delegate and requester receives mail notification for access request
|
---|
Request Failure Process
Use Case | Request Failure Process |
---|
Brief Description | The process when a request unable to submit for access to accounts, entitlements, and roles in IDM |
---|
Actors | |
---|
Trigger Events | |
---|
Preconditions | - Active user in IDM
- The request is submitted from the user-end through the User interface
|
---|
Post-Conditions | Success - Reattempted 5 times for submitting a request (after every failed attempt)
- Status changed to 'Request Failed' after 5th attempt
Fail - Status changed to 'Request Failed' before 5th attempt
- No re-attempts made
- No notification of request failure was sent to the designated support team and requester and beneficiary.
|
---|
Basic Flow | The basic flow for the request failure process is explained as follows: - User submits requests
- The system tries to submit a request and fails in 1st attempt
- The system tries to submit a request and fails in 2nd attempt
- The system tries to submit a request and fails in 3rd attempt
- The system tries to submit a request and fails on 4th attempt
- The system tries to submit a request and fails on 5th attempt
- Requester receives total request failure notification after 5th attempt failure
|
---|
Approval Process Use Case:
Auto- Approval
Use Case | Auto Approval |
---|
Brief Description | The process when a request does not require approval by a manager or approve group in IDM |
---|
Actors | |
---|
Trigger Events | |
---|
Preconditions | - Active user in IDM
- The request is submitted by the user
- The request ID is generated
|
---|
Post-Conditions | Success - Request sent to the fulfillment process
- Request status is changed to provisioning
Fail - Request not sent for fulfillment process
- Request sent for Manager/ Approve group approval
- Request status does not change to 'Provisioning'
|
---|
Basic Flow | The basic flow for the auto-approval process is explained as follows: - User submits Request
- IDM triggers the approval process and identifies no approval needed from the manager or any approved group
- IDM sends the request for the fulfillment process
- IDM change request status to 'Provisioning'
- IDM sends a notification to the requester
|
---|
Manager Accept Approval
Use Case | Manager Accept Approval |
---|
Brief Description | The process when a request requires approval by the manager in IDM |
---|
Actors | |
---|
Trigger Events | |
---|
Preconditions | - Active user in IDM
- A request is submitted by the user
- The request ID is generated
|
---|
Post-Conditions | Success - Request sent to the fulfillment process
- Request status is changed to provisioning
Fail - Request not sent for fulfillment process
- Request sent for Approve group approval
- Request status does not change to 'Provisioning'
|
---|
Basic Flow | The basic flow for the manager approval process is explained as follows: - User submits Request
- IDM triggers the approval process and identifies manager approval needed
- IDM sends the request to the manager (and his delegate, or proxy, as present in the system)
- IDM change request status to 'Obtaining operational approval'
- The manager provides some comments & justification and approves the request
- IDM sends a notification to the requester and beneficiary
- IDM change request status to 'Provisioning'
|
---|
Manager Reject Approval
Use Case | Manager Reject Approval |
---|
Brief Description | The process when a request requires approval by the manager in IDM |
---|
Actors | |
---|
Trigger Events | |
---|
Preconditions | - Active user in IDM
- The request is submitted by the user
- The request ID is generated
|
---|
Post-Conditions | Success - Request not sent for fulfillment process
- Request status is changed to 'Request Rejected'
- Requester unable to reopen the request
Fail - Request sent to the fulfillment process
- Request sent for Approve group approval
- Request status does not change to 'Request Rejected'
|
---|
Basic Flow | The basic flow for the manager reject process is explained as follows: - User submits Request
- IDM triggers the approval process and identifies manager approval needed
- IDM sends the request to the manager (and his delegate, or proxy, as present in the system)
- IDM change request status to 'Obtaining operational approval'
- The manager provides some comments & justification and rejects the request
- IDM sends a notification to the requester and beneficiary
- IDM change request status to 'Request Rejected'
- Manager no longer able to view the task under Approver details
|
---|
Manager Reassign Approval
Use Case | Manager Reassign Approval |
---|
Brief Description | The process when a request requires approval by the manager in IDM |
---|
Actors | |
---|
Trigger Events | |
---|
Preconditions | - Active user in IDM
- The request is submitted by the user
|
---|
Post-Conditions | Success - Request reassigned to the new user
- Request status remains unchanged
Fail - Request sent to the fulfillment process
- Request sent for Approve group approval
|
---|
Basic Flow | The basic flow for the manager reassign process is explained as follows: - User submits Request
- IDM triggers the approval process and identifies manager approval needed
- IDM sends the request to the manager (and his delegate, or proxy, as present in the system)
- IDM change request status to 'Obtaining operational approval'
- Manager searches for another user/ group to reassign the task
- Manager reassigns the task to another user/ group
- User has chosen for reassigned task able to view the re-assigned task
- Delegated user acts on behalf of the manager to perform task operation and able to view the task
|
---|
Role Approval
Use Case | Role Approval |
---|
Brief Description | The process when a request requires approval by the approval group in IDM |
---|
Actors | IDM - Requester
- Role Approver
|
---|
Trigger Events | |
---|
Preconditions | - Active user in IDM
- The request is submitted by the user
- The request ID is generated
|
---|
Post-Conditions | Success - Request sent to the fulfillment process
- Request status is changed to provisioning
Fail - Request not sent for fulfillment process
- Request status does not change to 'Provisioning'
|
---|
Basic Flow | The basic flow for the role approval process is explained as follows: - User submits Request
- IDM triggers the approval process and identifies role approval needed
- IDM sends the request to the member(s) of the approval group
- IDM change request status to 'Obtaining operational approval'
- IDM sends a notification to the requester and all member(s) of the approval group
- One of the members of the group provides some comments & justification and approves the request
- IDM change request status to 'Provisioning'
|
---|
Approval Expiry & Notification
Use Case | Approval Expiry and Notification |
---|
Brief Description | The process when a request requires approval by the manager in IDM |
---|
Actors | |
---|
Trigger Events | |
---|
Preconditions | - Active user in IDM
- The request is submitted by the user
- The request ID is generated
|
---|
Post-Conditions | Success - Request status is changed to 'Request Expired'
- Notifications sent to requester and approver
Fail - Request status does not change to 'Request Expired'
- Notifications not sent
- Request able to re-open the expired request
|
---|
Basic Flow | The basic flow for request expiry and notifications is explained as follows: - User submits Request
- IDM triggers the approval process and identifies auto-approval cannot be made
- IDM sends the request to the manager/ approve group for approval
- IDM change request status to 'Obtaining operational approval'
- IDM checks the status of request after 5 days of Request creation and finds it unchanged
- IDM sends a notification to the requester and approver
- IDM checks the status of request after 10 days of Request creation and finds it unchanged
- IDM sends a notification to the requester and approver
- IDM checks the status of request after 15 days of Request creation and finds it unchanged
- IDM change request status to 'Request Expired'
- IDM sends a notification to the requester and approver
|
---|
Bulk- Approval
Use Case | Auto Approval |
---|
Brief Description | The process when a request requires approval by a manager or approve group in IDM |
---|
Actors | |
---|
Trigger Events | |
---|
Preconditions | - Active user in IDM
- A request is submitted by the user
- The request ID is generated
|
---|
Post-Conditions | Success - Request status is updated for all tasks
- Request notification is sent to all requesters
Fail - Request status does not change for some/ all tasks
- Request status update notification not sent to all
- Beneficiary approved some part of their own request
|
---|
Basic Flow | The basic flow for the auto-approval process is explained as follows: - User searches for Approval Tasks
- User starts multi-select option to approve multiple tasks at a time
- The user selects tasks that need to be claimed, approved, rejected, or submitted
- The user performs the task
- The user provides comments and justification to the bulk task performance
- IDM change request status
- IDM sends a notification to requesters
|
---|
Track Request Use Case:
Track Request
Use Case | Track Request |
---|
Brief Description | The process when a request submitted can be tracked n IDM |
---|
Actors | |
---|
Trigger Events | |
---|
Preconditions | - Active user in IDM
- A request is submitted from the user-end through the User interface
|
---|
Post-Conditions | Success - IDM users were able to search for and track requests in the IDH by User ID, Request ID, or both.
- IDM Users were able to view all requested data
- Search results have fields: Request ID, Item requested, an action performed, status, beneficiary, and date requested
Fail - IDM users were unable to search for and track requests in the IDH by using the User ID, Request ID, or both.
- IDM Users were unable to view all requested data
- Search results did not have one/multiple fields among the following: Request ID, Item requested, the action performed, status, beneficiary, and date requested
|
---|
Basic Flow | The basic flow for the request failure process is explained as follows: - The user clicked on the 'Search Request' page
- User searched request by User ID and Request ID
- The user used advanced search functionality and availed AND/OR function and used a combination of fields: Request ID, Application, Entitlement, Role, Requester, Beneficiary, My Direct Reports, Requests Raised by Me, Requests Raised for Me to get search result
- User clicks on 'Search' to view search results
- User vi search results with fields: Request ID, Item requested, the action performed, status, beneficiary, and date requested.
- The user enters the desired Request and observes in detail by clicking on the hyperlink on Request ID
|
---|
The following information shall be available when tracking a request:
- Request and Approval Status
- Approver and last date and time of activity
- Approver hierarchy and status of the request for each level of approval
- Approver comments
Validation Use Case:
ECI Validation
Use Case | ECI Validation |
---|
Brief Description | The process when a request requires ECI validation in IDM |
---|
Actors | |
---|
Trigger Events | |
---|
Preconditions | - Active user in IDM
- The request is submitted by the user
- HRMS is connected to IDM and user record is synced
- LMS is connected to IDM
- Not all IDM catalog items will go through ECI validation, only those with specific Export Control Codes. Upon receipt of an HRMS record, IDM determines if ECI Validation is required based on the ECC Code.
|
---|
Post-Conditions | Success - Request rejects after ECI Validation fails
- The request moves to another step after ECI Validation passes
Fail - Request Completed after ECI Validation fails
- Request Failed after ECI Validation passes
|
---|
Basic Flow | The basic flow for the role approval process is explained as follows: - User submits Request
- IDM triggers validation process and checks ECI indicator for requested application, role, or entitlement
- IDM checks the Export Control Code (ECC) in the user identity record as received in IDM from HRMS
- IDM finds one of the options for ECC from below:
- "A" = US Persons (US Citizens, Green Card Holder, Asylee)
- "B" = Foreign Nationals from restricted countries
- "C" = Foreign Nationals from un-restricted countries
- "D" = Special Status Consultants
- "BLANK" = represents low values or spaces, but any code that does not conform to any of the codes above will fit this category.
- IDM identifies that attributes as "B" or "C" require ECI validation, whereas "A" and "D" does not require ECI validation and "Blank" will deny access
- IDM identifies that ECI Validation is required
- LMS is invoked at request time through a web service to check the requester's qualifications to have access to ECI.
- IDM identifies that either user has or hasn't completed the required training.
- IDM identifies that ECI Validation can move to the next step if the user has completed the training in LMS
- IDM identifies that training has not been completed in LMS by the user
- IDM sends notification that provides specific instructions for the user to complete the required training in LMS
- IDM sends notification that the user must complete the required training before the request can be completed
- IDM rejects the request after sending notification
|
---|
Inbox Management Use Case:
Inbox Workflow
Use Case | Inbox Workflow |
---|
Brief Description | Inbox Management is the method that users, approvers, certifiers, and fulfillers use to complete tasks assigned to them by the Access Governance System |
---|
Actors | IDM - Manager/ Approver/ Task Performer
|
---|
Trigger Events | The user invokes an Approve, Reject, Certify or Revoke, Claim, Remove, or Complete Task request
|
---|
Preconditions | |
---|
Post-Conditions | Success - The Inbox lists all approval, provisioning, fulfillment, certification, and audit violation tasks assigned to the user
- IDM users were able to search tasks by request or task ID and to filter tasks by user and application.
- Task removed from Inbox after task completion
Fail - Task still shows in Inbox after task completion
|
---|
Basic Flow | The basic flow for the request failure process is explained as follows: - IDM notifies the manager or approver is notified that they have a task to perform via email notification
- The manager, approver, or task performer clicked on the 'Inbox' icon to enter the inbox page
- User searched request by User ID or Request ID
- User vi all the lists of approval, provisioning, fulfillment, certification, and audit violation tasks assigned to the user with fields: Request ID, Beneficiary, Assignee, Acquired By, Expiration Date, and Assigned Date.
- The manager, approver, or task performer completes the task (using the Approve, Reject, Certify or Revoke, Claim, Remove, or Complete button)
- The task is removed from the inbox by IDM.
|
---|
Access Request Use Case:
Process Name | Access Request Process |
Brief Description | The process of requesting accounts, entitlements, and roles in IDM. |
Actors | |
Trigger Events | |
Preconditions | - Active user in IDM
- Catalog item is available in IDM
|
Post-Conditions | Success - The Request ID is being generated and the user has the requested catalog item
- Desired roles and entitlements have been provisioned to the user
Fail - Status of the request is being rejected
- If the entire process fails, need to submit the request again and will go for IDM validation and approver approves the request
|
Basic Flow | The basic flow for the access request process is explained in the below activity diagram - User clicks on the create request to link to request for a catalog item
- IDM searches for the catalog item and displays the search result
- The user selects the relevant catalog item and adds to the cart
- User clicks on checkout button and then enter the required details and add justification
- The user clicks on the "Ready to submit" button for form validation.
- Users submit the request
- IDM creates a Request ID
- The request goes for ECI validation
- After successful validation, a request is sent for approval
- Approver approves the request
- The user receives access to catalog item and desired roles, accounts, and entitlements
|
Diagram
The diagram below illustrates the basic flow of the user creation process.