Okta Certified Workflows - Specialty · Part I

Architecting Flows

7% of Part I

Architecting Flows

Sub-topic 1: Determine What Tasks You're Trying to Accomplish

2 sub-topics · this deck covers sub-topic 1 of 2

The Task

"Determine what task(s) you are trying to accomplish"

Before you open the Workflows Console, the exam expects you to be able to state the job in plain terms: what event should kick this off, what should happen as a result, and how will you know it worked. Everything downstream — the event card, the action cards, the schedule — falls out of that one sentence.

The Mechanism — Building the Flow

"Each event and action in a flow works with a pre-built connector, which allows you to communicate with other applications without code or APIs." The basic sequence: create a folder in the Flows tab, click +New Flow, add an event card (pick the app and the trigger event), then add action or function cards that do the work.

Event Cards vs. Function Cards

Action cards — send a command to an application (pick the app, pick the action)
Function cards — act on data from a card, or branch into another logical path (logic functions like branching/error handling, data functions like compose, or advanced functions like HTTP requests / JSON parsing)

Mapping data between cards means dragging a card's output field onto another card's input field — the field types have to match.

Testing Before You Trust It

You can test a single card in isolation, or run the whole flow with manually entered data via the Run button. "It takes about 60 seconds for the flow to enable" — after saving and turning a flow on, wait a minute before you try to trigger it, or the trigger won't fire yet.

How a Finished Flow Actually Runs

Determining the task also means knowing which run mechanism fits it. Okta Workflows can invoke a flow through an API endpoint (OAuth 2.0, a client token, or as a public service), run it as a delegated flow called from a parent flow, resume a flow that was deliberately paused, or cancel a flow execution outright.

The Gotcha — Execution History Has a Window

The Execution History page keeps a log of flow runs for the past 30 days, and it can be sorted by completed vs. in-progress runs. If you immediately trigger a flow right after turning it on, don't be surprised if it's missing from history yet — wait the same ~60 seconds before checking.

The Connection

This sub-topic is the "what" — the task statement and the run mechanism. The next sub-topic, Plan Your Flow, is the "how": lining up the actual apps, data, transformations, fields, and schedule before you build. Together they're the entire Architecting Flows section — the next section in Part I is Building Flows, where you actually assemble the cards.

The Angle — What Trips People Up

Watch for this in your own sandbox run:

→ Turning a flow on and immediately triggering it — the ~60 second enable delay means your test event can silently do nothing, and won't even show in execution history yet.

→ Confusing an action card with a function card — an action card always talks to an external app; a function card manipulates data or branches logic inside the flow itself.

→ Picking "invoke via API" as the run mechanism when the task is really an in-app event (like a user being assigned to an app) — that calls for an event card trigger, not an API-invoked flow.

One Line To Remember

Determining the task means naming the trigger, the outcome, and the run mechanism (event-triggered, API-invoked, delegated, or manually run) before you touch a card. A flow needs ~60 seconds after being turned on before it will actually fire, and execution history only covers the last 30 days.

Sources: help.okta.com — Build and test a flow (ext-build-a-flow); Run flows (ext-run-flows)

Next: Sub-topic 2 →