Access Requests are designed to be used by all people in an organisation. So making the interface and information presented be more user friendly should be a goal of any deployment. In this article we look at what information is presented to end-users by Okta Identity Governance (OIG) Access Requests and how you can use that to improve the usability.
The article has three sections:
- It looks at the use of names and descriptions in the workflows to make identifying the right access request flow easier,
- It explores the information presented to end users and how it can be improved so users can understand what’s going on with a request, and
- It shows how encouraging the use of messaging (chat) can improve responsiveness and usability.
Article contents:
Use of Icon, Name and Description in Access Request Workflows
The first interaction a user will have with an Access Request is via the Request Access UI or via one of the chat mechanisms (Slack or Teams). Both use the name, but only the UI uses the description. Lets look at how these are configured and displayed.
Name and Description in the Workflow Builder
Access Request workflows offer three fields that can be used to describe the workflow; the Icon, the Name and the Description.
The Icon could be used to give a visual indication of the type or purpose of the workflow. However the set of icons is limited and not customisable.
The colour of the icon displayed is based on the colour of the team assigned to own the workflow. You can’t set it in the workflow. For the above reasons, I don’t find the icon that useful.
The most useful fields are the Name and Description. The Name will show in all interfaces, whereas the Description will only show in some interfaces (see the following sections). The Name and Description showing in the Request Access UI is as follows:
As can be seen, there is a limit on the display length of the description so it makes sense to be terse.
Display in the Request Access User Interface
The Request Access User Interface displays tiles for all access request workflows that the user is entitled to see (based on groups assigned to the workflows). The tiles show the icon, name and description of the flow.
Having both the name and description makes this interface very useful for the end-user. If using this interface, you could keep the name short and put more detail/instructions in the description (allowing for limited space for the description in the tile).
You should also consider if you will be exposing additional Access Request functions (functions other that just requesting access) and how to name and describe them.
The example above shows a traditional access request, another built to hand back an access badge and one for a temporary suspension of all access for a user. The names and descriptions make this clear.
Display in Slack
The Slack app has four ways to initiate an Access Request workflow:
- By selecting from the pulldown list in the Home tab of the Access Requests app in Slack
- By typing a request directly into the Messages tab of the Access Requests app in Slack,
- By using the
/accessprompt in any channel, or - By messaging the user associated with the app to request access in any channel,
The latter three will use some NLP and AI to try to match the request to available workflows, and gives the user the option to select from a list (the first will just present a list of available workflows). These selection lists will only present the workflow Name, not the Description.
If Slack is going to be the primary interface for requesting access there’s no value in adding Descriptions to workflows – focus on making the Names descriptive (or rely on the NLP/AI built in to learn what users are requesting).
More information on requesting access via Slack can be found in OIG Access Requests – Requesting Access in Slack.
Workflow Information Presented to End Users
When a user submits a request, they are presented with the message trail from that request, with the various questions, tasks and activities in the workflow. This could be confusing for end users. Whilst much of the information presented is fixed, based on the task/action being performed, there is some flexibility in naming of steps and items used in steps. The information presented will depend on whether the Request Access UI or chat is used.
Information Presented in Request Access UI
If a request is initiated in the Request Access UI (or initiated in chat, but followed in the Request Access UI) there is an extensive amount of information displayed. For example:
The above shows the flow name, instructions for the requester, the questions answered, the approval steps and access provisioning step. Some of this information is generated by the actions and cannot be changed. However an administrator can set:
- The flow name (e.g. “Carpark Access”)
- The step names (e.g. “Manager Approval”, “Parking Mgr Approval”, “Provision”)
- The question field names (e.g. “Justification” and “Site”)
You should think about how you name the flow, steps and any fields you expect the user to provide responses for.
Information Presented in Slack
Whilst running a request in Slack or Teams will run the same flows as running a request from the Request Access UI, the information displayed will be different. This section looks at the information displayed in Slack.
When the flow is started (access requested) any questions are displayed in a dialog box. The item labels are set in the flow.
When the flow runs, the requester will see a summary of the flow, and can drill into the questions they just answered and the next step (tasks) and who it’s assigned to.
However when the flow completes, all of this request detail is removed from the Slack view.
For a completed flow, the requester can click on the link (e.g. Badge Access #107) to be taken to the Request Access UI to see the full details of the request. They can also click on the replies link (e.g. 3 replies) to see some more information.
If Slack (or Teams) is the primary interface, there is value in thinking about the flow name, step names and question field name. However the information displayed in Slack is not a rich, particularly after the request is done, so it may be worth considering encouraging users to also use the Request Access UI to review any completed requests.
Encouraging the Use of Messaging (Chat)
One of the great usability benefits of OIG Access Requests is the ability to chat in real time between the requester and approvers or administrators. Rather than rely on a slow disjointed process (like sending emails), use of chat is far more effective. This is available via the Request Access UI and chat tools (Slack/Teams).
Messaging via the Request Access UI
There is a messaging function built into the flows and exposed in the Request Access UI. When a flow starts a response can be added. In the following, a manager (reviewing the access request) is asking for some more info.
The user will see these messages appear in their view and can enter responses.
The manager will see the responses in their view.
This works best if the parties have the Request Access UI open.
Messaging via Chat Tools
Obviously chat tools like Slack and Teams are designed for realtime messaging. The access requests function leverages that. A flow similar to the above in Slack looks like the following.
The requester will see the messages in the app and also in a new thread.
The manager sees these in the access requests app
The messages (irrespective of whether they were entered in the Request Access UI or via a chat tool) are stored with the request.
Thus, use of messaging can be a very effective way of making the access request process for end users and lot simpler and faster. It should be encouraged.
Conclusion
Identity Governance is as much about people and process as it is about the technology. Users of IGA functions, like Access Requests, will be from across the organisation and represent the full spectrum of “IT-savviness”. You need to consider how to make your Access Requests implementation more consumable by the entire user population. This article has explored a number of ways to make the Okta Identity Governance Access Requests more usable, including use of names and descriptions, step names and field labels, and use of messaging to improve responsiveness. Hopefully this will help guide you in your deployment of OIG.
