Agentic Workflow Goals
Audience: Administrators, Developers, Solution Architects
Purpose: Understand what goal steps are, how they evaluate conditions and route execution based on whether those conditions are met or a timeout occurs, and when to use goals to build conditional waiting behavior into your Agentic Workflows.
Overview
Goal steps extend the waiting capability of delays by adding a conditional dimension. Instead of waiting for a fixed amount of time to pass, an execution at a goal step waits for a specific event to occur on the context Record. If the event happens within the configured window, execution continues down the Met path. If it does not, execution continues down the Not Met path.
Goals are the mechanism for building event-responsive waiting behavior into Agentic Workflows. Using them effectively requires understanding three things: how their evaluation is scoped, which trigger types they support, and how their timeout behavior works.
What Are Goals?
Before diving into how goals are configured and when to use them, it helps to understand what a goal step actually is and how it differs from other step types.
A Trigger Plus a Scoped Conditional Wait
A goal step combines two things: a trigger condition the execution listens for, and a scoped wait that holds the execution at that point until the condition is met or a timeout occurs.
This is the defining distinction between goals and conditions. A condition step evaluates immediately and routes based on the current state of the data. A goal step waits actively for something to happen. It is listening for a future event or state change, not evaluating the present state. Understanding this distinction is essential before designing any Workflow that involves waiting behavior.
Execution-Scoped Only
Goal evaluation is scoped to the execution in which the goal step exists. The goal is not a global listener. It is not monitoring all Records or all activity on the platform. It is listening specifically within the context of the Record and execution it is associated with, and it will only be met by events that occur on that specific context Record.
This boundary matters when designing Workflows that span related Records. A goal on a parent Record will not respond to an event on a child Record. It will only respond to events on the Record the execution is running against.
The Not Met Path Timer
Goals can be configured with a timeout, a maximum amount of time the execution will wait for the goal condition to be met. The timeout period is measured from the moment the execution reaches the goal step. If the configured time passes without the condition being met, execution proceeds down the Not Met path.
The timeout is configured under Goal Settings in the Proceed Down Not Met Path After dropdown, which offers three options:
Never: The execution waits indefinitely for the goal condition to be met. No automatic timeout applies and the Not Met path is never taken.
After Delay: The execution waits for a specified period before proceeding down the Not Met path.
On Specific Date: The execution waits until a specific calendar date before proceeding down the Not Met path.
The Wait Forever Option
Selecting Never for the Not Met path configures the goal to wait indefinitely. The execution remains at the goal step until the condition is met. There is no automatic timeout and the Not Met path is never taken.
Use this option intentionally. An execution configured to wait forever will remain active and associated with the Record for as long as it takes, which may be days, weeks, or longer. The only way to exit a goal configured this way without the condition being met is to manually cancel the execution.
How Goals Work
The following sections cover the mechanics of goal evaluation, completion, and timeout behavior so you can configure goals correctly and predict how they will behave at runtime.
Goal Completion and Timeout Behavior
A goal step has two outcome paths:
Met path: Taken when the configured trigger event occurs on the context Record within the wait period.
Not Met path: Taken when the configured timeout expires before the condition is met.
Both paths should be deliberately accounted for when designing a Workflow. Even if the Not Met path leads to no further steps, that decision should be intentional rather than overlooked.
If a goal step errors during evaluation, the execution pauses and a path must be manually selected to resume. See Agentic Workflow Conditions for detail on this recovery behavior.
Supported Trigger Types
Goal steps support a subset of the trigger types available in Agentic Workflows triggers. Not every trigger type available when configuring a Workflow trigger is available as a goal condition. Verify that the trigger type you need is supported before designing a goal around a specific event.
The following trigger types are supported, organized into three categories:
Activities
Activity Logged: This goal is met when the specified activity is logged against the context Record. Use this when the Workflow should wait for a team member or system to complete a tracked action, such as a call logged, a meeting recorded, or a task marked complete.
Activity Past Due: This goal is met when the specified activity becomes past due on the context Record. Use this when the Workflow should respond to a missed deadline, for example escalating after a follow-up call goes uncompleted.
Entity Records
Field Updated: This goal is met when the specified field on the context Record is updated. Use this when the Workflow should wait for a data change on the Record, such as a status field moving to a new value or an owner being assigned.
On or Around Date: This goal is met based on a date value stored on the context Record. The goal can fire on the date itself, a configurable number of days before, or a configurable number of days after, at a specified time. Use this for date-driven Workflows like renewal reminders, birthday outreach, or post-purchase follow-ups.
Note: The On or Around Date trigger handles timing differently from the other trigger types. Instead of the standard Not Met path timer, its Goal Settings include an Action for Dates in the Past option that determines how the execution behaves if the target date has already passed by the time the goal is reached. The available actions are: Proceed down Met path immediately, Proceed down Not Met path immediately, or Wait for Not Met path delay.
Interactions
Form Submitted: This goal is met when the specified form is submitted in the context of the Record. Use this when the Workflow should wait for a recipient to take an explicit action, such as registering, requesting information, or completing an opt-in.
Survey Submitted: This goal is met when the specified survey is submitted in the context of the Record. Use this when the Workflow should wait for feedback or qualifying responses before continuing.
The configuration shown under Goal Settings changes based on the selected trigger. Activity and interaction triggers ask you to choose the specific activity, form, or survey to listen for. Field Updated asks you to choose the field. On or Around Date asks you to choose the date field and configure the offset, time, and behavior for dates that have already passed.
Webhook Triggers Are Not Supported
Webhook triggers are not available as goal conditions. This is a design limitation, not a configuration error. A goal step cannot listen for an inbound webhook event as its completion condition.
If your Workflow needs to pause and wait for an external system to signal completion, use a webhook to trigger a separate Agentic Workflow that resumes the paused execution via the Resume Paused Execution API. See Agentic Workflow APIs and Webhook Trigger (Topic Coming Soon) for detail on that pattern.
Why Use Goals?
The following examples illustrate the situations where a goal step is the right design choice and how to think about goals in the context of a broader Workflow.
Drip Campaigns and Conditional Sequences
Goals are well suited to drip campaigns and multi-step communication sequences where the Workflow should respond differently depending on whether a recipient takes a desired action.
For example, send a communication, wait for a specific response — a form submission, a field update, or another trigger event — then branch based on the outcome. If the response arrives in time, take the Met path. If it does not, take the Not Met path. One Workflow handles both the engaged and unengaged paths
Choosing Between Goals and Delays
The distinction is straightforward:
Use a delay when execution should wait for a fixed period regardless of what happens.
Use a goal when execution should respond to something happening, or not happening, within a window.
If the next action depends on whether an event occurs, use a goal. If the next action happens no matter what, use a delay.
Goals and delays can also be combined. A delay before a goal creates a staged wait. A delay after a goal on either path creates a time gap before the next action.
Goals in Multi-Step Workflows
A Workflow can include multiple goal steps, allowing complex conditional sequences where execution listens for different events at different points. Each goal is independently scoped to the same execution and context Record, so each listens for its own configured condition without interference from other goals in the same Workflow Earlier goals do not affect the evaluation of later ones, and each goal must be met or timed out on its own terms.
What's Next
With goals, conditions, delays, and variables established, the next topic introduces a step type purpose-built for AI-driven logic within an Agentic Workflow. Continue to Agentic Workflow AI Agents to learn how to configure Call LLM, File Extraction, and Audio Transcription steps, and when to use AI-driven evaluation instead of standard conditions and actions.
Last updated
Was this helpful?