01 — A useful first connection
Start with the job someone needs to do.
Before connecting your CRM and accounting software, agree what your team needs to see or do. Then decide which system owns the information, how records will match, how current the view needs to be and who deals with a failed update.
“Sync the systems” leaves too much open. A more useful brief is: sales needs to see whether a particular invoice has been paid before calling the customer, without asking accounts to check it each time.
That might only need a read-only view in the CRM. Creating accounting customers, sending approved orders or updating billing details are separate workflows with their own permissions and checks. You can decide whether to include them once the first task is clear.
The example in this guide
Accounts changes the invoice status.
The connection finds the matching customer.
Sales sees the status and when it was checked.
An illustrative workflow, not a claim about a particular client or a ready-made connector.
Walk through the task with the people who do it. Ask what they check before making a decision, where they find it and what happens when the information disagrees. Bring an example with unnecessary personal details removed.
02 — Decide where changes belong
Give each field a clear owner.
Two systems can hold different views of the same customer without both being allowed to change every detail. Decide where each field is maintained and which people can edit it. The connection should follow those decisions.
In our example, finance controls invoice and payment information. Sales manages its contacts and pipeline in the CRM. An invoice status can be visible to sales without granting access to alter the underlying invoice.
Scroll the table sideways to read all three columns.
| Information | Source | What the connection does |
|---|---|---|
| Account identifier | An agreed mapping | Link the CRM customer to the accounting customer. Keep both system IDs; they may be different. |
| Sales contact and account owner | CRM | Sales manages the relationship. Share only the contact information accounts actually needs. |
| Invoice and payment status | Accounting | Show the agreed status in the CRM as read-only, with the time it was last checked. |
| Billing details and payment terms | Accounting, in this example | Finance approves changes. A CRM edit should not silently overwrite the billing record. |
If two teams need to propose changes to the same field, define an approval route. Also decide what a blank value means: missing information, an instruction to remove a value, or no change. Treating those as identical can erase useful data.
Give the integration only the access it needs. A view of selected account information may be sufficient; copying every invoice, note and attachment creates more to secure and maintain.
03 — Identity and freshness
Match the right record. Show how current it is.
Agree how the same customer is recognised.
Names change, people share email addresses and one company may have several branches or billing accounts. Agree how the CRM record links to the accounting record, ideally using stable identifiers held in a mapping. The two systems do not need to use the same ID.
Check the existing data before enabling updates. A customer with two possible matches should go to review. Automatically creating a new customer every time a match is unclear can make the original problem worse.
Migration needs its own scope. Decide whether the connection starts with new records, existing active customers or historical invoices, and how that initial set will be checked.
Choose timing to suit the decision.
A daily refresh may suit a report. A salesperson deciding what to say on a call may need a more recent view. Agree a useful delay and check whether the software can support it at your expected volume.
Ask what the user will see when a refresh fails. Keep the last successful check visible and clearly mark stale information. A timestamp saying the page was opened is not evidence that accounts was checked successfully.
04 — Choose the simplest suitable route
An existing connector may be enough.
Start by checking the supported integrations available for your exact products, versions and plans. A connector appearing in a marketplace does not establish that it covers the records, direction and business rules you need.
Configure an existing connector
Useful when its supported records, mapping, timing, permissions and recovery fit the task. Test it with your awkward records as well as a clean example.
Use an automation tool
Useful when you need to join several steps, transform fields or route exceptions. Check ongoing usage costs, access, logs and who can maintain the workflow.
Build a custom connection
Useful when a necessary business rule, interface or recovery requirement cannot be handled reliably through configuration. It still depends on what the connected systems allow.
A small proof of the uncertain part can help before committing to a full build: can the required invoice field be read, can an approved record be created safely, or can a permission boundary be enforced? Agree what that investigation should establish.
Costs depend on the workflows, data cleanup, migration, interfaces, permissions, update timing and recovery requirements. Ask for build costs and recurring software, hosting and support costs separately. A tool subscription is only one part of running the connection.
For a comparison of adaptable CRM, data and automation tools, see our business-tools guide.
05 — Plan beyond the successful demo
Define a safe failure before launch.
A timeout does not necessarily mean the other system rejected an update. It may have created the record before the response was lost. Sending the request again without checking can create a second order or invoice.
Ask how the connection recognises a repeated request, records what the other system accepted and makes a retry safe. Technical support for this varies, so the developer needs to verify the actual API or connector behaviour.
Some failures need a person: an unknown customer, missing approval or conflicting edits. Define who sees these exceptions, what information they receive and who can correct and resubmit them. A log that nobody reviews is not an operating process.
Agree checks your team can recognise.
- An update reaches the intended customer and the correct fields change.
- A repeated notification does not create a second record.
- An unmatched customer waits for review instead of being linked by guesswork.
- An outage makes stale information visible and alerts the agreed owner.
- A user cannot see or change information outside their agreed access.
- The source and destination records reconcile after recovery.
Plan the switch from the old process. If someone continues entering invoices manually while the new connection also creates them, the launch itself can introduce duplicates. Agree when each process starts and stops, who checks the first results and when to pause the integration.
For a connection that changes financial records, agree how mistakes will be corrected with the accounts team. Simply deleting a record may not be an appropriate recovery step. Confirm monitoring, access renewal and support responsibilities before handover.
06 — A brief you can use
Write down what you know. Keep the open questions.
Complete this with someone from sales, someone from accounts and whoever looks after your software. You do not need all the answers to start. Uncertainty about an API or a matching rule is useful scope for the initial investigation.
Describe the process using example or redacted records. Keep passwords, access tokens and real customer information out of the brief.
Your integration brief
Who copies, checks or chases what today?
Include the exact product, version or plan if known.
Which information moves, and what identifies the same customer?
Which system owns each field? Who only needs to view it?
How current must it be? Roughly how many records or updates?
Missing records, duplicate customers, outages or conflicting edits.
A real scenario, the expected result and who approves it.
Who handles exceptions? Any deadline, budget, migration or support needs?
Download it blank or add your answers first. This worksheet is not submitted to Launched. Your answers are not saved if you reload or leave this page.
07 — From the brief to the work
How Launched can help.
We connect business systems and build the tools teams need around them. We start with the task, check the access and data, and agree the scope and acceptance checks before building.
In our recruitment project, the previous CRM had no API. We selected a replacement, tested its API and migrated the records. We also built the website, applications for staff and clients, and sales dashboards, with Airtable holding application data and n8n connecting the systems.
That project demonstrates CRM migration and connected applications. The sales/accounts example in this guide is illustrative; it is not an accounting-integration result attributed to that client.
Comparing development teams? Our software buyer guide covers proposals, ownership and support. You can also read how we work with your team.