Where reuse ends and business meaning begins

Two customers both have a field called “active.” For one, it means the customer bought something in the past year. For another, it means a service agreement is current. A shared connector can move both fields correctly. A shared rule that treats them as the same business state can be wrong for one of them. This is an illustrative example, not a report from a deployment.

A discussion of shared platforms and local deployment describes a company reusing much of its infrastructure while still doing substantial work inside each customer environment. Its percentages are company-specific. The general architectural question is where shared mechanics stop and local meaning begins.

Separate the transport contract from the business contract

A transport contract can state: authenticate to the source, read changed records, preserve identifiers, retry safely and expose failures. Those behaviors can be implemented once and tested repeatedly. They are valuable because every integration needs a trustworthy route for data.

A business contract says which record is authoritative, what a status means, when an action is allowed and who can correct a mistake.

1. Shared transport identity · retry · event ID

   delivers a valid event

   hands off
2. Local policy meaning · consent · timing

   decides whether action is allowed

   hands off
3. Authorized action write · audit

   records the outcome

That business contract depends on the workflow. It might use the same source and destination as another customer yet require a different answer.

Consider a store-to-email connection. The platform can provide event ingestion, deduplication and an audit trail. The workflow owner must define whether “subscribed” means permission for a particular marketing purpose, whether a purchase suppresses a cart reminder, and how a consent change affects messages already queued. These are not connector features that can be guessed from field names.

The illustrated Tajo map below copies three fields directly. Notice the missing decision: none of those rows defines marketing permission. Reusing transport saves work, but the workflow owner still has to specify which status permits which action. A neat field map can expose that gap without resolving it.

TajoConcept illustration · Example data

Review a sync before it runs

Sync customer updates to my email platform.

Tajo MCP appDraft

Customer sync

StoreEmail platform

Field mapping

Source field	Destination field	Rule
email	EMAIL	Direct
first_name	FIRSTNAME	Direct
last_name	LASTNAME	Direct

Synthetic preview passed

3 fields mapped · No destination writes

Activation requires approval.

Preview mappingCreate draft

Illustrative layout based on Tajo's mapping tools. A synthetic preview and a saved draft do not activate a sync.

Shared layer	Local layer
Authentication and token refresh	Which principal may access this workflow
Event transport and retries	Which event counts as the business transition
Stable identifiers and deduplication	Which records refer to the same real customer
Logging and recovery hooks	Who resolves a disputed state and how
Contract validation	What the field values mean and when they may drive action

The table is a design boundary, not a claim that all implementations can be partitioned this neatly.

Reuse breaks when it hides disagreement

A generic platform often grows a configuration field for every exception. At first, this seems to preserve reuse. Later, nobody can tell whether a setting is a technical option, a legal constraint or a business decision. The shared core becomes a remote control for choices it does not own.

Look for a stable invariant. “Never apply the same source event twice to the same destination record” can live in a shared engine. “Send a discount when a customer becomes active” cannot be shared until “active,” the allowed audience and the offer policy have owners. The engine can execute an approved policy, but it should not invent one.

This also helps maintenance. If an API changes, the platform team can update the adapter and its tests. If the definition of an eligible customer changes, the business owner can update the policy and test examples without waiting for a transport rewrite. A clean boundary lets each change reach the person who has authority over it.

Reuse mechanics without flattening meaning

Some local rules do add cost. A platform with no reusable contract becomes a collection of bespoke scripts. The answer is to identify repeated mechanisms before abstracting repeated meanings. A well-designed shared primitive might accept a typed predicate, event time and action limit while leaving the predicate’s business definition local.

The boundary should be tested with real cases. Take a normal event, a duplicate, a late correction and a revoked permission. Ask which layer is responsible for each response. If a failure cannot be assigned, the abstraction is hiding ownership. If a new customer forces a shared “active” enum to acquire several unrelated interpretations, the shared type is too broad.

The companion deployment article examines whether a capability works inside a live workflow. This one asks what can be built once without erasing what the workflow means.

The interface between layers should be explicit enough to reject a bad assumption. A shared engine can require an event ID, source time, actor and declared purpose before accepting an action request. The local workflow can supply the policy that decides whether that action is allowed. If the purpose is absent, the engine should refuse the request; if the policy is ambiguous, the local owner must resolve it. This is a practical way to preserve reuse without outsourcing business authority to generic code. Document the contract with one accepted example and one rejected example, then test both whenever either layer changes.

A reusable connector should make local meaning easier to express and safer to execute. It should never make two different promises look identical because their fields share a name.