> For the complete documentation index, see [llms.txt](https://developer.kizen.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.kizen.com/docs/concepts/agentic-workflows/agentic-workflow-goals.md).

# Agentic Workflow Goals

{% hint style="success" %}
**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 <code class="expression">space.vars.automations</code>.
{% endhint %}

## 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 <code class="expression">space.vars.entity</code>. 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 <code class="expression">space.vars.automations</code>. 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 <code class="expression">space.vars.workflow</code> 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 <code class="expression">space.vars.entities</code> or all activity on the platform. It is listening specifically within the context of the <code class="expression">space.vars.entity</code> and execution it is associated with, and it will only be met by events that occur on that specific context <code class="expression">space.vars.entity</code>.

This boundary matters when designing <code class="expression">space.vars.workflows</code> that span related <code class="expression">space.vars.entities</code>. A goal on a parent <code class="expression">space.vars.entity</code> will not respond to an event on a child <code class="expression">space.vars.entity</code>. It will only respond to events on the <code class="expression">space.vars.entity</code> 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 <code class="expression">space.vars.entity</code> 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 <code class="expression">space.vars.entity</code> 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 <code class="expression">space.vars.workflow</code>. 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](/docs/concepts/agentic-workflows/agentic-workflow-conditions.md) for detail on this recovery behavior.

### Supported Trigger Types

Goal steps support a subset of the trigger types available in <code class="expression">space.vars.automations</code> triggers. Not every trigger type available when configuring a <code class="expression">space.vars.workflow</code> 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 <code class="expression">space.vars.entity</code>. Use this when the <code class="expression">space.vars.workflow</code> 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 <code class="expression">space.vars.entity</code>. Use this when the <code class="expression">space.vars.workflow</code> 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 <code class="expression">space.vars.entity</code> is updated. Use this when the <code class="expression">space.vars.workflow</code> should wait for a data change on the <code class="expression">space.vars.entity</code>, 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 <code class="expression">space.vars.entity</code>. 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 <code class="expression">space.vars.workflows</code> like renewal reminders, birthday outreach, or post-purchase follow-ups.

{% hint style="info" %}
**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**.
{% endhint %}

#### Interactions

* **Form Submitted:** This goal is met when the specified form is submitted in the context of the <code class="expression">space.vars.entity</code>. Use this when the <code class="expression">space.vars.workflow</code> 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 <code class="expression">space.vars.entity</code>. Use this when the <code class="expression">space.vars.workflow</code> 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 <code class="expression">space.vars.workflow</code> needs to pause and wait for an external system to signal completion, use a webhook to trigger a separate <code class="expression">space.vars.automation</code> that resumes the paused execution via the Resume Paused Execution API. See <code class="expression">space.vars.automation</code> 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 <code class="expression">space.vars.workflow</code>.

### Drip Campaigns and Conditional Sequences

Goals are well suited to drip campaigns and multi-step communication sequences where the <code class="expression">space.vars.workflow</code> 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 <code class="expression">space.vars.workflow</code> 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 <code class="expression">space.vars.workflow</code> 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 <code class="expression">space.vars.entity</code>, so each listens for its own configured condition without interference from other goals in the same <code class="expression">space.vars.workflow</code> 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 <code class="expression">space.vars.automation</code>. Continue to [Agentic Workflow AI Agents](/docs/concepts/agentic-workflows/agentic-workflow-ai-agents.md) 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.

<details>

<summary>Related Topics</summary>

* [Agentic Workflow Actions](/docs/concepts/agentic-workflows/agentic-workflow-actions.md)
* [Agentic Workflow Execution & Process Model](/docs/concepts/agentic-workflows/agentic-workflow-execution-and-process-model.md)
* [Agentic Workflow Delays and Time-Based Behavior](/docs/concepts/agentic-workflows/agentic-workflow-delays-and-time-based-behavior.md)
* [Agentic Workflow Code Steps](/docs/concepts/agentic-workflows/automation-code-steps.md)

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://developer.kizen.com/docs/concepts/agentic-workflows/agentic-workflow-goals.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.