How should a workflow distinguish entering a status from remaining in that status?

Question

I want a process to run when a record changes to “Ready,” rather than whenever someone edits a record that is already marked “Ready.” How should this distinction be expressed in Busabase? What should I check when defining the trigger and conditions?

Kelly · Answer

You want an **edge** (“became Ready”), not a **state** (“is Ready”). Express the trigger as a **transition into Ready**, and guard so later edits while still Ready do not re-run the process.

![](https://s1.busabase.com/attachments/cHEfVIklx0ASY7gZ6iJhU7wCONhhfJNb/blobs/sha256/7b/7b9051e8cbb0c132e454ef4695d2aa586daa3652f4d2c55d63868602b2f0c541.png)

*Diagram · enter Ready once vs remain Ready*

## How to express the distinction

| Intent | Condition to aim for |
|--------|----------------------|
| **Entering Ready** | Previous status ≠ Ready **and** current status = Ready (transition / edge) |
| **Remaining Ready** | Current status = Ready (state) — true on every later edit |

### Design patterns that stay clear

1. **Transition condition** — trigger only when status changes to Ready (compare before/after on the change).  
2. **One-shot flag** — when entering Ready, set `readyProcessStarted = true` (or write `readyEnteredAt`). Further edits while Ready do nothing if the flag is already set; reset the flag only when leaving Ready.  
3. **Dedicated “kickoff” status** — e.g. `Ready (new)` → automation moves to `Ready (in progress)` so a plain “is Ready” filter is not re-armed.

Also put any extra filters (assignee, type) on the same gate so you do not rely on “someone edited a Ready row.”

## What to check when defining the trigger

1. Does it read **old value → new value**, or only the new value?  
2. If someone edits a comment on an already-Ready record, should anything run? (Usually **no**.)  
3. When status leaves Ready and returns later, should the process run **again**? If yes, clear the one-shot flag on exit.  
4. Write a one-line note on the flow: “Fires on enter Ready only.”

## Current Workflow boundary

In [Busabase](https://busabase.com) you can **design and save** Workflow graphs today. The **execution runtime is still rolling out**, so treat the patterns above as the design rule for enter-vs-remain. For live behavior until the runner is generally available, use Agent / Skill / status-field updates with the same one-shot or transition logic. When runtime trigger semantics are confirmed in production, we can update this thread with the exact engine defaults.

## How you can verify later (once a runner executes the graph)

1. Move Draft → Ready → process runs once.  
2. Edit the Ready record without changing status → process must **not** run again.  
3. Ready → Draft → Ready → process runs again only if you intended re-entry.

If you share whether re-entering Ready should restart the process, we can lock the flag reset rule.

Intent	Condition to aim for
Entering Ready	Previous status ≠ Ready and current status = Ready (transition / edge)
Remaining Ready	Current status = Ready (state) — true on every later edit

How to express the distinction

Design patterns that stay clear

What to check when defining the trigger

Current Workflow boundary

How you can verify later (once a runner executes the graph)

Your reply