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 3: Understand Workflow Cards

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

The Task

"The first card in any flow is an event, representing the trigger that begins your flow."

Every flow is built from three fundamentally different card families: Event cards (the trigger), Action cards (talk to an app), and Function cards (manipulate data or logic inside the flow). The exam wants you to tell these apart on sight and know what each one can and can't do.

Event Cards — The Trigger

The first card in any flow. Events can be scheduled, on-demand (API Endpoint), or triggered by a change within an external application or service (app event, delegated flow). No matter which flow type from Sub-topic 2 you're building, it starts with exactly one event card.

Action Cards — Commands to Applications

"Action cards for applications control various aspects of the application or web service. They cause an action to happen, such as sending a message, adding a record, or updating an existing record."

Action cards can also retrieve information — searching for records, looking up customer data, or downloading a file. You pick the application first (Add app Action → choose Salesforce, Slack, Gmail, etc.), then pick from that application's own unique set of action cards, since each connector exposes different capabilities.

Function Cards — Manipulating Data and Logic

"A function card enables you to interact with the data in your flow to change or control elements. Functions can be chained together to create complex interactions between your cards."

Okta groups function cards into four families: Logic (Branching, Error Handling, Flow Control), Manipulation (Text, Number, True/False, Date & Time, Object, File, List), Elements (Flows, Folders, Tables), and Advanced (API Connector, JSON, XML, URL, Encryption, JWT).

Why You Need Function Cards at All

Action cards from different apps return data in different shapes, and sometimes return errors. Action cards themselves can't account for every one of those scenarios — that's the job of function cards: reshaping returned data, handling error conditions, or redirecting the flow down a different logical path (branching).

The Gotcha — Cards Are Connector-Specific

Action cards aren't generic — "each third-party application has a unique set of action cards, based on the application's capabilities and features," per Okta's docs. You can't assume a card from one connector (say, Salesforce's Search Records) has an equivalent on every other connector; you must check that specific connector's card list.

The Connection

This is the vocabulary Sub-topic 4 (Workflow Elements) builds on directly — connectors, inputs, outputs, and mapping are all described in terms of moving data between these exact card types. It also sets up Sub-topic 7 (JSON Basics), since the JSON function card family (Parse/Stringify) is one of the "Advanced" function categories introduced here.

The Angle — What Trips People Up

→ Calling every non-event card an "action card" — function cards (branching, error handling, JSON parsing, list iteration) never talk to an external application; only action cards do.

→ Expecting a uniform action-card set across connectors — the available actions are defined per-connector, based on what that specific application/API supports.

→ Forgetting that action cards can both send commands and retrieve data (search, look up, download) — "action" doesn't mean "write-only."

One Line To Remember

Every flow opens with one event card (the trigger), then chains action cards (which talk to a specific third-party app's unique capabilities) and function cards (grouped as Logic, Manipulation, Elements, and Advanced) to reshape data and control the flow's path.

Sources: help.okta.com — Action cards (ext-about-action-cards); Function cards (ext-about-function-cards)

Next: Sub-topic 4 →