Designing OIG Access Requests for Ease of Use

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:

  1. It looks at the use of names and descriptions in the workflows to make identifying the right access request flow easier,
  2. 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
  3. 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.

Set Icon, Name and Description on a Workflow

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.

Workflow Icon Set

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:

Name and Description in Request Access UI

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:

  1. By selecting from the pulldown list in the Home tab of the Access Requests app in Slack
  2. By typing a request directly into the Messages tab of the Access Requests app in Slack,
  3. By using the /access prompt in any channel, or
  4. 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.

Lists of Available Workflows in Slack via the Access Requests app

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:

Flow Information in the Request Access UI

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.

Questions Asked in Slack

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.

Flow Initiation in Slack

However when the flow completes, all of this request detail is removed from the Slack view.

Flow Completion in Slack

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.

Flow Completion in Slack Replies

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.

Manager Asking for Additional Information in Request Access UI

The user will see these messages appear in their view and can enter responses.

Requester Responds in Request Access UI

The manager will see the responses in their view.

Manager Sees Responses in Request Access UI

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.

Manager Messaging in Slack

The requester will see the messages in the app and also in a new thread.

Requester Replies to Messages in Thread

The manager sees these in the access requests app

Responses inline in the Request

The messages (irrespective of whether they were entered in the Request Access UI or via a chat tool) are stored with the request.

Messaging Stored in the Request History

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.


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.

Leave a Reply