Workflows do what you have been doing by hand, in response to things that actually happen in the system.
A workflow is a graph, not a list
A workflow is built from nodes joined by lines: the trigger, actions, conditions, delays, waits for an event, and split/join for work that runs in parallel.
Because it is a graph rather than a list, a path can branch and meet again — and the order of execution comes from the lines, not from where the nodes sit on the canvas.
A running execution keeps the graph it started with
When a run starts, a snapshot of the graph is recorded for it. Editing the workflow afterwards leaves runs already in flight to finish on the old version.
So editing a workflow never corrupts a run that is midway through. The change takes effect from the next run.
A draft never runs
A workflow that is not active never runs, however often its trigger fires. This is the usual answer to "why didn't it work?".
Some actions are sent without waiting for an answer
Actions that belong to another module — creating an invoice, enrolling a student, tagging a contact and the like — are sent as a request, and the workflow does not wait for the outcome.
So the node succeeds because the request went out, not because the work finished. If the other side fails, the workflow never learns of it; the result has to be checked in that module.
How the sections fit together
Workflows is where you build. Execution history says what happened. Monitoring says how things are going overall. Action credentials holds secrets so they are not written into the workflow itself.