Built, not programmed
An automation has a trigger, conditions and actions, composed in a visual builder. Start from scratch or from a recipe in the template gallery.
Run history shows the step, not just the outcome
Every run expands into its steps, with their timeline. When something did not happen, you see exactly where it stopped and why.
That is the difference between an automation you can debug and one you have to trust. A bare "failed" with no steps means that next time you switch it off instead of fixing it.
Triggers are things that happen in the system
Because automations run over the same data as the rest of the application, a trigger can be an invoice issued, a payment received, a contract approaching its date or stock below a threshold. There is no integration service needed between two products that do not know each other.
Worth knowing
Automations accumulate. After a year you have ten rules, and the question is no longer "what do they do?" but "which one did that?". That is why the step-level history matters more than the builder: the builder is used once, the history every time something goes wrong.