Configuration in the database, not in the code

Let us state a falsifiable thesis up front: in an integration, only the connectors deserve code. Field correspondences — which source field feeds which target field, through which transformation — are business data. They belong in a database, not in a source file. If renaming a field or plugging in a new source requires a deployment, data has leaked into the code.

The arithmetic already points that way. Connecting n applications pairwise requires up to n(n−1) data translators; introducing a canonical data model brings that number down to 2n. For six applications, that is 30 versus 12 — the example comes straight from the reference book Enterprise Integration Patterns (Canonical Data Model pattern).

The canonical model fixes the combinatorics; the code/data separation fixes the upkeep. A connector is written once per API grammar, then stabilizes. Correspondences never stop evolving: new fields, new values, new sources. Context makes the bill worse: the average company deploys 101 applications, according to the Businesses at Work 2025 study, commissioned and published by Okta. Nobody will ever maintain the point-to-point tangle of a portfolio that size.

The classic objection comes from the twelve-factor manifesto: "strict separation of config from code," hence environment variables. But twelve-factor is about deployment configuration — credentials, service URLs, resources — that is, whatever is likely to vary between deploys. A field mapping does not vary between deploys: it varies with the business.

The Google SRE Workbook frames the question at the right level:

"Configuration is a human-computer interface for modifying system behavior." — The Site Reliability Workbook, ch. 14

The same chapter holds that having both code and data — but separating the two — is optimal, and recommends phrasing configuration options in terms of business goals rather than implementation details. That is precisely what a mapping table does: it asks questions for people who know the data — does source A's work email feed the referential's email field? — never questions about code (endpoints, pagination, authentication). This is what makes configuration-driven integration extensible by non-developers: what they edit is narrow, declarative, and readable.

We run this pattern in production to consolidate heterogeneous systems. A sync engine written in Python, orchestrated on Trigger.dev, reads its configuration from an Airtable base and connects six CRM and ERP systems to a single source of truth — including a SaaS CRM with custom properties (HubSpot), an ERP whose API implements OData 4.0, an OASIS standard (Dynamics 365), and a legacy line-of-business application that exposes a SOAP/XML API. Three API grammars; one table of correspondences. Syncing multiple CRMs then comes down to adding mapping rows, not code. On the team side: zero manual re-entry.

Each row of the table is a Message Translator — the other founding pattern from Hohpe & Woolf — declared as data instead of coded:

{
  "source_system": "crm_a",
  "source_field": "work_email",
  "transformation": "lowercase, strip whitespace",
  "target_entity": "person",
  "target_field": "email",
  "merge_key": "email",
  "direction": "source to referential",
  "active": true
}

In ETL terms — extract, transform, load into a unified store, per Microsoft's definition — the connectors extract, the table declares the transformations, the engine loads the referential. The orchestrator brings what a scheduled script does not: queues, automatic retries, real-time monitoring (Trigger.dev describes itself as an open source background jobs framework). We documented the criteria that justify this level of tooling in when to industrialize an automation.

One honest design detail: the Airtable Web API enforces a documented limit of 5 requests per second per base. So the configuration is read at the start of a run and cached — never per record. A configuration layer is read rarely and edited often: exactly the usage profile of a database.

Storing business rules in tables may sound improvised. It is the opposite. DMN (Decision Model and Notation), a standard published by the Object Management Group, exists precisely to specify business decisions "in unambiguous decision tables," readable by business users. On the research side, Rahm & Bernstein established back in 2001 that schema matching is a fundamental problem of data integration, "typically performed manually." The mapping table does not eliminate that work: it makes it explicit, versionable, and reviewable, instead of scattering it across code.

The difference from a generic rules engine lies in scope:

• no implicit chaining between rules;
• no full expression language;
• a flat mapping — source, transformation, target — executed by an observable orchestrator.

Users map; they do not program. That narrow scope is what keeps the "extensible by non-developers" promise, where overly broad scopes tend to break it.

It is also how older systems become first-class sources again: SOAP 1.2 is a W3C Recommendation from 2003, still spoken by applications in production. The connector absorbs the grammar; the table only sees fields. Same move as modernizing a legacy ERP without replacing it: you wrap the existing system, you do not rewrite it.

The cost of doing nothing — Every point-to-point integration added today is combinatorial debt: at six systems, the full tangle represents up to 30 translators to maintain, and the seventh can add 12 at once (Hohpe & Woolf). Meanwhile, the average portfolio reaches 101 applications (Okta, 2025). And every hard-coded correspondence mobilizes a developer, a deployment, and a regression test — sometimes just to rename a single field.

Here is the anonymized structure of our mapping table — the one driving the mapping-driven sync of our six sources into the referential. It fits in nine fields.

Three everyday operations become table edits: plugging in a source (add rows), fixing a correspondence (edit a row), suspending a suspicious flow (deactivate a row). Routine changes move from code review to table review. This clean separation between a stable engine and living configuration is a constant principle of how we build.

Connectors remain code: a new API grammar (SOAP, OData, proprietary REST) still takes developer work. A flat table cannot express everything: rich conditional logic, fuzzy deduplication, and multi-step orchestration live in the engine, not in the configuration. The configuration itself becomes a production asset: without change history, controlled edit rights, and a test dataset, you relocate the risk instead of reducing it. Finally, the pattern has an entry cost: below two or three stable systems, a direct script often remains the right choice — which is exactly what our industrialization criteria help decide.