Prepared with AI assistance and reviewed for clarity, relevance and unsupported claims.
Workflow triggers and states answer two different questions: what happened, and where does the work stand now? Confusing them can send incomplete enquiries to staff, restart finished tasks or treat an attempted notification as completed work.
For a Moroccan service SME, the starting point can be a plain-language process sheet rather than a technical diagram. Define which events matter, what must already be true and what each resulting state allows. Connect tools only after those decisions are understandable to the people doing the work.
1. Separate the incoming event from permission to proceed
A trigger is an event the workflow notices: a form submission, an incoming message, a staff approval or a scheduled check. An entry condition is a requirement that must be satisfied before a particular action starts.
Consider a hypothetical appliance-repair business. A customer writes, “Can someone look at my washing machine?” The message creates an enquiry record, but it should not immediately enter the dispatch review queue. The team first needs the service location and a usable contact method.
Write the rule in business language: “When new customer information arrives, update the existing enquiry. Send it for review only when the required location and contact details are present and no cancellation has been recorded.”
This separates receiving information from authorising the next step. An AI-extracted location is only a candidate value if the message is ambiguous. “Near the usual shop” should not silently become a confirmed address.
2. Define workflow states as conditions people can recognise
A useful state tells staff what is true and what should happen next. Avoid labels such as “processing” when they could mean waiting for the customer, waiting for staff or experiencing a technical problem.
For the hypothetical repair enquiry, a compact state model could be:
- Awaiting details: required information is missing or needs clarification.
- Ready for review: entry conditions are satisfied, but no reviewer has taken responsibility.
- Under review: a named colleague is assessing the request.
- Awaiting customer decision: the team has supplied a next step and needs a response.
- Completed: the enquiry has an agreed outcome and any required handoff is recorded.
- Cancelled: the customer withdrew the request or an authorised colleague closed it with a reason.
Keep technical delivery status separate. A failed staff notification does not make the customer enquiry invalid. Likewise, “message sent” does not mean the customer has accepted an appointment.
3. Specify permitted transitions and who causes them
For each state change, record the starting state, the event, the required evidence, the actor and the resulting action. This prevents any new message from moving the enquiry arbitrarily forward.
- Awaiting details → Ready for review: the required fields are supplied and checked for obvious ambiguity.
- Ready for review → Under review: a colleague accepts ownership.
- Under review → Awaiting details: the reviewer identifies missing information and records the question to ask.
- Under review → Awaiting customer decision: an authorised colleague approves and sends the proposed next step.
- Awaiting customer decision → Completed: the response is recorded and the agreed outcome is documented.
In this example, completion might mean an accepted request was transferred to a separate scheduling process with its own reference. It does not mean the repair itself is finished. Define that boundary explicitly.
If several tools hold the same fields, first choose which system owns each field. Otherwise, one tool may overwrite the state another tool just corrected.
4. Give cancellation, inactivity and corrections their own rules
Cancellation is not deletion. Preserve enough context for staff to see what was stopped and why, while following the business’s internal data-retention rules. Stop pending actions that no longer make sense, such as reminders asking for an address.
A withdrawal received before review can move the enquiry to cancelled. If a separate appointment already exists, cancellation of the enquiry should create a staff task to check that appointment rather than assume it has also been cancelled.
Define inactivity separately from refusal. If the customer does not reply within the business’s chosen waiting period, staff might close the request with a “no response” reason. A late reply should follow an explicit reopening rule, not silently revive old commitments.
Corrections also need a route. A changed location during review may require reassignment. Keep the previous value distinguishable from the current one so the reviewer can understand why the request moved.
5. Rehearse duplicate and out-of-order events
Messages do not always arrive in the expected order. A customer may resend details, submit a form after messaging or reply while a colleague is editing the record.
Use a short hypothetical rehearsal:
Customer: “I need a repair visit.”
The enquiry remains awaiting details. The customer then provides the neighbourhood and callback number, so it becomes ready for review. Repeating the same message should update or leave the record unchanged, not create another review task. If “Actually, please cancel” arrives before a delayed notification is sent, that notification should no longer invite staff to begin an active review.
Test missing fields, ambiguous locations, repeated submissions, cancellation during review and replies after closure. For each case, write the expected state and the action that must not happen. The guide to recognising duplicate requests provides related reasoning about matching records without assuming that similar messages are identical.
6. Approve a one-page state specification
Before implementation, the process owner should approve the trigger list, required fields, state definitions, permitted transitions, cancellation rules and completion evidence. Include who handles a request that cannot follow any permitted transition.
More states provide precision but create more maintenance and training. Add a state only when it changes ownership, permitted actions or the next decision. Store secondary details as fields or reasons rather than creating a status for every possibility.
A custom n8n automation can be scoped around this specification, with tool compatibility and implementation details checked during discovery. You can discuss your workflow boundaries and state model with FlowAgent.