Write the workflow in plain language
State the trigger, eligibility rule, destination action, and owner. For example: when an approved inquiry arrives, create or update one contact in the CRM and record the result. “Connect the form to the CRM” leaves too many decisions unspecified.
List which fields are required, which can be missing, and which should never be copied. Start with the minimum information needed to complete the task. Use a test destination while working out the behavior.
Choose a stable identifier
A unique submission ID identifies an event; a customer ID identifies a person or account. Those are different concepts. Decide whether the destination should contain one record per submission or one record per customer.
Zapier’s polling-trigger documentation describes how unique IDs help identify new items. That mechanism is specific to the trigger implementation. It does not automatically prove that every downstream create action is safe from duplication.
| Case | Decision to document |
|---|---|
| Same event arrives twice | Ignore, update, or return the earlier result? |
| Customer submits a new inquiry | New inquiry linked to an existing contact? |
| Destination succeeds but confirmation is lost | How will a retry discover the existing result? |
| Original record changes | Which fields may overwrite the destination? |
Plan for partial success
An automation can create a contact successfully and then fail while creating the follow-up task. Retrying the entire workflow without checking earlier results can create another contact. Log identifiers and outcomes so you can resume at the appropriate step.
Where the platform supports it, use a find-or-update operation or an idempotency mechanism appropriate to the destination. Check its actual guarantees, including how concurrent events behave. A simple “search then create” sequence can still race if two runs execute at once.
Test the awkward cases deliberately
- Send one valid test record and verify every destination field.
- Send the same event again and check for duplicates.
- Send an update to an existing record.
- Try missing optional data and invalid required data.
- Simulate a failed downstream step in the platform’s supported test environment.
- Check how retries, notifications, and manual recovery work.
Use fictional test data that cannot accidentally contact a real customer or change a live business record. Keep external messages disabled until the record-handling behavior is understood.
Assign a recovery owner
Someone should receive actionable failure notices and know where to inspect the run history. Document how to pause the automation, which records it may change, and how to correct a partial run. Avoid a workflow that silently depends on an employee’s personal account.
Start with a small controlled rollout and check the first real results. Do not interpret a successful test button as proof that every future event will be handled correctly.
Estimate the full operating cost
Repeated attempts, multi-step workflows, and usage limits may affect subscription needs. Read the current billing documentation for your selected platform. Use the software cost calculator for a basic budget, then add usage assumptions separately.
If the trigger is a meeting summary, verify the content before turning it into commitments. Our transcript and summary guide explains what deserves review before automation.
