I built a simple order demo with n8n and Inistate to explore n8n long-running processes, n8n state management and an n8n state machine approach.
An order takes time. Payment happens first, then packing, shipping and delivery. These updates can arrive hours or days apart.
Instead of keeping one n8n execution running the whole time, each notification starts a new execution.
Inistate stores the order’s current state:
New → Paid → Fulfilling → Shipped → Delivered
n8n handles the notifications and performs the actions. Inistate acts as the state machine and decides which actions are allowed.
When payment arrives, n8n marks the order Paid, sends a “Please pick and pack” email and moves it to Fulfilling.
If the same payment notification arrives again, Mark Paid is rejected because the order has already moved forward. It doesn’t send another packing email.
If a delivery notification arrives before shipping, Mark Delivered is also rejected.
This demo uses simulated payment and carrier notifications. It shows how stored states can help manage a long-running business process across separate n8n executions.
How do you handle state management and repeated notifications in your n8n workflows?