Guide

What to check before connecting business systems

Write down which records move, in which direction and how often, what each system allows, and what happens when something fails.

By The Solva Group. Published 3 October 2026.

Before commissioning a system integration, identify the records that need to move, the source of truth and the access each system permits. The Solva Group recommends specifying direction, frequency and failure handling before the build. Rooftop's dealership reporting provides an example of reading existing systems into a shared view.

Name the systems and the access

  • Each system involved, and who in your business administers it.
  • What each one lets you export, and whether it offers a connection for other software.
  • Whether your plan or contract with the vendor allows that access.
  • Who can grant it, and how long that usually takes.

Describe one record's journey

Pick one record, such as a new customer, a sale or a job, and follow it. Where is it first entered? Which system should receive it? Which fields matter? Who notices today when it does not arrive? One record described properly is worth more than a list of systems.

A worksheet to copy

Fill in one set of lines for each record that needs to move.

  • Source system:
  • Destination system:
  • Record and required fields:
  • System that owns the correct value:
  • Read-only or write-back:
  • Update frequency:
  • Available export or connection:
  • What happens if a record is missing or rejected:
  • Who checks a failure:

Check a ready-made connection first

Check a ready-made connector first. Confirm that it supports the records, fields, direction, frequency and failure handling you need, then compare its costs and limitations with a custom connection.

Reading is not the same as writing back

A read-only connection retrieves information without changing the source system. Writing changes back adds decisions about permissions, validation and recovery. The scope of either depends on the systems, records and rules involved. The dealership reporting implementation is a reading example: Rooftop reads from the dealership's existing systems and combines them into reporting views.

A reading example

Reading existing systems: Rooftop.

Sources
  • Dealer management system
  • Sales log
  • Phone call records
  • Trade-in valuations
  • Website leads
Brought together

Rooftop checks and combines them through the day

Seen on

Office screens, phones and the showroom and workshop TVs

Illustrative screen · sample content

Quick answers

What if a system does not allow access?

Then that connection cannot be built as described. It is better to find that out before a quote than after. Sometimes a regular export is enough; sometimes the honest answer is no.

Do we need to replace the systems we use?

No. The point of an integration is to keep the systems that work and move information between them.

Can I use this checklist with another developer?

Yes. It is written to be used with anyone you ask for a price.

Where to go next.

Prefer a written workflow plan?

Rather have the plan written for you?

A Workflow Blueprint is a paid, fixed-fee plan for one business workflow, with a written scope and a build quote.

What a Workflow Blueprint includes

Tell us which systems need to connect.

A rough description is enough.