Start with a task you can inspect
Moving an approved inquiry into an internal work queue is a better first test than sending a customer a price or changing a payment. The difference is the consequence of being wrong—not whether the software can perform the action.
Fictional example: an inquiry form creates an internal task. The same submission arrives twice after a connection retries. Without duplicate protection, two people may contact the customer.
Write the rules before connecting the tools
- Trigger: one valid inquiry has arrived.
- Required information: an inquiry reference and the details needed to assign it.
- Duplicate rule: an inquiry reference can create only one task. A developer may call this an idempotency key; it is simply a way to recognize work already done.
- Missing-information rule: flag the record for review rather than guess.
- Owner: a named role checks failed transfers and unresolved items.
Try the failures on purpose
Use fictional or approved sample records. Test a normal submission, a missing field, a repeated submission, a temporary outage, and a permission failure. Confirm that retrying does not repeat a completed action. Keep a record of what happened without copying passwords or unnecessary customer data into logs.
Before using real work, agree on who can pause the connection and how the task will be completed manually. Keep a person at any step that sends a sensitive message, spends money, changes access, or makes a commitment.
Expand only after the first path holds up
Compare completed work, missed work, correction time, and review effort. A faster task that quietly creates extra cleanup is not an improvement. This checklist is a starting point for testing, not a safety certification.