Calling an Okta Workflow From an Okta Access Requests Request Type

Okta Access Requests can call a specific Okta Workflow at any stage of a Request Type flow or from within a Resource Centric Access Request (RCAR) approval sequence. This integration extends beyond Okta System Log event triggers, which only run at the start or end of a request. The integration requires workflow setup, role and resource configuration in Okta, Access Requests team and integration configuration, and request flow design.

Applies To

• Okta Identity Engine (OIE)
• Okta Access Requests
• Okta Workflows
• Request Type flows
• Resource Centric Access Requests (RCAR)
• Delegated Flows
• Early Access feature

How does the Okta Access Requests and Okta Workflows integration work?

Okta Access Requests can call a specific Okta Workflow directly from a Request Type flow. Okta previously supported workflow triggering through System Log events for request initiation and request closure, but that approach requires additional workflow processing to determine the request context and only supports execution at the start or end of the request process.

The integration uses Okta Access Requests and Okta Workflows as the main components. Workflows implement business functions such as manual provisioning activity, sending an email, or logging a ticket. These workflows must use Delegated Flow cards so Access Requests can expose and run them.

A synced list of available workflows appears in Access Requests in the same way that Okta syncs users, groups, and applications. Okta bases the workflows list on security configuration.

Access Requests includes an Action that calls a specific Okta Workflow from any point in the Request Type flow. The Action prompts for fields that map to the fields in the Delegated Flow card. These values can come from:

• The standard Request Type attributes Requester email, Request subject, or Request assignee's email
• Fields tied to questions in the flow, such as business justification or end date

The integration has these 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 returns from the workflow into the Request Type flow. This execution is one-way, and the Access Requests flow continues as soon as it calls the workflow.

The integration requires workflow, Okta, Access Requests, and request flow configuration

The example in this article uses a manual badge access request for a single building. Because no automatic process exists for this request, the workflow sends an email to a team that performs the request manually and closes the request after completion. Access Requests defines that team as a Team so the assigned team member receives the email.

How is the workflow built in Okta Workflows?

Create the workflow first so the later Okta role and resource configuration can reference it. The workflow does not need to be complete at creation time, but it must exist.

Create the workflow as a Delegated Flow and start it with a Delegated Flow card. The Delegated Flow card contains the fields passed from the Access Requests flow. In this example, the workflow consumes the requester email, business justification, requested building, assignee email, and end date.

The flow steps can vary. In this example, the workflow looks up the user in Okta, builds text from user and request details, and sends an email to the assignee.

NOTE: Workflow storage location in Okta Workflows does not matter. Okta controls access through security policy and only requires the workflow to be a Delegated Flow. The flow must be enabled before use in Request Type setup.

How are roles and resources configured in Okta?

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

Create the Okta Admin Role, resource set, and application assignment by following these steps:

1. Go to Administrators and open the Roles tab.
2. Create a new role with the workflow permission Run delegated flow.

3. Go to Resources and create a new resource set.

4. Enter a name and select the flow that the resource set should access.
5. Return to the new Role and edit the assignment.
6. Tie the Okta Access Requests OAuth application to the new resource set.

After saving the assignment, the Access Requests application can see all Okta Workflows specified in the resource set.

How is Okta Access Requests configured for the integration?

Access Requests requires an initial integration setup that is similar to other Access Requests integrations.

Create or reuse the Team, assign resource access, update the Okta connection, and synchronize workflows by following these steps:

1. Create a new Team for the integration, or use an existing team.

2. If a new team is created, allow access to Workflows under Settings > Resources.
3. Allow the Team to access any other Resources or Configuration Lists used in Request Type flows assigned to that team.

4. Assign the Team to configuration lists, such as Buildings, when a question uses that list.

5. Go to Settings > Integrations in the Access Request Console.
6. Select Edit Connection for the Okta configuration.
7. Ensure the Team is selected and Run a Workflow is enabled.

8. Synchronize the workflows list from Okta into Access Requests. This normally occurs on the 24-hour refresh cycle, but Access Requests can request an immediate background update.
   

How is a Request Type flow built with a workflow action?

After the workflow is available to Access Requests, add it to the flow like any other action.

Build the Request Type flow, map the workflow fields, and publish the flow by following these steps:

1. Add questions for justification, requested building, and end date in the Request Type flow.
2. Add a single approval step for the manager.
3. Add an action that calls the Okta Workflow.
4. Add a Custom Task as the last step so the assignee can return to the request and close it after completing the access change.
5. When configuring the action, select the workflow from the list of available workflows.
6. Map the workflow fields to the expected values.
7. Select published to make the Request Type and associated workflow ready for testing.

In this example, the workflow expects these five fields:

How is the integration tested?

Test the integration by initiating the request, approving it, checking workflow execution, and completing the request.

How is access requested?

Initiate the request in the Access Requests portal or one of the chat interfaces.

Complete the prompted fields and submit the request. The request execution history then appears.

The manager receives notification by email or chat, or sees the request in the Access Requests portal, then reviews and approves it.

What happens during workflow execution?

After approval, the action calls the Okta Workflow.

The workflow runs and sends an email to the assignee in this example. Access Requests also sends a generic notification that the assignee received a request. The email body contains substituted attribute values from Access Requests.

Check the workflow execution history to see the data passed from Access Requests into the workflow and how the workflow used that data.

The Assignee Completes the Request After the Manual Work Finishes

Return to the request and complete it after the manual badge access task finishes. Because badge access uses an email-driven manual task, keep the request open until the manual work is complete. The Custom Task at the end of the flow supports that completion model.

This completes the end-to-end flow.

Related References

• 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)
• Delegated flows
• Build a delegated flow
• Manage Early Access and Beta features
• Okta Identity Governance Product Hub
• Office Hours