Connectors Are Not Integration: What ‘Connected’ Actually Means.

Two products can display a connected badge and still disagree about the customer, the status of the work, the permission to view it, and whether the last update arrived. The badge confirms that a technical path exists. It does not define what travels through that path or whether the business can depend on it.

This is why integration directories are useful for discovery but insufficient for a software decision. The business needs to know whether the connection searches an indexed copy, reads the source live, synchronizes records, or performs actions. Those are different operating arrangements with different failure modes.

Before treating two tools as integrated, write a plain-language contract for the records, identities, permissions, changes, exceptions, and outcomes that must cross the boundary.

Connected can mean at least four different things

A product page may use the same word for several architectures. None is automatically superior. The right choice depends on freshness, security, reliability, cost, and what the next person or system must do.

1. Indexed copy: Information is copied from the source into another search or data store. Search may be faster and more capable, but the copy can lag behind edits, deletions, and permission changes.
2. Live federation: The destination queries the source when information is requested. This can reduce copying and improve freshness, but availability, latency, source limits, and search quality still matter.
3. Record synchronization: Fields move on a schedule or in response to an event. The sync may be one-way or two-way, and it needs rules for conflicts, retries, deletions, and duplicate records.
4. Action connection: One product can call a tool or API in another product to create, update, send, schedule, approve, or trigger something. The action needs a defined identity, permission scope, confirmation, and rollback.

Some integrations combine these patterns. A CRM assistant might search an indexed knowledge library, read a customer record live, synchronize selected attributes overnight, and invoke a workflow to schedule a follow-up. Calling all four capabilities "the integration" conceals the decisions that determine whether it works.

An indexed copy and a live answer make different promises

Google's Gemini Enterprise documentation distinguishes data ingestion from federation. Ingestion copies information into a Gemini Enterprise index and may improve search quality. Federation retrieves information from the source without copying it, but Google notes that search quality may be lower.

The same documentation separates full, incremental, entity, and identity synchronization. An incremental sync captures added or updated entity information, but it does not necessarily synchronize identity data or deletions. Read Google's current connector and data-store documentation.

That creates a practical question most connector lists do not answer: if access is removed at 9:00 a.m. or a document is deleted at noon, when does the connected system stop using it?

A connector cannot reconcile an identity rule that was never defined

One customer may have a CRM contact ID, an email address in the marketing platform, a phone number in scheduling, and an account number in billing. Moving those records does not prove that each system knows they represent the same person or company.

For every connected record, define:

The durable identifier carried across systems
The fields used when that identifier is missing
What happens when more than one possible match exists
How merges, household records, parent companies, and changed contact details are handled
Which system creates the authoritative identifier

Without those rules, a technically successful sync can create duplicate customers, attach activity to the wrong record, or make one customer look like several disconnected opportunities.

Permission and deletion behavior belong in the design

A connector may preserve source access-control lists, map them into the destination, replace them with destination permissions, or make imported information available to everyone who can access the new data store. The behavior depends on the product and connection mode.

Microsoft warns that a Copilot connector configured as visible to everyone can overshare sensitive content. Its documentation also says that changing this connector permission after creation may require deleting and recreating the connection. Google warns that some Cloud Storage import paths do not bring the source permissions with the data, allowing users with sufficient Gemini Enterprise permissions to see the imported information.

Verify these cases before launch:

A user gains access in the source.
A user loses access in the source.
A record or file is deleted.
A customer requests correction or removal.
A shared link changes from public to private.
The service account or employee who created the connection leaves.

"Uses existing permissions" is a useful feature description. It is not evidence that existing permissions are appropriate or that every connector mode preserves them in the same way.

A field mapping is not a status model

A CRM may use New, Working, Qualified, and Closed. Scheduling may use Requested, Confirmed, Completed, and Cancelled. Accounting may use Draft, Sent, Partially Paid, and Paid. A connector can move these values without defining what they mean together.

For each important status, decide:

Which real event causes the status
Which system is allowed to declare it
Which other systems need to know
Whether the update is one-way or two-way
What happens if a later event reverses it
How the original event and time remain auditable

Two-way synchronization deserves particular care. If either product can overwrite the same field, the business needs a conflict rule. "Last update wins" is a rule, but it may not be the right one when an older system writes after a more authoritative event.

The integration is defined by what happens when it fails

The happy path is easy to demonstrate: submit a test record and watch it appear in the second product. A dependable connection also accounts for expired credentials, rate limits, unavailable APIs, invalid fields, changed schemas, duplicates, partial updates, and out-of-order events.

Ask for operational answers:

Where does a failed record go?
Who is notified, and how quickly?
Does the system retry automatically?
Can a retry create a duplicate?
Can the original input and every attempted change be inspected?
Can a partial write be reversed?
How will the business know that the connection has silently stopped?

A connection without visible exceptions turns software failure into a business-process mystery. People compensate with spreadsheets, inbox checks, repeated entry, and manual reconciliation. The connector then exists alongside the workaround it was expected to remove.

Write a diagnostic contract for every important connection

This does not need to begin as a technical specification. One page of precise business language is enough to expose most missing decisions.

Purpose: Which business decision, handoff, or customer action does this connection support?
Source and destination: Where does the information originate, and where must it become available?
Connection pattern: Is the information copied, queried live, synchronized, or used to perform an action?
Identity: Which identifier proves that records concern the same customer, request, project, or payment?
Authority: Which system is allowed to decide each important field and status?
Timing: How current must the destination be, and what delay is acceptable?
Permissions: Whose identity is used, what can it access, and how are changes and removals synchronized?
Failure: How are errors detected, retried, reconciled, escalated, and reversed?
Evidence: Which logs prove what moved, when it moved, what changed, and whether the next step occurred?
Ownership: Who reviews the connection, approves changes, manages cost, and retires it?

Test the contract with real exceptions, not only a clean demonstration record. Use a duplicate customer, a corrected email address, a cancelled appointment, a deleted file, an expired credential, and an update arriving out of order.

A useful connector earns its place

The conclusion is not that integrations are bad or that every connection requires a custom platform. A connector is useful when it removes a real handoff, preserves the required meaning and access, exposes exceptions, and produces a result the business can verify.

After documenting the contract, the appropriate decision may be to:

Keep the current connection and improve monitoring.
Change field, identity, permission, or conflict rules.
Replace batch copying with a live query where freshness matters.
Use a governed copy where source performance or search quality makes federation impractical.
Limit a two-way sync to one authoritative direction.
Remove a connector whose purpose is duplicated or no longer needed.
Replace a tool when a required connection cannot be made dependable at a reasonable cost.

The existing five-connection tool map helps place this deeper contract inside the full customer and work path. A business systems review can identify overlap and fragile connections. For issues spanning records, permissions, reporting, and recurring work, explore business systems consulting.

What a connected badge does not prove

It does not prove that every required field moves.
It does not prove that records are matched to the correct customer.
It does not prove that source permissions, changes, and deletions are preserved.
It does not prove that two-way updates have a safe conflict rule.
It does not prove that a successful technical transfer produced the intended business outcome.
It does not prove that the software vendor intended to create lock-in or fragmentation.

The product examples in this article document current connector modes, access behavior, and stated limitations. They are not evidence that every connector from a vendor behaves identically or that one architecture is correct for every company. Features can also change after the July 21, 2026 review date.

The useful standard is observable rather than promotional: the right information reaches the right place, under the right identity and permission, in time for the next decision, while failures remain visible and recoverable.