Before an AI intake workflow writes to your CRM, test whether one approved inquiry stays one record when a message repeats, an update arrives late, or the connection times out. Use fictional records, require a human decision on proposed fields, and read the saved result back from the CRM. Keep the workflow in a staff-reviewed queue until those checks pass.
This checklist is for a Canadian service business preparing a narrow lead-intake integration. It helps an owner and implementer agree on evidence before using customer records. AI may help extract a proposed service request from free text; event tracking, required-field checks, permission limits, and retry rules usually need deterministic controls. A simple form and staff review may be enough.
This is a proposed Inquory worksheet, not a report of product testing. All examples are fictional. We did not connect a CRM, process customer records, or measure a vendor's reliability. Research and drafting were AI-assisted; see how Inquory uses AI.
1. Define what the integration may change
Start with one output: a proposed inquiry record for staff review. Keep sending messages, booking visits, rejecting leads, invoicing, and deleting records outside this pilot. If you need help selecting that boundary, use the first AI workflow guide.
For each proposed field, preserve a reference to the source passage and the reviewer's accepted, corrected, or rejected decision. Missing service details should stay missing until clarified. Use the lead-intake guardrails before testing the write itself.
Copy this setup worksheet and fill in an answer with your implementer. A blank safety-critical answer means the test is not ready to start.
| Setup item | Write down before testing |
|---|---|
| Destination | CRM product, record type, and isolated test environment |
| Responsibility | Test owner, approving staff member, and repair owner |
| Allowed change | Exact fields and whether the operation creates or updates a record |
| Forbidden actions | Customer messages, bookings, rejection, invoicing, deletion, and anything else outside scope |
| Identity and version | Source-event ID, approved destination key, and expected-version mechanism |
| Evidence | How to read the saved destination ID, relevant fields, version, and status |
| Access and recovery | Limited test credential, revocation process, and verified way to restore changed test records |
| Stop rule | Events that stop the test, maximum repair time, and manual fallback |
Use synthetic names, requests, and contact details that cannot reach a real person. Confirm that the test environment cannot send live messages or trigger other customer actions. If the vendor cannot isolate those effects, keep the exercise to a staff-reviewed proposal and obtain a suitable test setup before enabling writes.
2. Separate event identity from customer identity
A source-event ID identifies an incoming event and all its delivery retries. A destination key identifies the CRM record that the event is allowed to affect. A record version identifies the state that an update expects to change. These solve different problems.
Assign the event ID when the inquiry first enters the system. Retries retain that ID. A later staff correction gets a new event ID and identifies the record version it expects to update. Do not use a name or phone number alone as a universal customer identity: people may share a number or change it. Ask the implementer how ambiguous matches are held for review.
Consider this fictional sequence. Event EVT-0041 carries a reviewed inquiry with approved key INQ-2041. The CRM accepts it as record LEAD-713, version 7. A retry of EVT-0041 should resolve to the same logical write, with no second downstream action. A staff correction arrives as EVT-0042, expecting version 7. If accepted, readback should show the same record with the correction and a new version. A delayed request still expecting version 7 should be rejected or quarantined.
Those IDs and version numbers are illustrations. Your CRM may use a different version token or matching mechanism. A successful request response alone does not establish that these controls exist.
3. Check the actual CRM's write semantics
Microsoft documents Dataverse Upsert as a create-or-update operation. For standard tables, it finds a record using its primary or alternate key, then performs an update or create. That is one platform's behavior; it does not make every CRM integration safe from duplicate effects.
Dataverse's alternate-key documentation adds two conditions worth checking: null values in alternate-key columns do not enforce uniqueness, and a configured key is not available until its supporting index is active. The Upsert documentation also describes different behavior for elastic tables. Ask your implementer to show the actual table type, active key, and request body being tested.
Similarly, Dataverse optimistic concurrency can detect an intervening record change when the table supports it and the client uses the expected row version with the appropriate concurrency behavior. It is not automatic protection for every update. Microsoft's duplicate-detection guidance warns that records processed at the same moment may still produce duplicates.
For another CRM, obtain the equivalent primary documentation and test its behavior. A duplicate-warning screen, an upsert option, and a retry switch are not interchangeable guarantees.
4. Run the failure cases before real intake
Write the expected outcome first. Run each case in the isolated test setup, retain every attempt, and inspect the destination rather than relying only on the integration dashboard. This is a proposed test suite; no product is claimed to have passed it.
| Synthetic case | Expected result | Stop and investigate if |
|---|---|---|
| Deliver the same event twice, including overlapping deliveries | Both attempts resolve to one reviewed logical write; no duplicate downstream action | A second lead or action appears |
| Deliver an old correction after a newer staff edit | The stale update is rejected or held for review | Newer work is silently overwritten |
| Omit a required service field | The proposal waits for clarification | A value is invented or an incomplete record is marked complete |
| Time out after sending the write request | Check destination state before deciding whether to retry | The system blindly retries an outcome it cannot establish |
| Send a field value the destination rejects | Keep the source event and error available to the repair owner | The event disappears or the dashboard reports success |
| Attempt an out-of-scope write with the test credential | Access is denied and no destination change occurs | The credential can alter unauthorized fields, records, or actions |
Test duplicate delivery and stale updates separately. Preventing a second record does not prove that an old request cannot overwrite a newer correction. Also check whether a retried write causes a notification or task twice even when only one CRM record exists.
5. Keep an attempt log and reconcile timeouts
Copy one instance of this record for every attempt. Do not remove failed cases or replace several retries with a single successful screenshot.
| Attempt record | Value to capture |
|---|---|
| Case and event | Test-case ID, source-event ID, and synthetic test-set version |
| Approved change | Destination key, field-map revision, approving reviewer, and expected version |
| Attempt | Attempt number and time, response class or timeout |
| Destination readback | Record ID, version, relevant saved values, and readback time |
| Outcome | Pass, repair required, stop, or unknown outcome |
| Follow-up | Repair owner, minutes spent, and final reconciled result |
An unknown outcome means neither success nor failure has been established. The operator should look up the destination using the approved key and inspect the relevant saved values and version. If the result cannot be established safely, hold further attempts for manual reconciliation. A second request is not a substitute for finding out what the first one did.
Count unique source events separately from write attempts. Also count accepted records, duplicate effects, stale-update rejections, unknown outcomes, and cases needing repair. Keep every attempted case in the denominator. Use the AI pilot measurement worksheet to compare that repair effort with the simpler staff-reviewed process. A high completion percentage can conceal expensive correction work.
6. Decide whether to proceed, revise, or stop
Declare acceptance conditions before seeing the results. For this proposed synthetic test, start with zero unapproved writes, zero duplicate customer actions, and zero silent overwrites of newer staff corrections. Require each accepted write to have a destination ID and readback result, and each timeout to be reconciled before retry. Give every failed case a repair owner. These are proposed controls, not industry benchmarks or evidence that a small sample predicts production reliability.
Set a repair-time limit suited to the business and compare it with the manual baseline. If any case remains unresolved, revise the integration and rerun the affected tests. Repeat relevant checks after changes to the model, field map, destination key, permissions, or retry behavior. Keep a named person able to stop the pilot and return intake to the reviewed queue.
The Canadian Centre for Cyber Security's small-organization baseline recommends giving accounts only the functionality their tasks require and testing backup and recovery mechanisms. Apply those principles to the test credential and recovery plan. The guidance does not prove that a particular CRM can restore an overwritten record; verify that capability separately before risking real data.
Proceed to a limited, supervised pilot only when the agreed controls work and the repair burden is acceptable. If the AI step adds little beyond a simple form or creates more repair work, keep the simpler workflow. If you later include appointment changes, use the separate scheduling and confirmation guide to define that additional boundary.
Review this checklist when the cited platform behavior, your integration, or the proposed method materially changes. It is an acceptance aid, not a vendor certification or a substitute for the business's privacy and security review.