Automation & AIModule 2: Automation building blocksLesson 7 of 15
Course progress40%
17 min lesson · Updated August 2026
What are triggers, conditions and actions?
A trigger starts a workflow, conditions decide which path applies, actions change or send information, and stop, retry and exception rules keep the process bounded.
What you will learn
By the end, you will understand:
Map trigger, condition and action logic
Design validation, branching and idempotency
Create explicit retry, failure and stop behavior
Visual explainer
See the idea clearly.
✓
A verified trigger passes validation, branches through conditions into scoped actions, then reaches success, retry, human exception or safe stop with logs.
The core building blocks
Part
Meaning
Trigger
The event or schedule that starts a workflow, such as a form submission or daily time.
Condition
A true/false or multi-value decision that selects a path.
Action
An operation such as create, update, send, calculate or notify.
State
Stored facts about what has happened and what remains.
Stop/exception
A defined end or human route when requirements are not met.
Validate before branching
Check required fields, type, format, authorization, duplicate status and business rules before taking action. Frontend validation improves experience but server-side validation remains necessary.
Treat external payloads as untrusted. A field saying “approved=true” is not approval unless the trusted system and identity establish it.
Conditions should be explicit
01
Receive event
02
Authenticate source
03
Validate payload
04
Check duplicate/idempotency key
05
Evaluate business conditions
06
Execute allowed action
07
Verify response
08
Record status
09
Notify or escalate
Idempotency prevents duplicate effects
Networks retry and users double-submit. An idempotent design recognizes the same event and avoids charging, creating or sending twice. Use stable event IDs or safe upsert logic where supported.
Not every operation is naturally idempotent. Design duplicate checks and reconciliation for payments, messages and record creation.
Retries need limits
Failure
Response
Temporary timeout/rate limit
Retry with bounded backoff and jitter where appropriate.
Invalid data
Do not retry unchanged input; send to correction path.
Permission denied
Stop and alert owner; do not repeatedly attack the system.
Unknown partial success
Check external state before retry to avoid duplicate action.
Permanent service removal
Disable workflow and activate fallback/migration.
Design the unhappy path first
Missing field
Duplicate event
Out-of-order event
Service unavailable
Credential expired
Rate limited
Action partially succeeded
Notification failed
Human unavailable
Cancellation received
Maximum retries reached
Manual replay procedure
Real-world example
Example: safe contact-form workflow
Example
A signed server event validates the email and consent state, checks the submission ID, creates one CRM record and sends one acknowledgement. Invalid data enters a review queue; temporary CRM failure retries; repeated IDs do not send another email.
Try this
Draw an unhappy-path flow
Map one workflow with its normal path, three invalid inputs, two system failures, duplicate event and cancellation. Write exactly where it stops, retries or asks a person.
Common questions
Questions beginners ask.
What is a trigger?
The event or schedule that starts a workflow.
What is a condition?
Logic that decides which branch applies based on validated information.
What is an action?
A scoped operation such as creating, updating, sending or notifying.
What is idempotency?
Design that lets the same request/event be handled repeatedly without creating unintended duplicate effects.
Should every failure retry?
No. Invalid data and permission errors require correction or escalation, not repeated unchanged attempts.
What is exponential backoff?
Increasing delay between retries, often with random jitter, to reduce load during temporary failure.
Why verify an action response?
A request being sent does not prove the external system completed the intended change.
What is a dead-letter or exception queue?
A holding path for failed events that require inspection, correction or controlled replay.
