> ## Documentation Index
> Fetch the complete documentation index at: https://docs.voucherify.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Workflow options and limits

> Review workflow triggers, webhook callouts, statuses, behavior, and limits

Learn about the configuration and behavior of Workflows.

<Info>
  Read [Build workflows](/integrations/build-workflows) to create and publish a workflow.
</Info>

## Triggers

A trigger defines when a workflow starts.

| Trigger                 | What it matches                                                                                       | What you configure                         |
| ----------------------- | ----------------------------------------------------------------------------------------------------- | ------------------------------------------ |
| **Loyalty transaction** | Point movements, orders paid with points, tier changes, reward purchases, and benefit fulfillment.    | Group, event type, and transaction status. |
| **Loyalty activity**    | Lifecycle events for programs, members, cards, earning rules, rewards, benefits, and tier structures. | Group and event type.                      |

<Note>
  Transaction statuses such as `APPROVED`, `PENDING`, and `REJECTED` are trigger filters. They are not separate event types. They determine which transactions start a workflow.
</Note>

## Webhook callouts

A webhook callout sends a signed HTTP `POST` request.

The target URL must use `http` or `https`. A webhook callout can include up to 10 custom headers for authentication or routing data.

Voucherify generates the webhook payload automatically. Read [Workflows webhooks](/api-reference/workflows-webhooks) for the payload structure.

To verify signatures, generate a secret in **Project settings** > **Webhooks** and validate the `x-voucherify-signature` header. Read [Webhook authentication](/api-reference/introduction-to-webhooks#authentication) for details.

## Save, publish, and activate

Saving, publishing, and activation are separate operations.

| Operation                  | What it does                                                                                                                                                  | When to use it                               |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- |
| **Save**                   | Stores the working copy. Nothing goes live, even for an edited active workflow.                                                                               | When you have valid unsaved changes.         |
| **Publish**                | Creates a new published version from the saved canvas. An active workflow starts using it right away. Publish an edited active workflow to make changes live. | When the canvas is complete and fully saved. |
| **Active** or **Inactive** | Turns the published workflow on or off. The canvas does not change.                                                                                           | After the first publication.                 |

## Statuses

A workflow has three statuses: **Draft**, **Active**, and **Inactive**.

| Status       | Meaning                                                                      |
| ------------ | ---------------------------------------------------------------------------- |
| **Draft**    | The workflow has never been published. It does not react to events.          |
| **Active**   | The workflow is published. Matching events start new runs.                   |
| **Inactive** | The workflow is published but paused. Matching events do not start new runs. |

## Deactivation and version behavior

Events that occur while a workflow is inactive do not start a run.

Deactivation does not cancel a run that has already started. The run completes every pending action in the published canvas it started with.

Existing runs keep the version they started with when you publish a new version. New runs use the latest published version.

## Limits

Trigger and action limits are separate. A workflow can contain five triggers and five actions.

| Limit                              | Value |
| ---------------------------------- | ----- |
| Workflows per project              | 5     |
| Triggers per workflow              | 5     |
| Actions per workflow               | 5     |
| Connections per workflow           | 10    |
| Custom headers per webhook callout | 10    |