OIG Access Requests – Calling an Okta Workflow from Within a Request Type

For some time there has been the ability to trigger a workflow in Okta Workflows from a request flow in Okta Access Requests via events written to the Okta System Log. Events were created for a request being initiated and being closed. But this approach has some limitations, such as a lot of processing within the workflow to determine the request and what to do with it, and also you were limited to running a workflow at the start or end of a request process.

A new more direct and more flexible mechanism has been introduced into the Okta Access Requests platform to allow a specific Okta Workflow to be called at any stage of a Request Type flow. This article explores the integration with an example request for Badge Access to a specific building being performed manually.

The article has the following flow:

Apologies for the length of this article – it has a lot of screenshots.

Note that this integration is currently an early access (EA) feature in Okta preview environments.

Overview of the Integration

The following figure gives a high-level overview of the integration.

The two main components, Okta Access Requests and Okta Workflows (Okta Workforce Identity Cloud, or just Okta, has a minor role to play). Workflows are built in Okta Workflows to implement some business function, such as a manual provisioning activity, sending an email or logging a ticket. These workflows are Delegated Flows (which is how they can be exposed to Access Requests).

A list of available workflows is sync’d to Okta Access Requests in the same way that Okta users, groups and applications are (note the workflows list actually comes from Okta based on some security configuration).

There is a new Action in Access Requests to call a specific Okta Workflow that can be added at any point in the Request Type flow.

The Action will prompt for a set of fields to be populated from data within the Request Type flow. These fields are the same as those in the Delegate Flow card in the workflow. The values passed into these fields can either be:

• One of the standard Request Type attributes of Requester email, Request subject or Request assignee’s email, or
• Any of the fields tied to questions in the flow, such as business justification or end date

There are some constraints:

• The fields passed to the workflow can only be text, number, date-time or true/false. Objects cannot be passed
• Only single values can be passed, so you cannot have say a dropdown in Access Requests with multiple selection and have those values passed as an array
• There is currently no way to pass the request Id across to a workflow
• You cannot return anything from the Workflow into the Request Type flow, this is a one-way execution and the Access Request flow will continue on as soon as it’s called the workflow.

With the above in mind, lets look at how we configure the integration.

Configuring the Integration

There are four sets of activities that need to be configured for this integration:

1. You need a workflow in Okta Workflows that can be called from the Access Requests flow. You could have multiple, but you need one as a minimum.
2. To allow Access Requests to have visibility of the workflows, some role and resource definitions are required in Okta WIC.
3. There is some Access Requests configuration required around teams and configuration lists, and
4. You need an Access Requests flow to call the workflow

These are detailed in the following sections.

For this article we have a sample requirement to implement an access request flow for requesting access to a single building. There is no automatic way to do this, so an email must be sent to the team to perform the request manually and close out the request when finished. This team will be defined as a specific “Team” in Access Requests, so that the email is sent to the team member assigned in Access Requests.

Build a Workflow in Okta Workflows

The first thing we will do is to create a workflow. (Technically you could do it later, but why we do it first will make sense in the next step. It doesn’t have to be perfect yet, but we do need one there.)

The most important thing is that this flow is a Delegated Flow, meaning it is initiated with a Delegated Flow card. This card contains the fields to be passed from the Access Request flow. For this example the flow will consume the requesters email, business justification, the building they requested access to, the assignee email (i.e. the badge access team member automatically assigned this request) and the end data for the extra building access.

The flow steps are up to you, but for this example I have a flow that will lookup the user in Okta to get some name and email details, build up some text then send an email off to the assignee.

Note that it doesn’t matter where in Okta Workflows this workflow is stored. The access to it will be controlled by security policy in Okta and that only relies on it being a Delegated Flow.

Configure Roles and Resources in Okta

We need to create a custom role and resource to allow Access Requests to see the available workflows.

