Build and test the first flow
Want more background?
The idea in everyday life
Implement the smallest useful automation and verify each transformation before enabling real records.
Build like a pipeline: test one joint at a time before turning on full pressure.
One step at a time.
Use the sample or information you have permission to use. Keep your work as you go. You can pause between steps.
- 1
Open the pack’s index.html. Leave the manual batch trigger paused; set Approved-only, Require room and Check existing IDs ON. Select event_id, room and owner mappings; duration 15–120; alert owner Practice coordinator.
- 2
Load test-cases.csv. Press Run batch while paused: outputs stay empty. Enable the trigger, run once, and inspect every destination field, review item, alert and timestamped log entry.
- 3
Compare T01–T06 to expected-results.md: CREATED, CREATED, DUPLICATE, REVIEW, SKIPPED, ERROR. Expect 2 destination rows, 1 review item, 1 alert and 6 log entries.
- 4
Test 14, 121, blank and 15.5 as invalid duration variations. Deliberately map room from owner in a disposable run and catch the wrong field; restore room mapping, reset only that disposable run and retest. Pause and export the tested run.
See how it works.
The correct mappings produce B101/Room A/Lee/60 and B102/Room B/Noor/15. Mapping room from owner would wrongly produce Lee/Noor as rooms even though writes succeed. Your evidence compares values, not just green counts. The pack supplies executable runtime, CSV inputs and exact six-case outputs.
Did you cover these?
- Your work includes a disabled but fully tested workflow with field mappings, six test cases, expected results, and defect log.
- Check this common mistake: Testing only the expected successful case, seeing one success message, and assuming destination fields and duplicate behavior are correct.
- All defined test cases produce the expected destination, status, notification, or controlled rejection with no duplicates.
What to finish
A disabled but fully tested workflow with field mappings, six test cases, expected results, and defect log.
Watch for this
Testing only the expected successful case, seeing one success message, and assuming destination fields and duplicate behavior are correct.
How can I tell I understand it?
All defined test cases produce the expected destination, status, notification, or controlled rejection with no duplicates.
Quick knowledge check
Answer all 3 questions. Get at least 2 right and the lesson completes automatically.
You’ll get an explanation for each answer. Signed in? Your results save to your account.
Pass the check. We’ll save the progress.
Answer all 3 questions above and get at least 2 right. You can review the explanations and try again.
Go to the knowledge checkOptional course overview video · same video as Lesson 1
Power Automate Tutorials
From Microsoft Power Automate. Watch here or open it on YouTube .
Watch for an idea you can use in the practice below. You can pause or skip this optional overview.Tools, templates, and lesson sources
Tools and templates
Tools open in a new tab so you can keep your place here.
Sources and further reading
Explore the references behind this lesson.
Report a problem with this lesson
Tell us what went wrong. Please leave out personal information and private project contents.