An order is not just an order. It has a customer, a plan, a product, a billing state, a region, a sales owner, a risk flag, and a lifecycle. In a modern product, those facts often live in different services because that is the right architecture for the application.
But reporting, operations, finance, and customer teams do not ask questions in service boundaries. They ask for records.
The category problem
Most data movement tools are organized around connectors: source A to destination B. That is necessary, but it leaves a gap. The team often does not only need "move table X." They need "make this operational fact understandable when it arrives."
That is why operational enrichment should be treated as its own use case. It is not a connector. It is not a warehouse model. It is the step where the pipeline declares what a useful row means.
Can we move rows from this system to that system?
Can we make the row arrive with the identity, commercial, catalog, lifecycle, and reference context the destination actually needs?
The context teams keep rebuilding
Enrichment is not one trick. In real systems, the missing context usually falls into a few repeatable categories.
customer_id, account_id, or user_id into names, segments, owners, regions, and tenant metadata.What changes when enrichment is a workflow
If enrichment lives only in downstream SQL, it is easy to hide. If it lives only in custom code, it is easy to lose. As a product workflow, it becomes inspectable.
Three examples that are not the same pipeline
The value is easier to see when the rows are different. JoinLayer should not only tell the order/customer story.
| Workflow | Raw row has | Useful row adds | Why it matters |
|---|---|---|---|
| Subscription reporting | account_id, plan_id, renewal date. | Plan name, billing cadence, contract tier, account segment. | Finance and CS can read the row without joining billing and account systems again. |
| Marketplace operations | seller_id, SKU, fulfillment code. | Seller name, category, region, SLA tier, fulfillment label. | Ops teams can sort exceptions by business context, not internal IDs. |
| Product usage exports | user_id, feature key, event count. | Workspace name, plan, feature label, lifecycle stage. | Usage data becomes usable for product and revenue workflows before BI modeling starts. |
The product idea
JoinLayer makes this feel like configuring a pipeline, not inventing an integration project. Choose the source row. Define the target row. Attach lookup context. Decide miss behavior. Preview. Validate. Run. Diagnose.
PostgreSQL, MySQL/MariaDB, Kafka, ClickHouse, and BigQuery provide the current connector edges. The durable product idea is that each supported route uses the same visible middle layer: mapping, enrichment, preview, validation, and safe delivery.
When teams keep asking for "the customer name," "the plan," "the segment," "the status label," or "the product category," they are asking for enrichment. JoinLayer's job is to make that work explicit before the data lands.