Free tools / Checklist
Four tests to run before you trust an automation
A workflow that works once, with tidy test data, hasn't really been tested. These four cases cover the awkward situations an enquiry workflow meets sooner or later. Run each one with dummy data before a real enquiry goes through it.
00Before you start
- Use a test copy. A test record type, a sandbox, or a copy of the spreadsheet. Never test on live client records.
- Use dummy details only. No real names, emails, or phone numbers.
- Write down what should happen first. If you decide what "right" looks like after the run, the test turns into a guess.
- Run the normal case once. One complete, ordinary enquiry should give exactly one record, one task, and one notification.
01Missing answer
- Send
- An enquiry with the email, or another answer the record needs, left blank.
- Should happen
- It's held for review, no record is created, and someone is told.
- Why it matters
- People type whatever they type, and emails arrive in every shape. A rule for blanks is the difference between a held enquiry and a broken record.
02Same person twice
- Send
- Two enquiries from the same email address on the same day.
- Should happen
- The second is flagged, or added to the first record. No second record and no second follow-up task.
- Why it matters
- People chase when they don't hear back. Two records can mean two people calling the same client.
03Reviewer says no
- Do
- Reject the draft at the review step.
- Should happen
- Nothing is saved, nothing is sent, and the rejection is noted with a reason.
- Why it matters
- A review step only counts if "no" really stops the workflow.
04Connection fails
- Do
- In the test copy, break the link to the CRM on purpose, for example by turning the connection off.
- Should happen
- The workflow stops and says so, leaves no half-made record, and tells someone. Running it again afterwards must not create a duplicate.
- Why it matters
- Microsoft's reliability guidance makes the same point: test how a system behaves when the services it depends on fail, design each step so repeating it doesn't cause duplicates, and make sure nothing gets lost once retries run out.
05The test log
Fill in "What happened" only after you've run the case. Don't mark anything as passed from memory. Your entries are saved in this browser only.
| Case | What should happen | What happened | Status | Who follows up |
|---|
Prefer a blank file? Download the empty test log (CSV).
06After the tests
- Anything marked Failed or Fix needed gets a named person and a date.
- After any fix, run the whole list again, not just the case that failed. Fixes have a habit of moving problems around.
- Keep the log with the handoff notes, so whoever runs the workflow later knows exactly what was tested.
Sources, checked October 20, 2026
- Microsoft Learn: Architecture strategies for designing a reliability testing strategy
- Microsoft Learn: Recommendations for handling transient faults