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.
The Okta Access Requests platform allows a specific Okta Workflow to be called at any stage of a Request Type flow or from within a Resource Centric Access Request (RCAR) Approval Sequence. This article explores the integration with an example request for Badge Access to a specific building being performed manually using Request Types.
NOTE: This integration is an early access (EA) feature in Okta preview environments. This can be enabled in the Admin Console under Settings > Features. When this feature is generally available (GA), enabling is automatic.
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 synced (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 be either:
- 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 (such as Okta Actions) cannot be passed.
- 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 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:
- A workflow in Okta Workflows that can be called from the Access Requests flow. Multiple workflows can be configured, but one is required.
- To allow Access Requests to have visibility of the workflows, some role and resource definitions are required in Okta Workforce Identity Cloud.
- There is some Access Requests configuration required around teams and configuration lists.
- An Access Request 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 does not have to be perfect yet, but it does need to be created.
The most important thing is that this flow is a Delegated Flow, which 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 (that is, the badge access team member automatically assigned this request), and the end date for the extra building access.
The flow steps can be customized, but for this example, the flow will look up the user in Okta to get some name and email details, build up some text, and send an email to the assignee.
NOTE: It does not matter where this workflow is stored in Okta Workflows. 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 the 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.
- 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.
- For example, if a configuration list is built for a pulldown list, the Team must be assigned to it, like the Buildings list below.
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 Run a Workflow is enabled.
The last thing to consider is synchronizing 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 for Access Requests, including them in the flow is the same as any other action.
In this example, for this Request Type flow, the user is asked to supply a justification, select which building they need access to, and select an end date for the access to be removed. 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 (for example, 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 calls 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 five fields:
|
Field |
Sourced from |
|---|---|
|
requesterEmail |
The Requester email standard attribute in all flows |
|
buildingRequested |
Selected from a dropdown list in a Question, which uses a Configuration List |
|
businessJustification |
The first Question, a text field |
|
assigneeEmail |
The Request assignee’s email standard attribute (that is, 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 are ready to test.
Testing the Integration
To test this, initiate a user's request, get their manager to approve it, 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 will 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 will review and approve it.
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 badge access request for a building, requiring approval before calling a workflow to send an email to the team managing badge access. This is an example designed to show how the integration works.
Related References
- Okta Access Request - Create an Access Request type
- Resource Centric Access Requests (RCAR)
- Sink your teeth into V2 Access Requests with Okta Workflows
- Okta Workflow Not Executing With V2 Access Requests (RCAR)
- Okta Workflows - See Delegated flows and Build a delegated flow.
- Okta Workflows actions in Access Requests is an Early Access Feature. See Manage Early Access and Beta features to learn how to enable it.
Looking for Okta Identity Governance help? Visit the Okta Identity Governance Product Hub or schedule Office Hours with the Okta Identity Governance team.
