Overview

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 closed. This approach has some limitations, such as a lot of processing within the workflow to determine the request and what to do with it. Also, this approach is limited to running a workflow at the start or end of a request process.

A new, more direct, and 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.
 

Note that this integration is currently an early access (EA) feature in Okta preview environments. This can be enabled in the Admin Console under Settings -> Feature – > ‘Okta Workflows in Access Requests’
 

Overview of the Integration

 

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

The two main components are 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 functions, 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 synced to Okta Access Requests in the same way that Okta users, groups, and applications are synched (note: the workflows list 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 (such as Okta Actions).
• Only single values can be passed, so it is not possible to have a dropdown in Access Requests with multiple selections and have those values passed as an array.
• There is currently no way to pass the request Id across to a workflow.
• Nothing can be returned 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 calls the workflow.

Given the above constraints, the following shows how to configure the integration.

Configuring the Integration

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

1. A workflow in Okta Workflows that can be called from the Access Requests flow. Multiple workflows can be configured, but one is required.
2. To allow workflows to connect to Okta
3. To allow Access Requests to have visibility of the workflows, some role and resource definitions are required in Okta WIC.
4. There is some Access Requests configuration required around teams and configuration lists.
5. An Access Requests flow is required to call the workflow.

These are detailed in the following sections.
 

For this article, the example is based on 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

First, create a workflow. (Technically, this could be done later, but why it is done first will make sense in the next step. It doesn’t have to be perfect yet, but it does need to be created.)
 

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 requester’s 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 date for the extra building access.

Next, add an ‘App Function’, click ‘Okta’, then ‘Create User’. You will need to drag the input from the Dynamic Flow into the Create User card. This will enable the attributes to flow from the Access Request > Dynamic Flow > Create User activity

Note: User activation is set to True, so the contractors rely on the Okta notification when a user is created to invite them to log in. We are not using a Workflow driven notification here, but it is possible to add an Send Email action. 

The flow steps can be customized, but for this example, the flow will obtain the details entered in the Access Request and pass it to the Create User function. 

NOTE: It does not 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. The flow must be enabled to be used in Access Requests Type setup.
 

Configure Roles and Resources in Okta

Create a custom role and resource to allow Access Requests to see the available workflows.
 

First, create a new Okta Admin Role for Access Requests to access the delegated flows (like any other user/app that 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 it should access (Note: All delegated flows can be accessed, which may be easier if using only delegated flows for Access Requests).
 

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

Note: If Okta Access Requests OAuth does not appear in your Application list, disable the Enable Okta Workflows in Access Requests feature, and re-enable. 

Once this is saved, the Access Requests app will be able to see all Okta Workflows 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.
 

In this example, a new Team was created for the integration, so people in the badge access team can be dynamically assigned to requests and sent emails.

An existing team can be used.  If a new team is created, allow it to access Workflows under Settings > Resources.
 

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

The Team must also be added to the Okta connection in the Access Request Console. Navigate to Settings -> Integrations, click ‘Edit Connection’ for the Okta configuration. Ensure the Team is selected and that ‘Run a Workflow’ is enabled.

The last thing to consider is the synchronization of the Workflows list from Okta into Access Requests. This normally occurs on the 24-hour refresh cycle, but an immediate update can be requested. (It will run in the background).

With this done, a Request Type that calls a workflow can be built.
 

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 any other action.
 

In this example. for this Request Type flow, the user is asked to supply a justification, and enter some basic parameters about a new User. A single level of approval, their manager, is applied. The key information is passed 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 return 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, 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 this example, there are eight fields:

Field	Sourced From
requesterEmail	Standard field from the start of the Access Request
email	Access Request (Email for the new Contractor)
primaryPhone	Access Request (Phone number for the contractor)
userType	Access Request (User type within Okta to associate User Profile)
firstName	Access Request (name of the contractor
lastName	Access Request (Last name of the contractor)
manager	Access Request – Name of the person’s manager
expiryDate	Access Request (Custom attribute in Okta that will have auto disable Workflows running on)

Note: If more attributes are to be passed, such as ‘Department’, Add them to the Delegated Flow card, map them to Create Users card, add them to the Workflow Action and add a question into the Access Request

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

Testing the Integration

 

To test this, initiate the request from a user, get their manager to approve, 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 (as the requester)
 

The user completes the prompted fields.

When submitted, they see the request execution history.

As usual, the manager would be notified by email, or 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.
 

When the Approving user views the Access Request in Okta, only they can see the option to Approve or Deny.

Once approved, the Action to run an Okta Workflow is triggered, automatically. We can see the Action has completed successfully, below.

As we are creating Users, we can check Okta Universal Directory to see if the User has been created:

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). In the email body,  attribute values from Access Requests have been substituted in.

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 return to the request and complete it. As the badge access is an email-driven manual task, leave the request open until the manual work is done, and 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 new starter request for the Okta org, requiring approval before calling a workflow to provision the user via the Okta Create Users API. This is an example designed to show how the integration works.