Before connecting two apps, agree on the record identifier, the owner of each shared field, and the rules for updates and failures. Start with one workflow and prove the handoff works.
Your customer has one address in the sales system and another in the billing system. Someone corrects a phone number in a spreadsheet, but the old number reappears after the next sync. Connecting the apps was supposed to reduce work. Now the team has to decide which version to trust.
A useful integration needs more than a connection between accounts. It needs agreed rules for what information moves and what happens when the records disagree. For a small or midsize business, a simple mapping sheet can make those decisions visible before an automated workflow starts changing customer information.
1. Start with one business handoff
Pick a concrete event, such as moving an approved customer from your sales system into your billing system. Write down what starts the process, what should exist afterward, and who checks exceptions. Keep the first version small enough that the people doing the work can explain it.
For an illustrative service business, the handoff might create a billing customer after a project is approved. It might copy the company name and billing contact while leaving payment terms for an authorized team member to confirm. This is a planning example; choose the fields and approvals that fit your own operation.
Decide the direction of travel. Copying approved information from one system into another is easier to reason about than letting either system overwrite everything. Add a return path only where the business has a specific reason for it.
2. Decide which system owns each shared field
Give each field a clear authority. Your sales system might own the relationship owner and sales stage. Your billing system might own invoice status and the approved billing address. A field can appear in several places while one place remains responsible for its official value.
Create a mapping sheet with the source field, destination field, permitted values, update direction, and responsible person. Include what a blank means. Should an empty address leave the destination unchanged, clear the existing address, or stop the transfer for review? Those are different instructions.
Also define when a value may change. For example, a new billing email supplied during project onboarding could require confirmation before replacing an established contact. Write the rule in business language first, then have the implementer translate it into the integration.
3. Agree on how existing records are matched
Before creating a customer, decide how the integration will recognize one that already exists. A company name alone can be ambiguous. An email address may be shared or may change. Ask the implementer how a stable customer identifier will be preserved between the systems, and what happens when no reliable match exists.
Salesforce’s duplicate-management guidance, linked below, describes tools for identifying potential duplicates and controlling how they are handled. Our practical recommendation is to flag uncertain matches for review rather than automatically merge them. Two similar records may represent separate branches, contacts, or customers.
Check a small sample of existing data before switching on the connection. Include customers with similar names, missing details, and multiple contacts. Decide who can resolve a match and record the decision so the next transfer follows the same rule.
4. Specify what happens when the same event arrives again
Ask a direct question: if this transfer runs twice, will the destination contain one customer or two? Include retries and repeated button clicks in the design review. The desired result should be explicit, especially when the workflow also sends messages or creates follow-up tasks.
Microsoft documents an Upsert operation for standard Dataverse tables that updates a matching record or creates one when it does not exist. It is one platform-specific example of handling the create-or-update decision. Ask what your chosen integration supports and how it identifies the record; the feature name alone does not prove the whole workflow can be repeated safely.
Keep a visible record of failures with enough context to investigate. Assign someone to review them, decide whether a retry is appropriate, and check the result. A failed transfer should remain open work until the destination is verified.
5. Test the awkward cases before expanding
Use a test environment or clearly labeled test records, with permission from the people responsible for the systems. Try a new customer, an existing customer, a changed address, a missing required value, a repeated event, and conflicting edits. For each case, write the expected result before running it.
Inspect the destination record after each test. Check which fields changed, whether unrelated values were preserved, and whether any messages or tasks were created twice. Include an unavailable destination and confirm the team can find the failed work and recover it.
Launch a limited workflow with a named owner and review its exceptions. Expand only after the team understands how updates and corrections behave. If AI helps interpret an incoming request, keep uncertain output out of authoritative customer fields until it is reviewed.
At NextGenTech, we help map business workflows, connect applications, and define the checks around the handoff. If your team is copying the same information between systems or debating which record is correct, use the contact link below to discuss one workflow we can make clearer and more dependable.