Okta Workflows is a wonderful tool to automate tasks and processes in Okta, and a variety of connectors and tools can be used. In this article we will give an introduction to connectors for frontend.
This is a technical description in a series on Okta Workflows
PART 1: INTRODUCTION TO CONNECTORS FOR FRONTEND
1. Okta Workflows
Without Okta Workflows tasks and processes in Okta had to be handled manually. Delays and inconsistencies due to the human factor would be a consequence.
Not built-in human interaction features
What Okta Workflows in its core is not on the other hand, is a so-called human-interaction workflow engine. With the word “workflow” sometimes the misconception comes along that Okta Workflows is not only for automation, but also for scenarios that some workflow engines designed for that purpose, like ServiceNow, bring along out of the box.
For example, approval workflows or enrichment by human interaction, like a user creation workflow that requires a person to fill in certain fields before the account can be created.
Using the customers' frontend for the automation
However, Okta Workflows might not have human interaction features built in its core, that does not mean that it is not designed to fulfill these requirements as well.
The difference here is that Okta Workflows is designed to use whatever the Okta customer already has within its organization as the frontend for the automation. For that, Okta has pre-configured a wide range of connectors that allow you to easily interact with a frontend, while building the automation with Okta Workflows.
Classic service desk tools, like Jira, Zendesk or ServiceNow, but also standard collaboration tools can be used like Slack, Office 365 Email or Gmail.
2. Service management connectors
Service management tools like ServiceNow, Jira Service Desk or Zendesk always work in some form of tickets, incidents, or other mechanisms. An item is created and maintained for each service request, and will be resolved or closed once that request has been fulfilled.
The Okta connectors for service management tools always offer event cards to capture creation and changes to those items. With that, an Okta Workflow can be triggered based on changes in the tool, without any configuration or customization there.¹
Figure 1 - Example: Jira Service Desk event cards
The options for action cards vary a bit based on how the endpoint manages those tickets and how the usual flow is defined. However, like for the event cards, there is always an option to create and update a ticket/incident. Some additional cards may be present, like “closing”, if that is a different API call in the tool.
The full connector documentation with all available cards can be found in the Okta documentation.
IT Service Manamament (ITSM) tools often have their own options to set and trigger outside API endpoints. This article only describes the options that are available with Okta and the least effort required in the tools. Depending on the use case and environment it might also be a useful option to have the Okta Workflow configured with an API event trigger and call the API endpoint from the ITSM tool.
¹ Apart from the setup of the connection to the endpoint. Usually, there is only a user with sufficient permissions required.
3. Collaboration connectors
If there is no ITSM tool present or the customer requirements dictate a different method of user interaction for the workflow, collaboration connectors like Slack or Office 365 Email can be used.
Using the example of Slack, again the event cards can monitor and trigger a workflow based on a new message in a channel:
Figure 2 - Example Slack Connector event cards
And here again, the same options are available on the action cards. We can send messages to channels or message end users directly to inform or request actions.
Coming back to the introduction: Okta Workflows do not have human interaction or frontend options available in its core. That, however, does not mean that Okta Workflows can’t handle those use cases and that there aren’t options available to easily integrate with frontend systems.
After working with Okta Workflows for some time I rather see this as a benefit than a downside. Yes, there might be occasions where I would wish for a dashboard where the requested person can approve/deny or adjust the workflow. But from a user’s perspective this might not always be the preferred option, because it just adds another dashboard/frontend to the users.
Limiting the systems users are required to use and interact with every day often is key in a successful IT environment. It requires less time to be spent for training and user support and results in minimizing the time the workflow (and with that the requester) waits for a response.
Learn more? Read part 2 about the ServiceNow connector!
In this article you will learn how to make ServiceNow the frontend of user interaction by building a workflow with the ServiceNow connector in Okta Workflows.