Describe the handoff
Consider a form that sends a sales enquiry into a CRM. The brief should describe what happens after submission: which record is created, who receives it and how that person knows what to do next.
Name the systems, fields and business rules in your own workflow.
Agree the trigger. A saved draft, a completed form and a verified email address are different events. Decide which one is allowed to create a record.
Decide who owns each field
Map every required form field to its destination. Include the format, whether it can be empty and what happens when its value is unexpected. A date, a phone number and a choice from a list each need different checks.
Decide which system owns a value when a record already exists. Should a new form submission overwrite the company name in the CRM, add a note or ask someone to review the change?
Only send fields the receiving workflow needs. Put consent or contact preferences into the brief explicitly instead of inferring them from a form submission.
Plan for failed and repeated submissions
Describe what happens when the CRM is unavailable or rejects a record. Name the person who receives the failure notification and how they find the original submission.
Include repeated events in the test plan. Someone can press Submit twice, or a system can resend an event after a delay. Define how the integration identifies a submission so a retry does not create an unintended second lead.
Test the complete route
Write acceptance checks before implementation. For this example:
- A valid new enquiry reaches the agreed owner with the required fields.
- A repeated submission follows the agreed duplicate rule.
- An invalid field produces a useful error and remains available for correction.
- A failed transfer can be identified and retried without losing the enquiry.
Run the checks in a test environment where available. Confirm the destination record and the notification as part of the test.
Name the owner after launch
Record who can change the field mapping, renew access and investigate a failed transfer. Include where the integration runs and how to pause it in the handover.
The implementation can deliver an enquiry to the right place. The receiving team still needs a follow-up process and someone responsible for using it.
Write a field map before choosing a tool
A field map can be a short document. For each field, record its source, destination, validation rule, overwrite rule and owner. Here is a fictional example:
- Submission ID: generated once when the form is accepted; retained on retries so the same event can be recognised.
- Email: checked before transfer; used for matching only under an agreed rule. A shared mailbox may represent more than one person.
- Company name: sent with a new record; a different value on an existing record is flagged for review instead of silently replacing it.
- Contact preference: kept with its source and timestamp where required by the workflow. An enquiry is not automatically a marketing opt-in.
- Assigned owner: chosen by the receiving team's rule, with an agreed fallback when that person is unavailable.
For each test, record the original submission, the destination record and the outcome. Keep credentials and unnecessary personal data out of logs. If the CRM accepts a record but the connection times out before confirmation, a retry must check whether that submission already arrived.
Moving existing records is a separate job from sending new submissions. Use the data migration checklist to plan that move, and see Integrations, Automation & AI for the service scope.