First, you need a new Okta Admin Role for Access Requests to access the delegated flows (like any other user/app who needs to run delegated flows in Okta Workflows). Go to the Roles tab in Administrators, and create a new role with the workflow permission of “Run delegated flow”.

Next, go to Resources and create a new resource set, give it a name, and select the flow you want to allow access to (note that you can also expose all delegated flows which may be easier if you’re only using delegated flows for Access Requests).

Go back to the new Role and edit the assignment to tie the Okta Access Requests OAuth application to the new resource set you created above.

Once you save this, the Access Requests app will be able to see all Okta Workflows you specified in the resource set.

Configure Okta Access Requests

As this is a new integration into Access Requests, there are some initial configuration steps similar to setting up any integration in Access Requests.

I created a new Team for the integration, so people in the badge access team could by dynamically assigned to requests and sent email.

But you could use an existing Team.

If you create a new team you will need to allow it to access Workflows under Settings > Resources.

This new Team must also be able to access any other Resources or Configuration Lists you will use in any Request Type flows assigned to the Team.

For example, if you build a configuration list for a pulldown list, the Team must be assigned to it, like my Buildings list below.

The last thing to consider is the synchronisation of the Workflows list from Okta into Access Requests. This will occur normally on the 24-hour refresh cycle, but you can request an update immediately (it will run in the background).

With this done, you can build a Request Type that calls a workflow.

Build a Flow with a Workflow Action

With the Okta Workflow(s) defined to Access Requests, including them in the flow is basically the same as for any other action.

For this Request Type flow, I’m going to ask the user to supply a justification, select which building they need access to, and select an end date for the access to be removed. I’ll apply a single level of approval – their manager. Then I’ll pass the key information over to an Okta Workflow. The last step in the flow is a Custom Task for the assignee (i.e. the person in the team who will get the email) to come back to the request and close it after they have made the access change.

The Manual Provisioning step is calling an Okta Workflow.

When configuring the Action you select the workflow from the list of available workflows. This will populate the list of fields that the Workflow Delegated Flow card is expecting. In my case there are five fields:

Field	Sourced from
requesterEmail	The Requester email standard attribute in all flows
buildingRequested	Selected from a dropdown list in a Question, which is using a Configuration List
businessJustification	The first Question, a text field
assigneeEmail	The Request assignee’s email standard attribute (i.e. the email of the Team member assigned when the request is raised)
endDate	The last question, a date field

Once Published, this Request Type and associated Workflow is ready to test.

Testing the Integration

To test this, we will initiate the request from a user, get their manager to approve, then check the execution of the workflow and finally close the request out as the assignee.

Requesting Access

The request for building access is initiated in the same way as every other request, in the Access Requests portal or one of the chat interfaces.

The user completes the prompted fields.

When submitted they see the request execution history.

As usual, the manager would be notified by email, chat or if they are in the Access Requests portal, they will see it appear in their list of Requests. They would review and approve.

Workflow Execution

Once approved the action to call the Okta Workflow runs.

The workflow runs, and in this case generates an email to the assignee (they would also get a generic notification from Access Requests to tell them they were assigned a request). You can see in the email body where attribute values from Access Requests have been substituted in.

You could also check the Workflow execution history to see the data passed from Access Requests into the Workflow and how they were used.

Completion

The last step is for the assignee to go back into the request and complete it. As the badge access is an email-driven manual task, you would want to leave the request open until the manual work is done and so having a Custom Task at the end allows for that.

This completes the end-to-end flow.

Conclusion

This article has shown how an Okta Workflow can be run from within an Okta Access Requests flow, adding to the earlier capability of using events in the Okta System Log. It has looked at the integration and what can, and cannot, be passed to a workflow.

The bulk of the article has walked through the configuration and testing of an integrated pair of flows (one Access Request flow calling an Okta Workflow) using the example of a manual badge access request for a building, requiring approval before calling a workflow to send an email to the team managing badge access. This is a trivial example designed to show how the integration works.

Hopefully this all makes sense and you’ll be able to use this article to get your integrations working.