Okta Certified Workflows - Specialty · Part I

Building Flows

43% of Part I — the exam's largest section, split across 4 modules.

Building Flows · Module 2

Sub-topic: Triggering Events & Delegation

this deck covers 1 of 3 sub-topics in this module

The Task

"Identify the triggering event and add it to your flow"

"Events are occurrences that trigger flows to run." Every flow starts with exactly one event card, and picking the right type of event is the first real design decision in building a flow.

Three Types of Events

Application events — monitor for changes within a cloud app; the flow executes when a change is detected
Scheduled events — execute a flow at a given interval
On demand events — activate a flow internally or externally, e.g. via API call or Inline Hook

How Application Events Actually Fire

Two different mechanisms hide behind the same "application event" label:

→ Webhook-driven: "Many application events, including those from Okta, are triggered in response to an incoming webhook" — the external system calls Workflows the moment the event occurs.

→ Polling-driven: other cards check the service for new/updated records on a recurring schedule — "most of these cards poll the connected application for new data every five minutes by default," though this is configurable.

Delegating a Flow to Another Admin

"Delegating a workflow is an option to have a flow that an Okta admin can view and run directly from the Okta Admin Console" — useful when you want an admin to run an automation without granting full Workflows access. Build it using the Delegated Flow event card from the Add event dialog.

Delegation Requirements & Limits

A custom admin role with a resource set containing the delegated flow
The role must carry the "Run delegated flow" permission
The role must be assigned to one or more admins
A flow can have only one endpoint security setting; Pause / Pause Raw cards can't be used directly inside a delegated flow — use a helper flow instead

The card's inputs include a group of extensible fields (Text, Number, True/False, or Date & Time — no List type) plus the Okta User ID of the delegated user and an optional Caller context object when invoked from another Okta product.

The Angle — What Trips People Up

Watch for this in your own sandbox run:

→ Assuming every application event fires instantly — plenty are polling-based on a 5-minute default schedule, not webhook-driven.

→ Dropping a Pause card straight into a delegated flow — it isn't allowed there; move that logic into a helper flow instead.

One Line To Remember

Events are Application (webhook or 5-min-default polling), Scheduled (fixed interval), or On Demand (API/Inline Hook call). Delegating a flow to an admin uses the Delegated Flow event card, and requires a custom admin role with the "Run delegated flow" permission on a resource set containing that flow — but the flow can only carry one endpoint security setting, and Pause/Pause Raw cards need a helper flow instead.

Sources: help.okta.com — Events (ext-about-events); Delegated flows (ext-about-delegated-flows); Build a delegated flow (ext-http-method-delegated)

Next: Actions & Functions →