Power Automate: your first reliable workflow
Design a reliable first workflow: map a repeatable process, connect a trigger to actions, add safe conditions, and handle failures without duplicate work.
Learn it here, one small step at a time.
4 guided lessons · About 2h 30m including practice · No subscription
- Map a process before automating it
- Build a trigger-condition-action outline
- Design retries, approvals, and failure checks
Map the work before automating it
Automation repeats a defined process; it cannot repair a process nobody understands. Write down what starts the work, what information is needed, what decisions people make, and what a finished result looks like. Begin with a low-risk task that happens often and has clear rules.
A simple workflow has a trigger (the event that starts it), actions (the work), and a result that someone can verify. Keep a person involved when a decision affects someone or needs context.
| Part | Example: supply request |
|---|---|
| Trigger | A request form is submitted |
| Input | Item, quantity, requester |
| Action | Check required fields and route approval |
| Done means | A decision is recorded and requester is notified |
Map a process you know using Trigger, Input, Action, and Done. Mark one step that still needs a person’s judgment.
Reveal a suggested answer
The map exposes unclear rules and missing inputs before they become repeated errors.
Optional further reading
Core lesson and practice are on this page. For more detail, visit the official free reference ↗.
Connect a trigger, condition, and action
In a flow tool such as Power Automate, choose a trigger such as “new form response.” Add an action only after checking the data it needs. A condition creates clear branches: if quantity is greater than a chosen limit, request approval; otherwise route the request for routine handling.
Use descriptive names for steps. Test one normal case and one case for each branch, then confirm the final record and message are correct.
| Step | Example | Question |
|---|---|---|
| Trigger | New request received | Can it start twice? |
| Condition | Quantity exceeds 10 | Is the threshold documented? |
| Action | Request approval | Who can approve it? |
| Result | Save decision | Where can we verify it? |
Write a two-branch flow for a request under or over 10 items. State who reviews the large request and where the result is recorded.
Reveal a suggested answer
A documented value or rule from the input, not an assumption hidden in the flow.
Optional further reading
Core lesson and practice are on this page. For more detail, visit the official free reference ↗.
Validate inputs and protect approvals
Check required fields and allowed values before writing to another system. A flow should say what happens when an email address is missing, a date is invalid, or a record cannot be found. Give the workflow only the permissions it needs and protect connection credentials.
Use human approval for decisions with financial, legal, safety, or personal consequences. Record who approved, when they decided, and which version of the request they reviewed.
| Field | Validation example | Failure response |
|---|---|---|
| Quantity | Positive whole number | Ask for correction |
| Present and valid format | Stop and report the issue | |
| Approval | Named authorized reviewer | Keep request pending |
List two bad inputs your workflow should reject. Decide what clear message a person will see for each one.
Reveal a suggested answer
No. Stop the affected run and report what needs correction so bad data is not written downstream.
Optional further reading
Core lesson and practice are on this page. For more detail, visit the official free reference ↗.
Retry safely and monitor failures
A network timeout may happen after an action succeeded but before the flow received confirmation. Blindly retrying could send two payments or create duplicate tickets. Use a unique request ID and check whether the action has already completed before trying again.
Create a failure path that alerts the right person with a useful run ID, but not private data in an insecure message. Test missing permissions, unavailable services, and duplicate triggers. Review run history so quiet failures are noticed.
| Situation | Safe response |
|---|---|
| Temporary timeout | Retry with a limit and check for existing work |
| Duplicate trigger | Use a unique request ID |
| Permission denied | Stop, alert owner, and request approved access |
| Bad input | Return it for correction |
Imagine the same request runs twice. Describe one check that prevents two copies of its approval record.
Reveal a suggested answer
An earlier attempt may already have succeeded; without an idempotency check, retries can repeat the action.
Optional further reading
Core lesson and practice are on this page. For more detail, visit the official free reference ↗.
Your final knowledge check.
Score 80% or more to pass. Sign in to save your best result.