Who this is for: CRM owners planning native workflows, integrations, or migrations.
CRM automation changes records or starts work when an event or condition occurs. Assigning a lead can stay inside the CRM. Creating a billing customer or synchronizing a project usually crosses an application boundary.
That boundary is where ownership matters. Before configuring Salesforce, HubSpot, or an integration platform, decide which record is being changed, who owns each field, and how a conflicting update will be handled.
Keep native work native when the rules fit
For an illustrative lead-routing workflow, define the inputs first: territory, product interest, account owner, and whether the assigned person is available. Define a fallback queue for missing or conflicting information.
In Salesforce, evaluate a record-triggered Flow against the object and ownership behavior you need. In HubSpot, evaluate workflow enrollment and assignment actions. Exact actions and availability depend on the current subscription and permissions; verify them in the actual account. Use the linked platform walkthroughs as context, not as evidence that your edition includes every action.
| Decision | Rule to specify |
|---|---|
| Existing customer | Preserve account ownership or document an exception |
| New lead | Use the approved territory and product rules |
| Missing territory | Send to a named review queue |
| Owner absent | Use an active delegate or fallback queue |
| Lead edited later | State whether reassignment is permitted |
Cross a system boundary deliberately
An integration is appropriate when another system must accept or return state. For example, a CRM account may need the billing platform's customer ID. Match or create that customer once, then save the resulting ID so later events don't depend on fuzzy name matching.
Document what must be immediate and what can reconcile on a schedule. A retry is safe only if you can identify a previous successful write. A timeout can happen after the destination has already created the record.
Define source-of-truth and blank-value behavior
Choose the authoritative system per field, not per application as a whole. Sales may own an account manager; finance may own a billing address after verification. Neither system needs to overwrite every field in the other.
Treat absent, blank, and intentionally cleared values as distinct when the process needs that distinction. A partial event payload should not erase a valid billing address. Changes to bank details should use a separate verified process, rather than ordinary profile synchronization.
| Field | CRM input | Billing value | Decision |
|---|---|---|---|
| External customer ID | cus_demo_104 | cus_demo_104 | Match by persisted ID |
| Account owner | Alex | Older copied value | CRM owner wins |
| Billing address | Not supplied in event | Verified address | Preserve billing value |
| Company name | Acme Services | Acme Services LLC | Review naming rule; don't rematch automatically |
Test migration and everyday updates separately
A migration moves a history of records. A live workflow handles changes over time. Test both: initial imports, edits arriving out of order, duplicate events, deletions, and records restored after deletion.
Reconcile a representative sample by identifier and field value, not only by record count. Equal counts can still hide wrong associations. Keep a rejected-row report with a reason and an owner, and prevent the next import from silently reintroducing the same error.
- Persistent IDs survive export, import, and replay.
- Blank values follow an explicit rule.
- Conflicting edits have an owner.
- Deletion behavior is documented for each system.
- Counts and sampled values both reconcile.
Free download · No email required
CRM validation test sheet
Use synthetic records in a sandbox. Record expected values before running tests; do not accept matching counts as proof of correct relationships.
Open the CSV in Excel, Google Sheets, or another spreadsheet tool. The Markdown brief is editable in a text editor.
Common questions
- Do we need an integration platform for every CRM workflow?
- No. First check whether the CRM can execute the required rule with the controls and limits your account supports. Introduce another platform when the process actually crosses that boundary.
- Can we use email as the record identifier?
- Sometimes it is a useful matching input, but it may change or be shared. Prefer persisted system identifiers after a verified match, and route ambiguous cases for review.
