My colleague, Rajesh Kumar, showed me something today that fell into the “wow, I didn’t even think of using the product this way” category. It involves using logic in Access Request flows (Request Types) in Okta Identity Governance to prompt for additional information based on earlier selections.
Let’s look at how the user experiences it, then how it’s built. The scenario here is the the user is requesting some sort of office access. They must select the state, and then based on the state selected, they then get a list of state-based offices to select from. It’s a trivial example to show the mechanism.
Overview
The Okta Access Requests platform uses Request Types to build flows with steps. These steps may be questions for the requester (or someone else) to provide some information. They may also be approval steps, actions to be performed, tasks to be performed externally and timers to delay execution. All of these components are built into flows to represent the business processes for requesting access.
Logic can be applied between steps, such as “only add this user to the group if the previous approval step completes with approval”. This logic can also be applied between questions, where the display of a question is conditional on the selection or value entered in a previous question. For example, if provisioning building access, you may prompt the requester to select the state first, then based on the state present a list of offices in that state. The office selection questions presented are conditional on the state selected.
This article will show how this can be implemented in Request Types in Okta Access Requests, starting with the user experience and then how it’s built.
User Experience in the Access Requests Portal
When requesting access in the Access Requests Portal the experience is as follows. The user selects the request type from their App Catalog.
As usual, they are presented with a set of questions, in this case a Justification and a drop down list to Select state.
They select the state from the dropdown list.
On selecting a state, the dialog is changed and a third question added (“Select Vic office“) because the user selected Vic as the state.
Note that changing the Selected state will dynamically change the third field.
The users selects from the pulldown list of Vic offices.
And submits the new request.
The standard Request display shows all three questions answered.
The flow would then proceed as per the Request Type flow (e.g. manager approval then provisioning).
User Experience in the Slack App
The user experience when requesting access through the Slack app is basically the same. The user selects the resource (Request Type).
A dialog displays the first two fields (business justification and state to pick).
They fill out the fields.
Unlike in the Access Requests Portal example above, the Slack app does not automatically refresh with the third field. The user clicks the Submit button to send the current set of information to the Access Requests platform. It will respond to the app and the app will refresh the dialog with the third field.
The third value is selected.
Once the submit button is clicked, the request is created. The user can see the request information in Slack (or in the Access Request Portal).
As earlier, the request will continue with the next steps in the Request Type.
Building the Request Type to Support This
This Request Type flow is built using two standard features of Access Requests – Configuration Lists and Logic on steps.
You don’t need to use Configuration Lists, but if you’re offering selections that will branch in subsequent steps, using Configuration Lists means you don’t have to worry about users mistyping the selection. For example, it’s easier to have “Vic” in a config list than allowing the user to type in the state and have to allow for “vic”, “victoria”, “Vic”, “Victoria”, etc.
However you do need to use Logic to decide which step (Question) to present to the user next.
Let’s have a look at how this flow is built. There are two initial questions – Justification and Select state. The state selection is a Dropdown tied to a Configuration List called Office States (that has three values “Vic”, “NSW”, and “Qld”). Both are mandatory and you know one of “Vic”, “NSW” or “Qld” will be selected for the state.
Next come the variable questions – one for each state option. The Vic one is highlighted below and has it’s own dropdown, Office – Vic that has a list of Victorian offices.
It is assigned to the Requester (same as the earlier two questions).
Note that this step has Logic to only show if “Select state is Vic” (and the following one has “Select state is NSW“).
This is where the “Only show this field if” actually makes sense (in most other scenarios this option means “only run this step if”).
Notice that the next step tied to this one (“Set Vic office”) has a condition of “Select Vic office is Filled“. This means it will only run if the Select Vic office step has run and a value is selected.
This is important. You have effectively built a large switch statement and need to keep the subsequent logic within the respective case. Something like:
select state
if state = "Vic"
select Vic office
perform some action/tasks for Vic office selection
if state = "NSW"
select NSW office
perform some action/tasks for NSW office selection
...If you get the Logic conditions wrong on subsequent steps, you may find steps executing when you don’t expect them to.
Another thing to consider is that each question is setting a different field in the flow. This is the nature of the Access Requests platform. For example if the Select state is “Vic” then I’m setting the “Select Vic office” field, whereas if I select “NSW‘ in Select state, then I’m setting the “Select NSW office” field. This is different to normal programming practice where each branch would be setting the same field (e.g. State = Vic and StateOffice = “one of the Vic offices”, or State = “NSW” and StateOffice = “one of the NSW offices”). If you want to have a common step in the flow later, you may need to include conditions of all the fields or pass all the fields.
For example if I wanted to call an Okta Workflow with the state and state office, I would need to pass all the possible fields (e.g. Select state AND Select Vic office AND Select NSW office etc.) and let the workflow determine the selected values. This is shown below:
Event though only one state will be selected, so only one state-based office selected, all three state-based offices would be passed to the workflow which would decide which to process.
This concludes the exploration of the feature. If you want more information on calling Okta Workflows from Access Requests, see this article – https://iamse.blog/2023/07/17/oig-access-requests-calling-an-okta-wokflow-from-within-a-request-type/.
Conclusion
This article has shown how Logic on Access Request questions can be used to prompt the user for different information based on earlier selections.
This mechanism is more useful where you need variability in the user interactions. If you want complex logic in the flow (that doesn’t require user interaction) you might be better off calling out to a Workflow to perform the subsequent steps.
