Your Data Silos Are Not Just Separate Databases: Six Breaks Owners Should Look For

A business can put every application under one vendor, copy every record into one warehouse, and still have data silos. Separate databases are only the most visible kind.

A silo exists whenever an important business fact cannot cross a boundary with its identity, meaning, timing, access, and next action intact. The customer record may be available in five places while the business still cannot answer who the customer is, what happened, or what someone should do next.

That broader definition changes the diagnosis. It replaces the vague instruction to "integrate the tools" with six specific tests an owner can run before buying another connector, reporting layer, CRM, or AI assistant.

A boundary is not automatically a failure

Payroll should not be visible to everyone. Accounting and customer service may need different controls. A scheduling system may be better at appointments than a CRM. Separate applications, environments, and permission boundaries can be deliberate protections or sensible divisions of work.

The problem begins when two places independently define the same business fact, or when a necessary fact cannot reach the person and decision that depend on it. Microsoft's current cloud architecture guidance, for example, treats duplicated records as a valid distributed-data pattern when one service clearly owns the authoritative record and the copies are synchronized. The dangerous condition is not duplication by itself; it is ambiguous authority and unmanaged change.

1. Storage silos: the records live in different places

This is the familiar version. Website forms, email, CRM, scheduling, project management, support, and accounting each store part of the customer's history. A warehouse or native connector can make those records easier to retrieve, but access alone does not establish whether the copies are complete or which source may change them.

The boundary can remain even inside one branded suite. Microsoft documents that Dynamics 365 Finance and Operations and Dataverse represent customers differently and require table maps to exchange them. A shared vendor reduces some integration work; it does not guarantee one object model or one record.

Diagnostic example: A customer changes an address in the service portal. The CRM updates, but an open estimate and the accounting record retain older copies. Which address should the next job use?
Owner test: List every place that can create or edit the same customer fact. Mark one authoritative source and show how every necessary copy receives corrections and deletions.

2. Identity silos: the systems do not know it is the same customer

Each application creates its own identifier. Names vary, emails change, one phone number can represent a household, and a business may appear as a company in one system and several contacts in another. Moving the fields does not solve the matching decision.

Identity-resolution systems make that decision through match and reconciliation rules. Salesforce's current Data 360 architecture, for example, maps source records to a shared model and then applies rules to link profiles. Salesforce also distinguishes that unified profile from a master-data golden record. The distinction matters: finding likely related records is not the same as authorizing one value to overwrite every source.

Diagnostic example: One person submits a form with a personal email, books with a work email, and pays under a company name. The dashboard counts three people and cannot connect the payment to the original inquiry.
Owner test: Follow one real customer across the stack. Record the identifier each system uses, the match rule, the confidence or exception process, and what happens after a merge or correction.

3. Semantic silos: the same words mean different things

Two reports can use the label "customer" and count different populations. Sales may mean an accepted opportunity, service may mean anyone with an open request, and accounting may mean an entity with a paid invoice. The columns align while the meanings do not.

NIST identifies these independent semantic models as a core interoperability problem. A field map can move status into another status field, but it cannot decide whether "closed" means won, completed, invoiced, paid, cancelled, or simply no longer active.

Diagnostic example: Marketing reports 120 leads, the CRM reports 74, and sales recognizes 31. None is necessarily wrong; each may be answering a different question with the same label.
Owner test: Choose five terms that drive money or capacity. Write the operational definition, qualifying event, exclusions, date rule, and authoritative source for each one.

4. Permission silos: the right record exists, but the right role cannot use it

Security is supposed to limit access. The failure is not that everyone cannot see everything. It is that a role cannot see the minimum fact needed to complete authorized work, or that a copied workaround exposes more information than the role should receive.

Permission boundaries can also differ by environment, object, field, record, integration account, and API. A connector may be installed while its service account cannot read a required field, observe a deletion, or write the returned status. The interface says "connected" while the business path remains incomplete.

Diagnostic example: Dispatch can see an appointment but not the approved service notes. An employee copies the notes into a shared spreadsheet, creating a less controlled record to work around a restrictive view.
Owner test: Test the process while signed in as the actual employee and integration identities. Verify the least information each needs, the action it must perform, and the audit trail it leaves.

5. Temporal silos: each system is correct at a different time

Data can be accurate and late. Batch imports, polling, queues, retries, rate limits, offline work, and manual updates create several versions of "now." Event-driven architecture reduces some delays, but Microsoft's current guidance still requires teams to design for eventual consistency, duplicate events, ordering, and error recovery.

A dashboard refreshed this morning, a CRM updated five minutes ago, and an accounting close finalized yesterday can all be internally consistent. Combining their totals without a shared as-of rule creates a false disagreement.

Diagnostic example: A cancellation reaches scheduling immediately but reaches the CRM after a retry. An automated message fires from the older CRM status during the delay.
Owner test: For each important update, document the expected latency, source timestamp, retry behavior, failure queue, monitoring owner, and rule for late or out-of-order changes.

6. Workflow silos: the information arrives, but the work does not move

This is the silo most likely to survive a successful technical integration. The receiving system has the record, but no one owns the transition, no task is created, the acceptance condition is undefined, or the completion event never returns to the earlier system.

A workflow silo is not solved by adding more fields. It is solved by defining the trigger, responsible role, required context, expected action, completion evidence, exception path, and next handoff.

Diagnostic example: A website inquiry enters the CRM with every requested field. No routing rule assigns it, no response timer starts, and no later booking or payment returns to close the record.
Owner test: Name the event that makes the next action necessary, the role that accepts it, the evidence that proves completion, and what becomes visible when the handoff fails.

Run the six-silo diagnostic on one real record

Do not begin with an application inventory or a promised integration diagram. Choose one recently completed customer journey and trace it from entry to payment or another meaningful outcome.

Storage: Where did a copy exist, and which source could change each fact?
Identity: What identifier connected the same customer and transaction?
Meaning: Did every status and measure retain the same definition?
Permission: Could each authorized role and integration use the necessary fact?
Time: When did each source know, and how were delays or retries handled?
Workflow: What event moved the work, who acted, and what proved completion?

Mark every break with evidence: a duplicate, unmatched identifier, disputed definition, denied field, stale update, missing task, or unresolved exception. That evidence distinguishes a software limitation from a configuration, governance, training, or process problem.

Repair the broken layer, not the most visible symptom

Storage is the break: Consolidate, integrate, or deliberately synchronize the necessary facts and correction paths.
Identity is the break: Define durable keys, match rules, merge behavior, source priority, and an exception queue.
Meaning is the break: Create an operational glossary tied to events, owners, exclusions, and date rules.
Permission is the break: Repair least-privilege access and service identities without creating uncontrolled copies.
Time is the break: Set latency expectations, preserve timestamps, and make retry and failure states observable.
Workflow is the break: Define the transition, acceptance, action, completion evidence, and exception owner.

The appropriate answer may be to configure an existing tool, repair one handoff, remove a duplicate system, or replace a platform that cannot support a required boundary. A focused business systems review can test the specific record path. When the issue crosses definitions, roles, reporting, and recurring work, it belongs in business systems consulting.

What this diagnosis does not prove

Separate systems do not automatically create harmful silos.
One vendor, database, warehouse, or dashboard does not automatically remove them.
Different totals do not prove that one source is defective; the definitions or dates may differ.
A permission boundary may be an appropriate control, not an obstacle to remove.
A connector can be useful without resolving identity, meaning, workflow, or authority.
The same symptom can require a different repair in a different business.

The six categories are a diagnostic framework, not a universal maturity score. Its purpose is to identify the exact boundary that prevents one real record from supporting one real decision.