Okta Workflows
Automate the repetitive identity tasks that fill an IT team's week, without writing a full application. Learn what flows, cards, connectors, and tables are, how a flow actually runs, and how to build automations that are safe, reliable, and easy to maintain.
Think about what happens when a new person joins a company. Someone must create their account. Someone must add them to the right teams. Someone must give them access to email, chat, a ticket tool, and a code tool. Someone must tell their manager that everything is ready. Now think about the day they leave. All of that access must be removed, quickly and without mistakes. In many companies, a tired human does all of this by hand, from a checklist, between other jobs.
Okta Workflows is a tool built to take that checklist off people’s shoulders. It lets you describe each step visually, connect the steps together, and let the system run them every time something happens. You do not need to be a software engineer to use it, though engineers like it too. In this guide we learn it from zero: what it is, the parts it is made of, how a single run works inside, real jobs it can do, how to keep it secure, and how to fix it when it breaks.
1The Big Picture: Why Identity Needs Automation
Before we meet the tool, we need to understand the problem it solves.
The hidden cost of manual identity work
An identity is the digital record of a person: their name, their job, their team, and the apps they can use. Keeping identities correct is a never-ending job. People join, change teams, take leave, and leave. Each change should ripple out to many other systems. When it is done by hand, three things go wrong. The work is slow, so new staff wait days for access. It is inconsistent, because two people follow the checklist in two different ways. And it is risky, because a forgotten step, such as removing an old employee’s access, can leave a door open.
Think of a hotel at check-out time. A front desk worker can walk to every room, collect keys, turn off lights, and tell housekeeping, one room at a time. Or the hotel can use a system: one tap at the desk, and the key card stops working, the room is marked dirty, and housekeeping gets a message. Okta Workflows is that system for people and their access.
The three big jobs of automation
When someone arrives
Create accounts, place people in groups, grant starting access, and send a welcome message.
When someone changes role
Remove access they no longer need, add the access their new role needs, and tell the right people.
When someone departs
Suspend or deactivate accounts, clear sessions, remove access, and record what was done.
When something looks wrong
React to risky events, such as a suspicious sign-in, by notifying staff or locking an account.
These three, joiner, mover, and leaver, are often called the identity lifecycle. Almost every use case you will meet in this guide is a variation of one of these, or a security reaction on top of them.
Automation does not remove the need for rules. It makes your rules run the same way every time. If the rule is wrong, automation will make the wrong thing happen faster. Plan the rule first, then build it.
2What Is Okta Workflows?
A plain definition, where it lives, and who uses it.
The definition
Okta Workflows is a no-code, or low-code, automation platform that is part of the Okta Identity Cloud. You build automations on a visual canvas by placing blocks, called cards, and joining them with lines. Each automation is called a flow. A flow waits for something to happen, such as a user being created, then performs a series of steps, such as adding that user to a group and sending a chat message.
“No-code” means you do not have to write a program to use it. You drag, drop, and fill in fields. “Low-code” means that when you need more power, you can still use small pieces of logic, such as text and list functions, and you can call outside services through web requests. A person who understands the business process can often build a flow without waiting for a developer.
Think of building with toy blocks that click together. Each block does one small thing: one block listens for a doorbell, another turns on a light, another sends a text. You do not make the blocks. You choose them, snap them in order, and the whole thing works. Workflows cards are those blocks.
Where you find it
Workflows has its own console, which an Okta administrator opens from the Okta Admin Console menu. Inside, you see a list of folders and flows, a place for connections, a place for tables, and a history of runs. Access is controlled by Okta admin roles, and Workflows has its own roles for people who may build, who may only run, and who may only view. Exact menu names and plan details change over time, and Workflows is generally licensed as its own part of the Okta product line, so check your own organisation’s plan.
What it is not
- It is not a general programming platform. It is built for event-driven, step-by-step business tasks, not for hosting a full web application.
- It is not a replacement for good identity design. Groups, rules, and policies in Okta still do the main work. Workflows handles the extra steps around them.
- It is not only for Okta. It can talk to many other systems, such as chat tools, ticket tools, and human resources systems, through connectors.
Real-world example: a growing software company
A company hires dozens of engineers each quarter. Previously, the IT team received an email from human resources for every hire and then manually created accounts in several tools. With a flow, the human resources system sends the new hire’s details, Okta creates the user, a flow places them in the right groups, opens a ticket for their laptop, and posts a message to the manager’s chat channel. The IT team now only handles the exceptions.
3The Core Vocabulary
Ten words explain nearly everything in Workflows. Learn these and the rest feels familiar.
Flow
One automation. It starts with an event and holds a chain of cards. Each flow does one clear job.
Card
One block on the canvas. It does a single task, such as “find user”, “send message”, or “join text”.
Event card
The first card in a flow. It listens for something to happen, or for a time to arrive, and starts the flow.
Action card
A card that asks another system to do something, such as create a user or post a message.
Function card
A card that works on data inside the flow itself, such as joining two pieces of text or comparing two numbers.
Connector
A ready-made kit for one outside service, such as Okta or a chat tool. It supplies the cards for that service.
Connection
A saved, signed-in link to one account on a service. A connector is the kit. A connection is your key to it.
Table
A small built-in spreadsheet for keeping information between runs, such as which users were already processed.
Helper flow
A flow that another flow calls, so that common steps are written once and used in many places.
Folder
A container that groups related flows, tables, and helper flows. It is also the unit you export and import.
A flow is like a recipe. The event card is “when the guests arrive”. Function cards are the kitchen steps you do yourself, such as chopping and mixing. Action cards are the steps you ask someone else to do, such as the baker who prepares the bread. The table is the notebook on the counter where you write down what you have already served.
Connector versus connection
These two words are often mixed up. A connector is available to everyone. It is simply the set of cards for a service. A connection is yours. It holds the permission you gave Workflows to act on that service, using a particular account. You can have many connections to the same connector. For example, a company might keep one connection to its chat tool for sending ordinary messages, and another, with stronger permission, for an administrative task. Keeping them separate follows the idea of giving each job only the access it needs.
The same word, “flow”, is used for both a whole automation and the line of cards inside it. In this guide, a flow always means one complete automation, from event to last card.
4Architecture and Components
Let us see the whole system at once, from the thing that happens to the thing that gets done.
flowchart LR
subgraph SRC["Sources of Events"]
E1["Okta Events - user created, group change"]
E2["Schedule - daily or hourly"]
E3["API Endpoint - called by another system"]
E4["Delegated Run - started by an admin"]
end
subgraph WF["Okta Workflows Platform"]
Q["Event Intake and Queue"]
X["Flow Execution Engine"]
T["Workflows Tables"]
H["Execution History"]
C["Connections Vault"]
end
subgraph TGT["Connected Services"]
O["Okta APIs"]
S["Chat Tool"]
J["Ticket Tool"]
HR["HR System"]
W["Any Web API via Custom Connector"]
end
E1 --> Q
E2 --> Q
E3 --> Q
E4 --> Q
Q --> X
X T
X --> H
X --> C
C --> O
C --> S
C --> J
C --> HR
C --> W
Component by component
Event sources are the reasons a flow starts. Some come from Okta, for example a user being created or added to a group. Some come from a clock, which is a schedule. Some come from another system that calls a special web address belonging to the flow. And some are started by a person, such as a help desk worker using a delegated run.
The intake and queue catch each event and line it up for processing. This matters because many events can arrive at once, such as when a hundred new staff are created on the same morning. The queue keeps them in order and prevents loss.
The execution engine takes one event at a time, finds the flow it belongs to, and runs the cards in order, passing data from each card to the next. It also decides what to do when a card fails.
Tables are the engine’s memory between runs. A flow can write a row, read it later, and update it. Execution history is the record of what ran, what data went in, what came out, and whether it succeeded. The connections vault holds the saved permissions to other services, so the flow never contains passwords in plain sight.
Connected services are the systems the flow reads from or changes. Okta itself is one. Others are reached through connectors, and anything with a web interface, called an API, can be reached by building a custom connector.
When you design a new automation, first draw this same picture on paper for your case: what event starts it, what memory it needs, and which services it must touch. A clear picture before building avoids tangled flows later.
5The Three Kinds of Cards
Every flow is built from three kinds of cards. Knowing which is which helps you read any flow quickly.
| Kind | Job | Talks to outside services? | Examples in plain words |
|---|---|---|---|
| Event | Starts the flow | Listens to them | User created, user added to a group, run every day at nine |
| Action | Does something in another system | Yes | Create user, add to group, send message, create ticket |
| Function | Works on data inside the flow | No | Join text, compare numbers, find a value in a list, format a date |
Event cards
Every flow has exactly one event card, and it must come first. The card also produces the first pieces of data, called outputs. For a “user created” event, those outputs include the user’s identifier and details about the user. All later cards can use these outputs.
Action cards
Action cards are where the flow changes the world. Because they touch other systems, they can fail for reasons outside your control, such as a service being busy or a permission being missing. Many action cards come in pairs, such as “Read user” and “Update user”, or “Find” and “Create”, which lets a flow check before it changes anything. This habit of checking first is very useful and we return to it in the best-practices chapter.
Function cards
Function cards are the flow’s own tools. There are groups for text, numbers, true-or-false values, dates and times, lists, and objects, plus a group of logic and flow-control cards. They run inside Workflows, are fast, and do not need a connection.
In a restaurant, the doorbell that tells the kitchen “a table has arrived” is the event. The cook who chops vegetables without leaving the kitchen is a function. The waiter who goes to the cellar for wine is an action, because it reaches outside the kitchen and may fail if the cellar door is locked.
Inputs and outputs
Each card has input fields on its left and output fields on its right. You fill an input either by typing a fixed value or by dragging a line from an earlier card’s output. This line is the way data moves through the flow. A card can only use data from cards that sit earlier in the chain, which keeps the logic easy to follow from left to right.
Typed values are fixed forever, which is fine for a message title but dangerous for things like a group identifier that differs between your test and live environments. Where a value might change, store it in a table or pass it in, so it can be changed in one place.
6Data Types and How Data Moves
Cards pass data to each other. Each piece of data has a type, and getting the type right avoids most beginner errors.
Text
Words and characters, such as a name or an email address. Even a phone number is usually kept as text.
Number
A value you can add, subtract, and compare, such as a count of days or a number of users.
True or false
A yes-or-no answer, often used to decide which path a flow should take.
Date and time
A point in time. You can add days, compare two dates, or format a date for a message.
List
An ordered collection of items of one type, such as all the groups a user belongs to.
Object
A bundle of named values, like a filled-in form. A user record is an object, with a name field, an email field, and so on.
Why types matter
A card that expects a number cannot use text such as “twelve”. A card that expects a list cannot use a single item. When types do not match, the flow shows an error before or during the run. Workflows lets you convert between types with function cards, for example turning a number into text so it can be placed inside a message, or turning a text date into a date and time value so that two dates can be compared.
Objects and lists in everyday use
Most of the data you receive from other systems arrives as an object. A user object might hold the first name, last name, email, department, and manager. To use one piece, you use a card that gets a value from an object by its name. Many flows also use lists, for example “all members of this group”. A list can be walked through, one item at a time, using a loop, which we meet in the flow-control chapter.
An object is like a filled-in paper form, where each box has a label. A list is a stack of such forms. To read one answer from a form, you look at the box by its label. To deal with the whole stack, you pick up the forms one at a time. Types are the rule that you cannot put a letter in a box meant for a number.
Empty values
Sometimes a field is empty. A new user may have no manager yet. A card that reads that value gets “nothing”, and a later card may fail if it expects real text. Good flows check for empty values first, using logic cards, and decide what to do: skip the step, use a default, or stop and tell someone.
Real-world example: formatting a welcome message
A flow receives a user object. One function pulls out the first name. Another joins the first name with a greeting text. A date function formats the start date into friendly words. Finally an action card sends the finished text to the manager in a chat tool. Four small steps, each doing one thing, make a message that looks written by hand.
7Building Your First Flow, Step by Step
A tiny but real example: when a new user is created in Okta, send a welcome note to a chat channel.
Create a folder and a flow
In the Workflows console, make a folder with a clear name, such as “Onboarding”. Inside it, create a new flow and give it a name that says what it does, such as “Welcome message for new user”.
Pick the event card
Choose the Okta connector and select the event for a user being created. If this is your first time, the console asks you to make a connection to Okta, signing in with an administrator account and approving the permissions it needs.
Read more about the user
The event gives you a few basic facts. Add an action card that reads the full user record, so you can see their department and manager.
Prepare the message
Use text function cards to join the first name, a greeting, and the department into a single sentence. Fill each field by dragging lines from earlier outputs.
Add the action
Add an action card from your chat tool’s connector that posts a message to a channel. Link your joined text to its message field and choose the channel.
Test with sample data
Use the test option to run the flow with real or sample data. Click each card to see exactly what went in and what came out. Fix anything that looks wrong.
Turn it on
A flow only listens for real events once it is switched on. Turn it on, create a test user, and watch the run appear in the history.
What to notice
Three ideas show up in this tiny example, and they appear in every flow you will ever build. First, data flows left to right along lines you draw. Second, testing is built in, so you can see each card’s inputs and outputs before anything goes live. Third, a flow has an on and an off state. A flow that is off never starts, no matter what happens in your systems. A common mistake is building a perfect flow and forgetting to switch it on.
Setting up a flow is like setting up a motion-sensor light. You choose the sensor (the event), choose the light (the action), test it by waving your hand, and finally flip the switch to arm it. Until the switch is flipped, the light stays dark whatever you do in the hallway.
Always build and test in your Okta preview or test organisation first, with test users and a test chat channel. Only after the flow behaves well should you copy it to your live organisation, where a mistake affects real people.
8Internal Working: How a Flow Runs
What actually happens between “a user was created” and “the message appeared in chat”?
sequenceDiagram
autonumber
participant OK as Okta
participant EN as Workflows Engine
participant TB as Table
participant CH as Chat Tool
participant HI as Run History
OK->>EN: Event - user created with basic details
EN->>EN: Find the flow that listens for this event
EN->>OK: Action - read the full user record
OK->>EN: User details returned
EN->>EN: Function cards build the message text
EN->>TB: Check whether this user was already welcomed
TB->>EN: Not found
EN->>CH: Action - post the message
CH->>EN: Success and message identifier
EN->>TB: Write a row to record the welcome
EN->>HI: Save inputs, outputs, and final status
Step by step
The event arrives
Okta tells Workflows that something happened. The event is placed in a queue so it is not lost, even if many arrive together.
The engine picks the flow
The engine looks for flows that are switched on and listen for this kind of event. If several flows listen, each one runs on its own, as a separate run.
Cards run in order
The engine runs the first card after the event, waits for its outputs, and passes them to the next card. Action cards wait for the other system to answer.
Branches and loops decide the path
Flow-control cards can send the run down one branch or another, or repeat steps over a list. Only the chosen path runs.
The run ends and is recorded
When the last card finishes, or a card stops the run or fails, the engine records the result. You can open the run later and inspect every card.
Runs are independent
Each event produces its own run, and runs do not share data unless they write to a table. This is a helpful rule. Two new users created at the same moment will each get their own run with their own data, and one cannot overwrite the other’s values by accident. When flows must share information, a table is the safe place for it.
Runs may take time
Most flows finish in seconds. But a flow may also wait: for a slow external system, for a delay you added on purpose, or for a rate limit to clear. Workflows is built for tasks that tolerate a short delay. It is not meant for work that must answer a person instantly while they stare at a screen.
Workflows is not strictly a “run exactly once” system under every possible failure. Events can occasionally be delivered more than once, or a run can be retried. This is why careful builders check whether a job was already done before doing it again, a habit explained later as idempotency.
9Ways to Start a Flow: Triggers
A flow starts for one of a few reasons. Choosing the right start decides how responsive and how reliable your automation is.
| Trigger | Starts when | Best for | Watch for |
|---|---|---|---|
| Okta event | Something happens in Okta, such as a user being created or a group changing | Reacting right away to identity changes | Several events can arrive in a burst |
| Scheduled | A clock time or interval arrives | Daily clean-ups, reports, and checks | Large result lists need careful looping |
| API endpoint | Another system calls the flow’s web address | Linking systems that cannot send Okta events | Protect the address like a password |
| Delegated run | A permitted person starts it from a button | Help desk tasks, such as reset steps, with controlled rights | Limit who may run it |
| Called by another flow | A parent flow calls it as a helper | Reusing common steps | Keep inputs and outputs clear |
Event-driven versus scheduled
An event-driven flow reacts the moment something happens. This is the fastest way to give a new hire access. A scheduled flow wakes up on a timer, looks around, and acts on what it finds. This suits jobs such as “every night, find users who have not signed in for ninety days”. Many strong designs use both: events for speed, and a scheduled sweep as a safety net that catches anything the events missed.
An event-driven flow is a doorbell: someone arrives, and it rings at once. A scheduled flow is a night guard doing rounds at fixed times. A good building uses both. The doorbell handles visitors quickly, and the rounds make sure nothing was missed.
API endpoint flows
Some systems cannot send events in Okta’s format, but they can call a web address. Workflows can give a flow its own address, called an API endpoint, so an outside system can start it and pass in data. The address contains a secret, so treat it as a password, and where the platform supports it, add extra checks on who may call it.
Delegated flows
Some jobs need an administrator’s power but should be run by someone without full admin rights. A delegated flow is a flow that appears as a button for chosen people. They click, fill in a few fields, and the flow runs with its own saved connection. A help desk worker can then trigger “re-enable this user” without receiving the right to change anything else. The power stays inside the flow, and the flow is limited to one clear job.
Real-world example: a nightly safety net
A company reacts to “user deactivated” events to remove access in connected tools. But once, a connected tool was down at that moment. The team added a scheduled flow that every night lists deactivated users and checks the tool again. Any account still active gets removed and reported. The event handles the usual case quickly, and the schedule catches the rare failure.
10Flow Control: Decisions, Loops, and Helpers
Real tasks are rarely a straight line. Flow control cards let a flow choose, repeat, wait, and recover.
flowchart TD
A["Event - user updated"]
B["Read user record"]
C{"Department changed?"}
D["Stop - nothing to do"]
E["Get list of old department groups"]
F["For each group - remove the user"]
G["Add user to new department group"]
H{"Any step failed?"}
I["Notify IT team with details"]
J["Notify the manager - access updated"]
A --> B
B --> C
C -->|no| D
C -->|yes| E
E --> F
F --> G
G --> H
H -->|yes| I
H -->|no| J
The main control tools
If and else
Sends the run down one branch when a condition is true and another when it is false.
Continue if
Stops the run quietly when a condition is not met. It is a simple guard at the start of a flow.
For each
Takes a list and runs the same steps once for every item, such as every group a user belongs to.
Delay
Pauses the run for a set time, useful when another system needs a moment to catch up.
Error handling
Catches a failure so the flow can notify someone, try another path, or clean up instead of simply stopping.
Helper flows
A flow called from other flows to perform a shared job, such as sending a standard alert.
Guards at the top
One of the best habits is to place a guard right after the event. For example, an “updated user” event fires for every kind of change, including a changed phone number. A guard card checks whether the department actually changed, and stops the run if it did not. Without this guard, the flow would repeat its work, or even cause harm, for changes it was never meant to handle.
Helper flows keep things tidy
If five flows each need to send an alert to the security channel, do not build the same five cards five times. Build one helper flow called “Send security alert”, and let the five flows call it, passing in the message. When the channel changes, you fix one place. This is the same idea as a shared tool in a workshop: made once, borrowed by many.
A flow with decisions and loops is like a mail sorter. A decision is “is this letter for the local area?”. A loop is “do this for every letter in the tray”. A guard is the first check that throws out junk mail before it enters the system. Error handling is the bin where damaged letters go, with a note to a supervisor.
Loops can multiply work. A loop over ten thousand items that calls another system once per item may run into rate limits or take a long time. Where possible, narrow the list with a filter first, and test a loop on a small sample before turning it on for everyone.
11Tables: Giving Flows a Memory
By default, each run forgets everything when it ends. Tables are the place to keep what must be remembered.
What a table is
A Workflows table is a small, built-in spreadsheet. It has columns with names and types, and rows of data. Flows can add a row, find a row, update it, delete it, or read all the rows. Because it lives inside Workflows, it needs no outside database and no connection to set up. You can also view and edit it by hand in the console, and import or export rows as a file.
A table is like the notebook that a night guard keeps by the desk. Each time something happens, the guard writes a line. Before doing a task, the guard checks the notebook to see if it was already done. Without the notebook, the guard would have to rely on memory, and forget by morning.
Common uses
Remember what was done
Record each user that was already welcomed, so a repeated event does not send a second message.
Settings in one place
Store values such as channel names, group identifiers, and number of days, so changing a setting means editing a row, not a flow.
Track a process
Hold the state of a multi-step request, such as “waiting for manager approval”, so a later flow can continue it.
Build a report
Add a row for each action taken, then export the table as a record for auditors.
Mapping data
Translate one system’s values into another’s, such as job titles into group names.
Queue work
Collect items from many runs, then have a scheduled flow process them in a batch.
Habits for healthy tables
- Choose one column as the unique identifier, such as the Okta user identifier, and search by it.
- Do not store secrets such as passwords or tokens in a table. Tables are for data, not for credentials.
- Be careful with personal details. Store only what the flow needs, and clean old rows on a schedule.
- Give columns clear names and the correct types, so that functions like comparing and sorting behave correctly.
- Remember that tables have size limits, which depend on your plan, so remove rows you no longer need.
Real-world example: avoiding double messages
A flow welcomes each new user in chat. Occasionally, the same event arrives twice. The team added a table of welcomed user identifiers. The flow first searches the table, and if it finds the user, it stops. If not, it sends the message and adds a row. Duplicate events are now harmless, and the chat channel is no longer spammed.
12Connectors, Connections, and Custom Connectors
Workflows becomes powerful when it reaches beyond Okta. This chapter explains how it talks to other tools.
The catalogue of connectors
Okta provides a large catalogue of prebuilt connectors for popular services, including chat and email tools, ticket and service desk tools, cloud storage, human resources systems, customer relationship systems, and more. Each connector supplies cards for that service’s common tasks. The list grows over time, so check the catalogue inside the console for what is available today.
How a connection is made
Choose a card from a connector
The first time you use a card from a service, Workflows asks you to create a connection for it.
Sign in and approve
You sign in to the service with an account and approve the permissions. Most services use a safe approval method where you never hand over a password to Workflows.
The connection is saved
The permission is stored in the connections vault, under a name you choose. Every card from that connector can now use it.
Reuse and review
Many flows can share a connection. Review the list of connections regularly and remove ones that are no longer needed.
When there is no connector
If a service has no prebuilt connector, you have two choices. You can use a generic card that sends a web request to that service’s API and handle the answer yourself. Or you can use the API Connector Builder, a guided tool inside Workflows that lets you describe the service’s web addresses, how to sign in, and what each call needs. It then creates your own connector with your own cards, which you and your team can reuse like any prebuilt one. This is how a company can link a small in-house system, or a niche tool, into its identity automations.
Prebuilt connectors are like power adapters sold for common countries: pick the one that fits and plug it in. The API Connector Builder is like a workshop where you craft an adapter for a rare socket. Once made, it is just another adapter in your drawer.
Choosing the right account for a connection
A connection acts with the power of the account that approved it. If an administrator with full rights makes the connection, then every flow using it can do anything that administrator can. A safer way is to create a dedicated service account, a non-human account just for Workflows, with only the permissions the flows need. If that account is ever misused, the damage is limited, and the audit trail shows clearly which actions came from automation.
Name connections after their purpose and environment, such as “Chat – welcome messages – test”. When something fails at midnight, a clear name tells you at once which account and which system are involved.
13Real-World Use Cases
Here are the jobs that teams most often give to Workflows, grouped by what they achieve.
Lifecycle automation
Joiner: faster first day
When the human resources system marks someone as hired, a flow creates or activates their Okta user, adds them to groups based on department and location, opens a ticket for equipment, and sends their manager a checklist. The new hire can sign in on day one to find the tools ready.
Mover: access that follows the job
When a user’s department or title changes, a flow removes the groups from the old role and adds those for the new role. It tells the manager what changed. This prevents “access creep”, where people collect more and more rights over the years because nobody removes the old ones.
Leaver: clean and complete exit
When a user is deactivated, a flow clears their sessions, removes them from connected tools, transfers files or ownership to their manager, and records everything in a table for auditors. Because the same steps run each time, nothing is forgotten.
Housekeeping and governance
Inactive account clean-up
A scheduled flow lists users who have not signed in for a set number of days, warns them and their managers, and, after a grace period, suspends the account. This reduces the number of forgotten accounts that attackers could use.
Access reviews and reminders
A flow finds people in sensitive groups, asks their managers to confirm the access is still needed, and removes it if no answer arrives in time. The table holds the state of each request.
Temporary access
A person is added to a group for a set number of days. The flow records an end date in a table, and a scheduled flow removes the person from the group when the date passes, so temporary never becomes permanent.
Security response
React to risky events
When a security event appears, such as a user reporting suspicious activity, a flow can clear that user’s sessions, post an alert to the security channel, and open an incident ticket with the details. Humans then focus on judging the case instead of copying data between tools.
Alert on admin changes
When someone is added to a powerful administrator group, a flow immediately notifies the security team with who made the change. Unexpected changes are noticed in minutes, not months.
Chat tools
Send alerts, welcome notes, and approval requests where people already work.
Ticket and service desk tools
Open, update, and close requests so there is a human-readable record.
HR systems
Use hire, change, and exit dates as the true source of lifecycle events.
Email and calendars
Notify managers and users, and schedule check-ins.
Many of these jobs can also be done in other ways, such as with group rules inside Okta itself. A good rule of thumb: use built-in Okta features for what they handle well, and use Workflows for the extra steps and the connections to other tools.
14End-to-End Example: Onboarding a New Employee
Let us follow one complete story, from the hiring decision to a ready workstation, and see which parts are flows and which are other systems.
sequenceDiagram
autonumber
participant HR as HR System
participant WA as Intake Flow
participant OK as Okta
participant WB as Setup Flow
participant TK as Ticket Tool
participant CH as Chat Tool
participant TB as Audit Table
HR->>WA: New hire record sent to the flow endpoint
WA->>WA: Check required fields and clean the data
WA->>OK: Create user with profile details
OK->>WA: User created
OK->>WB: Event - user created
WB->>OK: Add user to department and location groups
WB->>TK: Open equipment request
WB->>CH: Tell the manager the account is ready
WB->>TB: Record each step with the time
WB->>OK: Mark onboarding complete in a profile field
Why two flows?
The story uses two flows that each do one job. The intake flow receives data from the human resources system, checks it, and creates the user. The setup flow listens for the “user created” event, whatever created the user, and does everything that follows. Because the setup flow reacts to the event, it also works when a person creates a user by hand in the Okta console. Separating the two keeps each flow short, readable, and reusable.
What happens when things go wrong
- Missing data: if the hire record has no department, the intake flow stops, posts a message to the human resources team naming the missing field, and records the case in the table.
- User already exists: the flow finds the existing user first, and updates it instead of creating a duplicate.
- The ticket tool is down: the setup flow notes the failure in the table, notifies IT, and a scheduled flow retries later.
- Wrong group name: the lookup table has no match, and the flow alerts an administrator rather than guessing.
Think of a relay race. The first runner (intake flow) takes the baton from the starting line and hands it over at a fixed point. The second runner (setup flow) does not care who carried the baton before. It only needs to receive it. Clean hand-offs make a team faster and make a dropped baton easy to trace.
Real-world pattern: the source of truth
Large organisations treat the human resources system as the source of truth for who works there, and Okta as the system that grants access. Flows sit in between, translating “hired”, “changed role”, and “left” into identity actions. When the source of truth is clear, there is no argument about which system is right when two disagree.
15Data Flow and the Life of a Flow
A flow is a piece of software, even if it looks like a picture. It needs a life cycle: design, build, test, release, watch, and improve.
flowchart LR
A["Design the rule on paper"]
B["Build in the test org"]
C["Test with sample users"]
D["Review by a second person"]
E["Export the folder"]
F["Import into the live org"]
G["Switch on and watch"]
H["Monitor history and alerts"]
I["Improve and repeat"]
A --> B
B --> C
C --> D
D --> E
E --> F
F --> G
G --> H
H --> I
I --> B
Stage by stage
Design
Write the rule in a sentence: “When X happens, do Y, unless Z.” Name the owner, the systems touched, and what a failure should do.
Build and test
Build in a test or preview organisation. Use test users and test channels. Inspect each card’s inputs and outputs.
Review
Ask another person to read the flow like a story. Fresh eyes spot missing guards and risky actions.
Promote
Export the folder as a package file and import it into the live organisation. Then set up live connections and settings, because connections do not travel inside the package.
Release carefully
Turn it on and watch the first runs closely. Start with a small group if you can.
Operate and improve
Watch the history, answer alerts, and update the flow when the business rule changes. Keep notes on what changed and why.
Moving flows between organisations
A folder can be exported as a single package, and imported into another Okta organisation. The package holds the flows and the structure of the tables. It does not hold your saved connections, because those are tied to accounts and secrets. After import, you attach live connections to each card that needs one and check any values that differ in the live environment, such as group identifiers. This is why storing environment-specific values in a settings table is so valuable.
Shipping a recipe from a test kitchen to a restaurant is like exporting a folder. The recipe card travels, but the restaurant must use its own ovens and its own suppliers. The connections are the restaurant’s own suppliers. They must be set up on arrival.
Editing a live flow directly is like repairing a plane in flight. A small slip can send wrong messages or remove the wrong access to real people. Make changes in the test organisation, test them, and promote them, even for tiny edits.
16Security: Automation With Great Power
A flow can create users, change groups, and remove access. That is exactly why it must be built and guarded with care.
Think of a flow as a very fast employee
A flow does what it is told, instantly, and never gets tired. If told to do something unsafe, it will do it a thousand times in a minute. Treat each flow with the same care you would give to a new administrator: limited rights, clear instructions, and someone watching.
A master key opens every door. Giving it to a loyal robot makes the building run smoothly. But if a stranger can give the robot orders, or if the robot makes a mistake, the master key opens every door the wrong way. Security for flows means keeping the key small, keeping the orders honest, and keeping a log of every door opened.
The main safeguards
Do
- Use dedicated service accounts for connections, with only the rights the flows need.
- Give Workflows roles only to people who need to build, run, or view.
- Keep test and live environments separate, and promote through review.
- Protect API endpoint addresses like passwords, and rotate them if shared by mistake.
- Limit delegated flows to named groups and to one narrow task each.
- Ask for human approval before very sensitive actions, such as removing an administrator.
Do not
- Connect with a personal super-administrator account.
- Store passwords, tokens, or keys in tables, notes, or card fields.
- Trust input from outside systems without checking its format and values.
- Let one flow do unrelated jobs, which makes its rights hard to limit.
- Leave unused flows and connections switched on.
- Send personal data to a tool that does not need it.
Input is not always honest
If a flow starts from an outside system through an API endpoint, anyone who learns the address could try to send data. The data may be wrong, or even crafted to cause harm, such as asking the flow to add a user to an administrator group. Check that fields exist, have the expected type, and contain allowed values. Map outside values to a fixed list in a table rather than using them directly as group names.
Privacy and the run history
Run history shows what data went through each card. That is excellent for debugging, but it means personal details such as names and email addresses are visible to people with access to the history. Limit who can view history, avoid passing more personal data than needed, and understand how long your organisation’s plan keeps the history.
Auditing
Changes made by flows appear in the Okta system log under the identity of the connection that made them. Using a clearly named service account makes it easy to tell automated changes from human ones. Combine this with the table of actions your flow writes, and you have a strong trail for auditors.
Before adding any card that removes access or deactivates people, add a safety check: a limit on how many users can be changed in one run. If a mistake or an attack triggers a thousand removals, the check stops the flow and alerts a person after the first few.
17Monitoring, Logging, and Troubleshooting
Every automation fails sometimes. What matters is how quickly you notice, and how clearly you can see why.
Where to look
Execution history
Lists every run with its start time, status, and duration. Open any run to see the data at each card.
Flow-level status
Shows whether a flow is on, off, or has errors, and lets you filter runs by outcome.
System Log
Records the actions taken in Okta, including those made by flows, with the actor and the target.
Audit table
A table that your own flows write to, so you can see business-level results, such as “welcome sent”.
A calm way to troubleshoot
Did the flow start?
Check that it is switched on, and that the event really happened. If there is no run at all, the problem is before the flow.
Where did it stop?
Open the failed run and find the first red card. Everything after it may be only a result of that failure.
What was the input?
Look at the data the failed card received. Empty values and wrong types are the most common cause.
What did the service say?
Read the error message from the outside service. It often names the exact missing permission or invalid field.
Fix, test, and re-run
Fix one thing at a time, test with sample data, and, where safe, re-run the failed case.
Common problems and likely causes
| What you see | Likely cause | What to do |
|---|---|---|
| Flow never runs | Flow switched off, or the event did not occur | Turn it on and confirm the event in the Okta log |
| Card shows a permission error | The connection’s account lacks the right | Grant the minimum missing permission or reauthorise |
| Connection error after weeks of working | Token expired, or the account password or settings changed | Reauthorise the connection and note its owner |
| Type or empty value error | A card received nothing, or the wrong type | Add a guard for empty values and convert types |
| Message sent twice | Duplicate event or overlapping flows | Check a table before acting, and review all flows on that event |
| Run is slow or delayed | Rate limits or a loop over a large list | Filter the list first and spread the work out |
| Works in test, fails live | Different group identifiers or settings | Move such values into a settings table |
Alerting yourself
Do not rely on remembering to look at history. Add error handling to the important flows so that when a card fails, a helper flow posts a message to a team channel with the flow name, the user concerned, and a link to the run. Also consider a scheduled flow that counts recent failures and warns if the number is high. Fast alerts turn silent failures into small, quick fixes.
Run history is not kept forever. If you need to prove what happened months later, write the key facts to your own audit table or to a log system, rather than relying on the history alone.
18Performance, Scalability, and Reliability
Flows that work for ten users should also work for ten thousand. A few ideas make that possible.
Limits you should expect
Workflows is a shared cloud service, and it has limits to keep it fair for all customers. There are limits on how many runs can start in a short time, how long a single run may last, how much data a card can handle, and how large tables may grow. The other services you call have limits too, called rate limits, which control how many requests you can make per minute. Okta’s own web interfaces have rate limits. When a flow hits a limit, calls may be slowed or refused for a short time, and the flow must be able to cope. Exact numbers differ by plan and change over time, so read the current documentation for your organisation.
Rate limits are like the speed limits on a road. Everyone can use it, but nobody may go faster than the limit. A driver who ignores the sign will be stopped and slowed down for everyone. A good builder plans the journey for the speed the road allows.
Habits that scale
- Filter early: narrow a list before looping, so you only handle what you must.
- Avoid unneeded calls: read a user once and reuse the result, instead of reading again in every card.
- Spread large jobs out: process big batches in smaller pieces, using a table as a queue and a scheduled flow to work through it.
- Keep flows small: a flow of a few dozen cards is easier to run and debug than one with hundreds. Use helper flows.
- Handle retries calmly: if a service says “too busy”, wait and try again later rather than hammering it.
Idempotency: safe to repeat
An action is idempotent if doing it twice has the same result as doing it once. “Add this user to the group” is idempotent: the second time, the user is already in the group. “Send a welcome message” is not: the second time, the user gets two. When a run might repeat, make each step idempotent, or protect it with a check in a table. This single habit removes a large share of production surprises.
Reliability when other systems fail
| Failure | Effect | Good response |
|---|---|---|
| Outside tool unavailable | Action cards fail | Record the work in a table and retry on a schedule |
| Connection expires | All cards using it fail | Alert the owner and reauthorise |
| Burst of events | Runs queue up and take longer | Accept delay, avoid heavy steps, and check limits |
| Bad data from source | Wrong or empty values reach cards | Validate at the start and stop early |
| Flow changed by mistake | Behaviour changes for everyone | Limit edit rights and keep exported backups |
Do not design a flow so that a person is stuck unable to work if the flow fails. Keep a manual fallback for critical steps, such as a documented way for the help desk to complete onboarding by hand.
19Design Patterns and Anti-Patterns
Teams that use Workflows for years keep returning to the same few shapes. Learning them saves you from reinventing, and from repeating well-known mistakes.
Patterns worth copying
Guard first
Put a check right after the event so the flow stops at once if the change is not one it should handle.
Check, then act
Read the current state before changing it. If the user is already in the group, skip the step.
Settings table
Keep channel names, group identifiers, and day counts in one table so a change never needs a flow edit.
Event plus safety sweep
React to events for speed, and run a scheduled flow that finds anything the events missed.
Helper flows
Wrap common jobs, such as alerts and logging, in a helper flow that every other flow calls.
Audit row for every action
Write a row in a table whenever a flow changes something important, with who, what, and when.
Approval step
For sensitive changes, send a request to a manager or owner, record the answer in a table, and continue only on approval.
One flow, one job
Keep each flow focused on a single purpose with a clear name, so rights and testing stay simple.
Anti-patterns to avoid
The habit
One giant flow tries to handle joiners, movers, leavers, and alerts, with dozens of branches.
Why it hurts
Nobody can read it, a small edit can break unrelated paths, and a single failure stops everything. Its connection needs the combined power of every task.
Do this instead
Split by purpose. Use small flows with helper flows for shared steps, and give each its own limited connection where practical.
The habit
Group names, channel names, and other fixed values are typed straight into cards, and edited live when they change.
Why it hurts
Values differ between test and live, so promotion breaks flows. Updating ten flows by hand is slow and invites mistakes.
Do this instead
Store such values in a settings table, and read them at the start of each run.
The habit
A flow removes access or deactivates users with no limit, no guard, and no alert, because “the rule is simple”.
Why it hurts
A wrong rule, a bad data feed, or an attack can remove access from hundreds of people in minutes, and nobody notices until work stops.
Do this instead
Add a guard, cap the number of changes per run, and send an alert whenever the cap is hit.
The habit
Everything is connected with one personal administrator account, and the person who made it later leaves the company.
Why it hurts
When that account is disabled, every flow fails at once. Meanwhile, the connection had far more power than any flow needed.
Do this instead
Use dedicated service accounts with minimal rights, and record an owner for every connection.
20Best Practices and Common Mistakes
A practical checklist to use every time you design a new automation.
Before you build
- Write the rule in one sentence, with the event, the action, and the exception.
- Decide who owns the flow, who reviews it, and who gets the alerts.
- Check whether Okta’s built-in features already do part of the job.
- List every system the flow touches, and the minimum permission each needs.
- Decide what a failure should do, and what the manual fallback is.
While you build
- Name flows, folders, cards, and connections clearly. Add short notes on cards that are not obvious.
- Place guards at the top, and check for empty values before using them.
- Read before you write, and check before you change.
- Keep settings in tables and shared steps in helper flows.
- Use error handling on every card that reaches an outside system and could fail.
- Test with real-looking edge cases: a user with no manager, a very long name, a user who already exists.
After you release
- Watch the first runs closely, and compare results with what you expected.
- Set an alert for failures, and make sure someone is on the receiving end.
- Export a copy of each folder as a backup after every important change.
- Review flows and connections every few months, and switch off what nobody uses.
- Keep a short change note for each edit: what, why, and who.
Mistakes seen again and again
Forgetting to switch on
A flow is built and tested, but never turned on, so nothing happens and nobody knows why.
Testing with real people
Test runs send real messages or remove real access, because the test used the live system.
Ignoring empty values
A missing manager or department reaches a card that cannot handle it, and the run fails.
Updating on every change
An “updated user” event fires for any change. Without a guard, the flow repeats work all day.
Loops over huge lists
A loop calls an outside service for each of thousands of items, and hits rate limits.
No owner
Nobody is responsible for the flow, so alerts go unanswered and old flows keep running without review.
A good test of design: could a colleague who has never seen your flow open it, read it from left to right, and explain what it does and why? If not, simplify it, rename the cards, or split it.
Team habits that keep automation healthy
Good tools still need good habits around them. Teams that run Workflows well for years tend to share a few working practices that have nothing to do with cards and everything to do with people.
A flow register
Keep a simple list of every flow: its purpose, its owner, the systems it touches, the connections it uses, and the date it was last reviewed. When something breaks, the list tells you who to call.
Naming rules
Agree on a pattern, such as the area, the verb, and the target. A name like “Leaver – remove chat access” is far clearer than “Flow 14 copy”.
Peer review
No flow that changes access goes live until a second person has read it. Flows are easy to read, so reviews are quick, and they catch missing guards.
Change notes
Write one line for every change: what moved, why, and who approved it. In six months, this note is worth more than anyone’s memory.
It also helps to agree who may switch a flow on or off. If any of ten people can turn off a leaver flow while “just testing”, an important job can stay off for weeks. A small group of owners, and a rule that every switch change is announced in a team channel, prevents this quietly and cheaply.
Finally, hold a short review of all flows every quarter. Ask three questions of each: is it still needed, is the rule still correct, and does its connection still have only the rights it needs? Companies change their tools and their structure often, and flows that were perfect a year ago may now point to a chat channel that no longer exists, or a group that was renamed.
21Workflows Compared With Other Options
Workflows is one tool among several. Knowing the others helps you choose well.
| Option | How it works | Best for | Limits |
|---|---|---|---|
| Built-in Okta rules | Group rules and policies inside Okta | Simple, standard access decisions | Cannot reach other tools or run multi-step logic |
| Workflows | Visual flows with cards, tables, and connectors | Multi-step lifecycle and cross-tool automation | Not for instant, user-facing decisions |
| Event hooks | Okta sends an event to your own web address | Teams with their own services that process events | You must build and host the receiver |
| Inline hooks | Okta calls your service during a process and waits for an answer | Changing the outcome of a process as it happens | Needs your own fast and reliable service |
| Custom scripts and code | Your own program calling Okta APIs | Complex logic, heavy data work, special needs | Needs developers, hosting, and upkeep |
Advantages of Workflows
- Visual and readable, so more people can understand and review the automation.
- Fast to build common jobs, with ready-made connectors.
- No servers to host or patch.
- Built-in tables, history, and testing.
- Delegated flows give controlled power to help desk staff.
Disadvantages
- Complex logic can become a tangle of cards.
- Platform limits on runs, time, and data size.
- Less suitable for heavy data processing or instant responses.
- Version control and team review are weaker than with ordinary code.
- Runs on a licensed platform, so cost and plan matter.
How to choose
- Start with built-in Okta features if they fully solve the problem.
- Use Workflows when the job has several steps, touches other tools, or needs a table of memory.
- Use an inline hook when the answer must be returned during a live sign-in or registration step.
- Use code when the logic is too complex or heavy for cards, or must live inside your own application.
Where Workflows fits in the wider Okta platform
Workflows does not live alone. It sits beside the other parts of the Okta platform and often works together with them. Single sign-on decides which apps a user can open. Universal Directory holds the user profiles that flows read and update. Lifecycle management handles creating and removing accounts in connected apps, and flows add the extra steps around it. Multi-factor authentication and adaptive policies decide how users prove themselves, and flows can react when security events appear. Where your organisation uses identity governance features, such as access requests and reviews, flows can add custom steps such as notifications or ticket updates. The cleanest designs let each part do what it does best, and use Workflows to join them.
Real-world example: layering the tools
A company uses group rules in Okta to give every engineer access to the code tool. That is a simple, standard decision, so no flow is needed. But when an engineer joins a project that handles customer data, a flow opens a ticket for a security briefing, notifies the project lead, and sets a reminder to review the access in ninety days. Built-in rules handle the common case, and Workflows handles the extras.
Choosing a tool is like choosing a vehicle. A bicycle (built-in rules) is perfect for short, simple trips. A car (Workflows) handles most daily journeys with comfort. A lorry you build yourself (custom code) can carry anything, but you must maintain it. Using a lorry to fetch milk is silly, and using a bicycle to move house is worse.
22Glossary of Terms
Quick reference for every term in this guide, in plain words.
| Term | Plain meaning |
|---|---|
| Identity | The digital record of a person and the access they have. |
| Flow | One automation, starting with an event and followed by cards. |
| Card | One block that performs a single task. |
| Event card | The card that starts a flow when something happens. |
| Action card | A card that asks an outside service to do something. |
| Function card | A card that works on data inside the flow. |
| Connector | The ready-made kit of cards for one service. |
| Connection | A saved, approved link to an account on that service. |
| Table | A small built-in spreadsheet that flows use as memory. |
| Helper flow | A flow that other flows call to do a shared job. |
| Delegated flow | A flow that chosen people can run from a button. |
| API endpoint flow | A flow with its own web address that outside systems can call. |
| Run | One execution of a flow from start to end. |
| Execution history | The record of past runs and their data. |
| Guard | A check early in a flow that stops it when it should not run. |
| Idempotent | Safe to repeat: doing it twice equals doing it once. |
| Rate limit | A cap on how many requests may be made in a period. |
| Joiner, mover, leaver | The three moments of the identity lifecycle: arrive, change role, depart. |
| Service account | A non-human account for automation with only the rights it needs. |
| Least privilege | Giving only the minimum rights needed for a job. |
| Source of truth | The system that is trusted when two systems disagree. |
| Event hook | An Okta feature that sends event data to your own service. |
| Inline hook | An Okta feature that asks your service for an answer during a process. |
23Frequently Asked Questions
Short answers to the questions people ask most often.
24Summary and Key Takeaways
If you remember only a handful of ideas, make them these.
Key Takeaways
- Workflows automates identity tasks visually. It turns the joiner, mover, and leaver checklists into flows that run the same way every time.
- A flow is an event plus cards. Event cards start it, action cards change other systems, and function cards work on data inside the flow.
- Connectors are kits, connections are keys. Use dedicated service accounts with minimum rights, and record who owns each connection.
- Tables give flows memory. Use them to avoid duplicates, to hold settings, to track multi-step requests, and to write audit records.
- Guard, check, then act. Stop early when a run is not needed, read before you write, and make steps safe to repeat.
- Build, test, and promote safely. Work in a test organisation, review, export, and import into live, then watch the first runs.
- Plan for failure and for limits. Use error handling, alerts, retries, and a manual fallback, and respect rate limits by filtering lists and spreading work out.