Ten checks before relying on an automation

Prepare an isolated copy

Illustrative scenario: a form saves an inquiry and hands it to a teammate. The first test looks correct, but repeated delivery and revoked access are still unexamined.

Use an isolated copy with fictional data and your own test recipient. In Make, copy the scenario into a test version, inspect every destination module, and disable production messaging in the copy. If you cannot establish isolation, ask a maintainer to prepare it before inducing failures. Do not experiment on live client work.

Download the ten-check record. Import it through File → Import → Upload in Google Sheets. Enter the tester, date, observed result, and evidence link. Initial status is “not run,” not success.

Checks 1–3: valid input and identity

1. Ordinary inquiry. Submit test FORM-101 with a contact and request. Open the destination and compare required fields and original arrival time. A usable record is the outcome; a green run alone is insufficient.
2. The same event again. Replay the retained input with the same identifier in the test environment. Simply submitting another form may create a new identifier. Expect the existing action to be found, rather than another card.
3. The same contact, different work. New FORM-102 asks for training rather than a website. It should remain a separate inquiry. Contact matching must not erase separate projects.

Checks 4–6: missing data and partial completion

4. Missing contact. Remove the contact from test input only. Expect a retained case assigned for clarification, rather than a fabricated address or silent loss.
5. Destination access fails. Use a separate test connection without the necessary permission. Expect retained input and an inspectable error. Do not revoke a shared production connection.
6. The write succeeds; a later step fails. In the copy, introduce a controlled failure after creating the test card. Confirm the card exists before recovery. Recovery must not create a second one. Make requires incomplete-execution storage to be configured separately.

Checks 7–10: concurrency, changes, and absence

7. Two simultaneous inputs for one action. Submit two copies of a known test event close together. Inspect both runs and the destination. Ordered processing in one scenario does not necessarily coordinate another scenario or a human writer; Make explains its ordered-processing setting.
8. Approval changes. If the workflow hands over approved work, revoke approval in the test record before handover. Expect handover to stop. If approval is irrelevant to the process, mark the check “not applicable” with a reason.
9. No run occurs. Disable scheduling in the test copy while retaining the expected deadline in an independent check. That check should identify the missing result. The scenario’s own error message is insufficient for this case.
10. Backup coverage. Have the backup person open the original input, result, and test record with their own account. They must understand what happened and what comes next without sharing a password.

Act on the findings

Record a specific gap and next action for each failure. Rerun the check after fixing it and check other affected behavior when appropriate. An unexplained skipped check is not a pass. Use safe recovery for partial completion and deadline monitoring for missing runs.

Documentation reviewed October 1, 2026. The record is our proposed test method, not evidence that your connection passed or a promise to detect every failure.