Lifecycle of a Flow

Flows can exist in a variety of states during their lifetime, with each state conveying different requirements, abilities, and limitations. This article outlines the different states that exist, how a Flow transitions into each state, and what each state means for developers building and sending Flows.

Business-set Flow states

Most common states are the result of API calls, such as creating or publishing a Flow. This section covers the various states that you have control over as a business.

Draft

When a Flow is initially created, it enters the "Draft" state which indicates that the Flow is actively being modified.

While in the Draft state, the Flow is only able to be sent for testing, and also has the ability to be fully deleted if no longer needed.

Next states: Deleted, Published

Deleted

Technically this is not a "state" of a Flow because this represents a Flow that no longer exists. However, it's important to note that Flows may be deleted, but only if they are in the Draft state.

Next states: None (terminal)

Published

Once a Flow is ready to be sent, it transitions from the Draft state to the Published state. This allows it to be sent to real users rather than just for testing.

Now that the Flow is visible to real users, it can no longer be modified or deleted. This is to prevent inconsistency from Flows changing over time (or errors from missing Flows).

Instead, alternatives exist for these actions:

• Since you cannot modify the Flow, create a new Flow that clones the existing one (using the clone_flow_id field)
• Since you cannot delete the Flow, deprecate it instead using the /deprecate API call.

Next states: Deprecated, Throttled

Deprecated

Once a Flow enters the Deprecated state, it can no longer be sent to real users. Keep in mind that a deprecated Flow may still be present on users' devices and you may still see responses from the deprecated Flow.

Next states: None (terminal)

System-set Flow States

This section covers the states that can only be entered based on WhatsApp monitoring determining that there is an issue or that an issue has been resolved.

Throttled

In the case that WhatsApp monitoring detects that the endpoint for your Flow is unhealthy, it transitions the Flow to a Throttled state. A throttled Flow can still be opened and sent, however sending is limited to 10 messages per hour.

If your Flow enters the Throttled state and you need help diagnosing the issue, start by opening a support case using the Support Portal.

If WhatsApp monitoring detects an improvement in the health of the Flow's endpoint, the Flow will be transitioned out of the Throttled state and back into the Published state.

Next states: Published, Deprecated, Blocked

Blocked

If a Flow has entered the Throttled state and WhatsApp monitoring detects that the health of the provided endpoint has deteriorated even further, the Flow will be transitioned into the Blocked state. This is to prevent a degraded user experience for WhatsApp Flows.

While in the Blocked state, the Flow cannot be sent by the business and cannot be opened by users. WhatsApp monitoring will continue to check the health of the endpoint, and upon improvement the Flow will be transitioned back to Throttled and then to Published state.

Next states: Deprecated, Throttled

Example Flow Lifecycles

To illustrate how Flows might transition through the various states, here are some real-life examples of the stages and events leading to transitions.

A successful Flow

In this example, we publish a Flow and it continues to run with no issues. One day it may be deprecated, but it has not entered that state yet.

A Flow with health issues

In this example, we publish a Flow that has intermittent health issues with the provided endpoint. WhatsApp monitoring detects problems, recoveries, and then further problems. Finally, health is fully restored.

A Flow that never makes it to production

In this example, we work on a Flow but decide that we no longer need it. This Flow never ends up being visible to real users.