Twenty questions to answer in writing before connecting two systems, in four groups: data, access, failure and ownership, with what a bad answer sounds like.
Key takeaways
- A question with no written answer gets answered in code, by somebody without the business context.
- "Both systems are up to date" is not an answer about the source of truth. It is a statement that there is none.
- Most late-arriving problems are born in the failure group, which is also the group people rush past.
- Every integration needs a named person. "The team" is not a person.
- An answer that starts with "that won't happen" marks exactly the case worth planning for.
Before you connect two systems there are twenty facts you need to know rather than guess. They fall into four groups: which data moves and who owns the truth, who grants access and where secrets live, what happens when something fails, and who is responsible after handover. Each question below also shows what a bad answer sounds like.
How do you use this list?
Go through it once, in writing, and mark each question one of three ways: answered, unanswered plus who should answer it, or not applicable plus why. That document is the output. It is worth more than a long specification, because you can come back to it when something breaks and see what was assumed.
| Group | What a good answer produces | What it prevents |
|---|---|---|
| Data | A field mapping table and a shared identifier | Duplicate records and an overwritten value |
| Access | A list of secrets with an owner and an expiry date | An expiry that takes everything down mid-month |
| Failure | An exceptions queue and an alert with a destination | Days when nothing ran and nobody knew |
| Ownership | A name, a response time, and a shutdown plan | A fault that circulates between three parties for a week |
Data: which facts must be settled before anything is written?
- Which system is the source of truth for each field? Without a per-field decision the two sides overwrite each other. Bad answer: "both systems".
- What shared identifier says two records are the same entity? This is the largest piece of work and the least visible. Bad answer: "we'll match on the name".
- Exactly which fields move, named on both sides? An explicit list prevents a mandatory field being discovered late. Bad answer: "all the customer details".
- What is the volume per run and is it growing? Volume decides whether the design is per record or per batch. Bad answer: "not much".
- What does a partial but still valid record look like? This defines what is rejected and what is accepted. Bad answer: "that won't happen".
Access: who grants it, for how long, and where it is stored
- Who on each side is authorised to issue the credential, and how long does that take? This is calendar time, not development time. Bad answer: "we'll open a ticket".
- What type of credential is it, what is its lifetime, and who is alerted before it expires? Expiry is a common and silent cause of outage. Bad answer: "it doesn't expire".
- Where will the secret be stored and who can read it? A secret sitting inside an automation workflow is visible to everyone who can open the workflow. Bad answer: "we keep it safe".
- Is there a non-production environment, and is its data representative? Without one, every test runs against real data. Bad answer: "we test carefully in production".
- Is anything restricting where calls come from - an IP allowlist, a VPN, a certificate? A restriction like this is usually discovered on go-live day. Bad answer: "no idea".
Failure: what happens when it does not work?
- What happens if the destination is unavailable for an hour? You need to know whether messages wait or vanish. Bad answer: "there's a retry", with no count and no destination.
- What happens if the same message arrives twice? With no uniqueness mechanism you get a duplicate document or a duplicate charge. Bad answer: "that doesn't happen".
- How does a person find out a run failed, and within how long? An alert with no human destination is the same as no alert. Bad answer: "it'll show up in the logs".
- Where does a rejected record go and who works it? You need a queue somebody opens, not a line in a file. Bad answer: "it gets logged".
- What happens when a record is corrected at the source after it was already synced? This is the question that produces silent divergence between systems. Bad answer: "we'll resync everything".
Ownership: who owns this after handover?
- Who is the named owner of the integration after go-live? With no name, every fault starts with a discussion about who handles it. Bad answer: "the team".
- Who pays when a vendor's version change breaks the connection? This will happen; the only question is when. Bad answer: "we'll deal with it then".
- What is the documented rollback if a run writes wrong data? You need written steps, not an intention. Bad answer: "we'll restore from backup".
- Where is the field mapping written down and who updates it? A mapping that exists only in code is lost the moment the developer changes. Bad answer: "it's in the code".
- Who is authorised to switch the integration off, and what happens manually while it is off? Without an answer, switching off becomes a business-process outage. Bad answer: "we can't switch it off".
Two answers written out in full
A good answer looks different from one that sounds good in a meeting. Two examples:
Question 2, the shared identifier. Weak answer: "we'll match on email". Written answer: the primary identifier is the customer number in the finance system. It is stored in a custom field in the second system and was populated by hand for the 1,840 existing customers. A new record without that number is not synced but goes into a matching queue reviewed once a day. Email matching is used only as a suggestion to a person, never as an automatic decision.
Question 14, a rejected record. Weak answer: "it gets written to the log". Written answer: a rejected record is stored with its original reason and the data exactly as it arrived, and appears on an exceptions screen with a re-run button. The process owner opens that screen each morning, and a record waiting longer than 48 hours raises a second alert. A handled exception stays on the list with a marker, so a repeating pattern is visible.
The difference between the two levels is not phrasing. It is how many decisions have already been made.
What to do with the answers
This list is not a form you fill in once. Keep the document beside the integration itself and return to it at three points: before go-live, after the first fault, and at every version change on the far side. A question whose answer has changed is the fastest explanation for a fault nobody understands.
Related: connecting systems in an Israeli business, silent failure in automation tools and how to monitor for it, what an API integration is.
Sources
Frequently asked questions
What if some of the questions have no answer?
That is normal at the start. Write the gap down as such: what is unknown, who should answer it, and by when. The questions still open at go-live are exactly the project's risk list, and it belongs in a document rather than in somebody's memory.
Who is supposed to answer these questions?
Not all of them the same person. The data questions belong to the process owner, the access questions to infrastructure or the vendor, the failure questions to the developer, and the ownership questions to whoever holds the budget. If a whole group has nobody to ask, that is a finding in itself.
Do all twenty apply to a small integration?
Yes, but the answer can be short. In a read-only integration several questions are answered in a sentence, and question 12 about duplicates may be genuinely irrelevant. The value is in having marked "not applicable, because", rather than having skipped it.
When do you return to the list after go-live?
At three fixed points: after the first fault, at every version change in either system, and whenever the responsible person changes. A changed answer to a question already answered is usually the explanation for a fault that otherwise looks inexplicable.
Keep reading
Related service
Integrations
Make the systems you already pay for talk to each other.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.