# Integration at programme level: ownership before technology > Large integration estates rarely fail on protocol or platform. They fail because nobody could say who owned the field, who paid for the pipe, or who would be woken when it stopped. - Source: https://synconai.com/insights/enterprise-salesforce-integration-best-practices - Publisher: SynconAI (https://synconai.com) - Desk: Data & Integration - Author: SynconAI Architecture Team, Solution & technical architecture - Published: 25 May 2026 - Updated: 29 August 2026 - Reading time: 10 minutes - Topics: Integration, Governance, Enterprise Architecture, Data Ownership, Operating Model ## Key points - System of record is an attribute-level decision, not a system-level one. No single application owns a whole customer, which is why arguments framed as system against system never resolve. - Interfaces are funded once and inherited by nobody. Every interface needs a run budget and a named owner attached at design time, not discovered at the first upgrade. - Most large organisations cannot produce a current list of what connects to their Salesforce org. Until that register exists, every integration decision is being taken blind. - Whether Salesforce is the hub or a spoke should be a decision with a date against it. Left undecided, it becomes the hub by accretion, because it is the easiest place to add one more callout. --- Ask a large organisation why its integration estate is difficult and the answers come back technical. The middleware is old. The sync lags. The nightly job fails and somebody reruns it. There is a duplicate problem in accounts that nobody has got to the bottom of. Trace any of those to the decision that caused it and the decision is almost never technical. It is that two systems were allowed to write the same field without anyone recording which one wins. It is that an interface was built by a project that closed, and inherited by a team with no budget line for it. It is that nobody could name, on the day it broke, who was accountable for the data crossing it. Which pattern an individual interface uses is a real decision, and one worth taking properly: we set out how in [pick the integration pattern before you pick the middleware](/insights/pick-the-integration-pattern-first). This piece sits above that. These are the decisions that have to be settled across a whole estate, before any single interface is designed, and they are decisions about ownership, money and order rather than about technology. ::: takeaways Five programme decisions: which system owns each attribute, who funds each interface for its life, what currently connects to the org, in what order shared connections are built, and whether Salesforce is the hub or a spoke. None of them requires a platform expert. All of them are expensive to reverse. ::: ## System of record is decided per attribute, not per system The single most useful move available to an integration programme is to stop asking which system owns the customer. No system owns a whole customer. The finance platform is authoritative for the legal entity name and the billing address, because that is what appears on an invoice and what an auditor will test. The CRM is authoritative for the relationship: who the contacts are, what stage the opportunity has reached, which account team is on it. The consent platform is authoritative for whether that customer may be marketed to, because that is where a regulator expects the record to sit. The contract system is authoritative for entitlement. Framed as a system-level question, this argument does not resolve, because each participant is partly right and knows it. Framed per attribute, it resolves in an afternoon, because each attribute genuinely does have one obvious home once somebody asks where the consequence of getting it wrong lands. The artefact that comes out of that afternoon is an ownership register, and it is the most reused document the programme will produce. | Attribute | Owning system | Consumers | Named owner | | --- | --- | --- | --- | | Legal entity name | Finance platform | Salesforce, billing, service portal | Finance master data lead | | Billing address | Finance platform | Salesforce, billing | Finance master data lead | | Trading name and account team | Salesforce | Marketing platform, service portal | Sales operations manager | | Primary contact email | Salesforce | Marketing platform, billing, service portal | Sales operations manager | | Marketing consent and preferences | Consent platform | Salesforce, marketing platform, analytics | Privacy officer | | Service entitlement | Contract system | Salesforce, service portal | Service delivery lead | | Product and price list | Product master | Salesforce, billing, commerce | Commercial operations lead | Three rules make the register work. Every attribute has exactly one owning system. In every other system that attribute is read-only unless a write-back exception is written down, with a reason and an approver against it. And the owner column names a role held by a person, not a team, because a team cannot be asked a question. ::: note Ownership is not the same as where a value is typed. Sales teams will keep correcting billing addresses in the CRM, because that is the screen in front of them, and that is fine provided the correction is routed to the owning system and flows back, rather than being written locally and quietly diverging. Deciding capture separately from ownership removes an argument that otherwise repeats at every design review. ::: ## Who funds an interface, and who inherits it Integrations are built by projects. Projects end. That is the structural problem underneath most ageing integration estates, and no amount of engineering quality survives it. A project has a budget, a delivery date and a sponsor who wants a capability live. Building the interface is in scope. Operating it for eight years is in nobody's scope, because the operating cost falls in years when the project no longer exists. So the interface goes live, the project closes, the sponsor moves on, and what remains is an unowned dependency that works until a platform release, a certificate expiry or a schema change on the far side stops it. At that point somebody discovers that no team holds budget to fix it, no team has a person who understands it, and a business process has been quietly running on it for years. The remediation is then funded as an incident, which is the most expensive way to fund anything. Two funding models work, and either has to be chosen deliberately. **Consumer funded.** The team that needs the data pays for the interface and for its run cost. This is honest, and it makes demand visible: an interface nobody will pay to run is an interface nobody needs. It struggles when four consumers share one connection, because the first payer subsidises everybody after them. **Centrally funded platform.** A standing platform budget covers shared connections and projects consume them. This is the model that makes reuse actually happen, because reuse stops being an act of generosity by whichever project went first. It requires a platform team with a permanent budget, which is a harder conversation than any technical one on the programme. What does not work is the unstated third model, in which projects build and nobody runs. That is not a funding model. It is a liability booked as an asset. ::: warn The test of whether an interface is genuinely owned is not whether a name appears on a governance slide. It is whether that named owner can point at the budget line paying for the interface next financial year. If they cannot, the interface is unowned, whatever the pack says. ::: ## The register of what already connects Ask a large organisation for a current list of everything that talks to its Salesforce org. Give the request a week. What comes back is partial, assembled from memory, and missing the things built quickly by people who have since left. That gap matters more than it looks. Platform capacity for API traffic is a shared and bounded resource across the whole org, so an unregistered integration is spending an allowance that belongs to everyone else as well. It is also why release regression testing is incomplete in most estates: you cannot test what you have not listed. Assemble the register from evidence rather than from interviews. Enumerate the integration users and what each is entitled to do. Enumerate the connected apps and the credentials they use. Enumerate outbound endpoints and scheduled jobs. Pull the consumption picture by consumer out of whatever monitoring you have. Then compare that evidence against the list people gave you from memory, and treat the difference as the finding rather than as an administrative tidy-up. For each interface the register carries the business process it serves, the direction, the systems at each end, the owning business capability, the technical owner, the funding line, what breaks if it stops, and the date somebody last looked at it. That final column is the one that ages visibly, and it prompts the review nobody would otherwise call. An estate that cannot produce this list has no basis on which to choose middleware, because the requirement it would be choosing against is unknown. The register is the first artefact of an integration programme, not the documentation deliverable at the end of one. ## Sequencing when several projects need the same connection In a portfolio, the same connection gets requested three times in eighteen months by three unrelated projects. Each business case includes its own connector. Each is separately reasonable. Left alone, three variants of one interface get built, with three schemas, three owners and three different behaviours when the far side is unavailable. Nobody decided that. It is what happens when interfaces are sequenced inside projects rather than across the portfolio. The correction is simple in form and awkward in practice. Shared connections belong on the portfolio plan, with their own sequence, ahead of the projects that will consume them. Where that is not affordable, the first project builds the connection and the contract is designed with the second and third consumer in the room, even though they are not funded yet and their sponsors will resent being asked for requirements early. That last point is where the discipline sits. Whoever goes first sets the contract, and a contract shaped around one project's assumptions becomes the shape everyone else works around for years afterwards. Half a day with the future consumers is the cheapest architectural insurance available to a programme. Prioritise by dependency and reuse rather than by go-live date. The connection three initiatives need should be built before the one a single initiative needs, even when the single initiative shouts louder, because the shared one is the constraint on everything queued behind it. ## Hub or spoke: where Salesforce sits This decision is usually made by accretion. Salesforce holds the customer, the users live in it, and it is the easiest place to add one more callout. Do that for three years and the CRM is the hub, without anybody having decided that it should be. Ask the question explicitly instead, and answer it against the estate you actually have. [Salesforce Platform](https://www.salesforce.com/platform/) is a capable place to orchestrate customer processes, and in a modest estate, where nearly everything crossing the org is a customer process, Salesforce at the centre is defensible and cheaper than a dedicated layer. It stops being defensible on three signals. Traffic with nothing to do with customers begins crossing the org because a connection already existed there. The count of point-to-point connections rises to the level where a change at any endpoint requires a survey of the others. And processes with no customer in them start depending on CRM availability, which is a coupling nobody chose and nobody priced. At that point the estate wants an integration layer that each system talks to, with the CRM as one spoke among several. The trade is real: an [iPaaS](https://www.mulesoft.com/integration/ipaas-integration-platform-as-a-service) or equivalent adds licence cost, a skill set and another component to operate, in exchange for endpoints that can change without renegotiating with every partner. The [Salesforce architect resources](https://architect.salesforce.com/) are a reasonable place to pressure-test the shape before committing to it. Whichever way it goes, record the decision, the estate assumptions behind it, and the signal that would trigger a review. Left unrecorded, it gets relitigated by every new architect, and re-decided by accident in between. ## Who is paged when an interface fails at 2am This question is almost always unanswered until the night it matters, and it is then answered badly, by whoever happens to be reachable. Settle it at design time, per interface. Which team receives the alert. What severity a stopped interface carries, which is a business judgement rather than a technical one: an overnight finance feed and a marketing preference sync do not deserve the same response at three in the morning. Who tells the business owner, and whether they will hear it from monitoring or from a customer. And what the manual fallback is while the interface is down, because anything supporting a customer-facing process needs one. Two operational points earn their place at this level. Alert on the absence of expected traffic, not only on errors, because the characteristic large-estate failure is silent: a queue that stops, a job that no longer runs, a connection that succeeds and returns nothing. And agree in advance who authorises a reprocess after an outage, because replaying a backlog is a data decision belonging to the owner named in the register, not a judgement call for whoever is on shift. ## The governance that fits on one page Three artefacts and one rule carry most of the value here. The **ownership register** settles which system is authoritative for each attribute, with a named person against each one. The **interface register** records what exists, what it serves, who pays for it and who is paged. The **portfolio sequence** puts shared connections ahead of the projects consuming them. The rule: no interface gets built without a named owner at both ends and a funding line for the year after go-live. Add one forum with the authority to say no, meeting often enough that saying no does not delay anybody by a fortnight. A design authority that reviews interfaces before they are built is governance. One that reviews them afterwards is an audit function with a misleading name. Two adjacent decisions belong in the same conversation. Where a programme is consolidating customer data, ownership has to be settled before ingestion rather than discovered during it, which is the argument in [getting Data 360 right the first time](/insights/data-360-implementation-best-practices). And the identifiers every interface will join on are a data model commitment with a long tail, covered in [the data model decisions you cannot cheaply undo](/insights/data-model-decisions-you-cannot-undo). ::: tip If you take one thing from this piece, build the ownership register for the twenty or so attributes that cross more than one system. Two workshops, no tooling, and it pre-empts a category of argument that otherwise recurs at every design review for the life of the estate. ::: None of this replaces good engineering, and none of it substitutes for choosing the right pattern for each interface. It is what makes those choices possible to take once and hold, rather than re-taken by each project with slightly different assumptions until the estate is a record of who happened to be in the room.