Trigger first, then actions
The shape is always the same. A trigger defines when the flow wakes up, and one or more actions define what it then does, in sequence or in parallel. Microsoft's Power Automate, where the term is at home, offers three starting points: an automated flow fires on an event such as a new message from a given sender, an instant flow starts when someone selects a button, and a scheduled flow runs at a set time, such as a nightly upload. Triggers themselves come in two kinds. A polling trigger checks the service at intervals for something new; a webhook trigger is told the moment it happens.
The parts, and where each goes wrong
- Trigger: too broad and the flow runs on every edit to a list instead of on new items; filter it at the trigger, not three steps later.
- Actions: each one is a call to a service, so a long flow is a long chain of things that can time out or be throttled.
- **Connectors**: the adapters that let the flow talk to SharePoint, Outlook, a CRM or a custom API, each signed in through a stored connection.
- Expressions and conditions: where most logic errors hide, because a date or an empty field arrives in a format nobody tested.
Power Automate now also lets a maker describe the automation in plain language and have Copilot draft the steps, which speeds up the first version and changes nothing about who has to maintain it. A workbook macro remains the right size for a task inside one file on one desk; a cloud flow suits work that crosses applications or must run when nobody is signed in. Behind the connectors sits the same idea as any REST API integration, and the discipline of marketing automation platforms, with triggers, branches and audits, carries over well. The workplace automation topic sets flows in that wider picture.