Okta Certified Workflows - Specialty · Part I

Workflows Overview

27% of Part I — the exam's largest single knowledge area alongside Building Flows.

Workflows Overview

Sub-topic 4: Understand Workflow Elements

7 sub-topics · this deck covers sub-topic 4 of 7

The Task

"A flow is a combined sequence of individual steps consisting of the events, logic, and actions for a particular use case."

Beyond naming card types (Sub-topic 3), the exam wants you to understand the plumbing that connects them: connectors, connections, inputs, outputs, and mapping — plus the optional elements (notes, duplicated cards, templates) that make a flow maintainable.

Connectors and Connections

Connectors are the individual applications that compose your flow (Okta's docs use a Box connector as the example). Connectors interact with external applications through a connection — "a uniquely configured relation to the external applications or services endpoints." The connection handles authentication and authorization, so the flow builder never has to query the API directly.

Inputs and Outputs

Input fields determine how an action or function card proceeds — for example, the Search Users action card's input field is Email. Output fields contain the results a card generates: in Okta's example, the Search Users card produces output values such as User ID, Role, and Name.

Mapping — How Cards Talk to Each Other

"The sharing of data from one card to one (or more) subsequent cards is called mapping. To map data between cards, you drag and drop the output field of one card to the input field of another card."

In Okta's worked example, the User ID output field maps to both the value input on a Continue If function card and the User ID input on a Deactivate User action card — one output can feed multiple downstream inputs. Critically: "the format of an output field and any mapped input fields must match."

Optional Elements: Notes, Duplication, Templates

You can drop note cards anywhere in a flow to explain it or leave reminders — notes don't affect run-time execution at all. You can also duplicate cards when you need near-identical cards with slightly different inputs. A template is a flow (or collection of flows) that Okta builds to demonstrate a use case; you copy and adapt it rather than building from a blank canvas.

The Gotcha — Type Mismatches Break Mapping

Mapping is drag-and-drop, which makes it easy to overlook that the underlying data types must line up. If an output field's type (say, a list) doesn't match the target input's expected type (say, text), the mapping fails or produces a runtime error — this is exactly the kind of scenario the JSON and Object function cards (Sub-topic 7, and the Advanced function family from Sub-topic 3) exist to resolve.

The Connection

This sub-topic is the connective tissue for the whole module: Sub-topic 2's flow types all still open with an event card; Sub-topic 3's action/function cards are exactly what gets connected via mapping; and Sub-topic 6's execution limits (Table function limits, memory limits) are direct consequences of how much data flows through these input/output pipelines.

The Angle — What Trips People Up

→ Thinking a "connector" and a "connection" are the same thing — the connector is the app integration itself; the connection is your org's specific authenticated link to that app's endpoint.

→ Forgetting notes are purely documentation — they never execute or affect the flow's logic at runtime.

→ Assuming templates are locked — they're meant to be copied and modified "to meet your needs with minimal configuration changes," not used as-is only.

One Line To Remember

A flow's elements are its event, action, and function cards, wired together by connectors/connections (which handle auth) and by mapping (dragging an output field to an input field of matching type) — with notes, duplicated cards, and templates as optional, non-executing conveniences.

Sources: help.okta.com — Workflow elements (ext-about-elements)

Next: Sub-topic 5 →