Ecommerce Automation Software Wired Into The Backend That Took The Order.
Draw the flow, pick what starts it, and let it branch. The events come from the same system that holds your orders, your stock and your customers, so the automation reacts to what happened rather than to a copy of it.
What Can Start A Flow
Every trigger below is a real event on the backend, not a field you poll. They fire when the thing happens.
8 events
Orders
Placed, shipped, delivered, ready for pickup, picked up, cancelled, refunded and payment failed. The pickup pair exists because a counter sale is a real lane here, not an edge case.
12 events
Inventory
Stock below your threshold, stock at zero and stock restored, plus create, update and delete on products, categories and sizes.
2 events
Storefront
Added to cart and checkout started, which is what makes an abandoned cart a real event rather than a nightly guess.
6 events
Customers And Contacts
Account created, subscribed to email, contact created or updated, a tag added, and a contact form submitted.
3 events
Your Team
A user created, logged in, or resetting a password, for the internal alerts nobody wants to write twice.
Anything else
Schedules And Webhooks
A cron expression, a plain interval, a calendar event or its reminder, a signed custom webhook, or a button you press yourself.
Five Kinds Of Node.
A flow is a canvas of nodes joined by edges, and there are only five things a node can be. That is enough to express almost every automation a store actually wants, and few enough to still read the diagram a year later.
The one worth pointing at is the condition, and the reason is the sixth card: the edges are not decoration. Each one records which branch of a fork it leaves from, so a condition sends two runs genuinely different ways rather than filtering one of them out.
Trigger
What starts it. One per flow, chosen from the registry rather than typed as a string and hoped for.
Action
What it does. Send an email or a template, notify your team, open a task, write to a contact, tag one, adjust stock, or draft copy with AI.
Condition
A real fork. Edges carry the branch they belong to, so the two sides of a condition go different places instead of merging back immediately.
Delay
Wait, then carry on. The run parks with a status of waiting rather than holding a worker open for three days.
Wait Until
Hold until something becomes true, then take the branch that matches what happened.
And The Edges
Not a node, but the other half of the canvas. A connection knows which branch of a fork it leaves from and can carry a label, which is what lets one condition send two runs somewhere genuinely different.
Nobody Gets Welcomed Four Times.
Re-entry is a setting on the flow, not a convention you hope everybody follows. Never, always, only once the previous run finished, or only after a cooldown you give in seconds.
Never is the default. The version of this feature that ships with a permissive default is the version that emails somebody four times on their first day.
Test It Against Yourself First.
A flow can be switched into test mode with one address. The run then happens properly, with real steps and real output, and every message goes to that address instead of the customer.
Which is a different thing from a preview. You are watching the automation behave, not looking at a picture of what it would probably do.
Every Run Leaves A Record
When somebody asks why a customer got that email, the answer should be a lookup rather than an investigation.
The Run
Pending, running, waiting, completed, failed or cancelled, with the payload that started it and the node it stopped on.
Each Step
What went in, what came out, which branch it took, and the error text if it failed. Per node, not per run.
The Timings
Milliseconds per step, which is how a flow that quietly got slow becomes visible before it becomes a complaint.
It Reads From The Same Records
Questions People Ask
What is ecommerce automation software?
It is the layer that does the repetitive work a store generates: emailing the customer whose payment failed, alerting somebody when a size drops below its threshold, opening a task when an order is ready for pickup. On DashForDevs it runs on the same backend as the orders and the stock, so a flow starts from the event itself rather than from an export that arrives later.
Is there a visual builder, or is this code?
A canvas. Nodes are placed and joined, and each one is a trigger, an action, a condition, a delay or a wait. Conditions genuinely branch: the connection between two nodes records which side of the fork it belongs to, so a flow can do one thing for a repeat customer and something else for a first order.
Can a customer enter the same flow twice?
That is yours to decide, per flow. Re-entry can be never, always, only after they finished the last run, or only after a cooldown you set in seconds. Never is the default, because the failure everybody has seen is the welcome sequence that welcomed somebody four times.
Can I test a flow without emailing real customers?
Yes. A flow can be put in test mode with a single address, and the run happens for real against that address instead of the customer. You see the actual behavior rather than a preview of it, which is the difference between testing an automation and hoping about one.
How do I know what a flow actually did?
Every run is recorded, and so is every step inside it. Each step keeps what went in, what came out, which branch it took, how many milliseconds it spent, and the error if it failed. When somebody asks why a customer got that email, the answer is a record rather than a reconstruction.
Can a flow run on a schedule instead of an event?
Both are supported. A cron expression for the ones that belong to a calendar, or a plain interval for the ones that just need to happen every so often. A flow can also be started by a signed webhook you call from anywhere, or by hand from the dashboard.
Draw One This Afternoon.
Sign up, put a low-stock alert on the canvas, and watch the execution log fill in.