Skip to content

0002. Introduce a Tenant entity and dissolve App

Date: 2026-07-10 Status: Accepted

Context

Every externally connected system (a shop like WooCommerce, or a SaaS product like User Platform or rapidmail itself) is, from Conflux's point of view, an interchangeable adapter — a System with a SystemDriver and a plugin. But the real company on the other end of several adapters (e.g. "Acme GmbH" with both a WooCommerce shop and a User Platform account) has no seat in today's model. App (rapidmail, User Platform) is neither that company nor an adapter — it is a third, ill-fitting category that conflates an internal product boundary with a data-ownership scope.

Decision

  • A new Tenant entity is introduced — not a renamed App. Only a dedicated entity can represent "the same customer across several systems"; App grouped by internal rapidmail product, not by a real customer.
  • App is dissolved entirely into the adapter model. rapidmail and User Platform become ordinary System/adapter catalog entries, exactly like WooCommerce. There is no reason for a separate tenant layer once Tenant owns that role — the internal products are just adapters that happen to be pulled from.

Consequences

SystemConnection moves from belongsTo App to belongsTo Tenant (app_id → tenant_id, unique key becomes ['tenant_id','system_id','external_user_id']). The apps table, the App model, and the app_user pivot are retired once this ships.

Dissolving App also removes its role as the Sanctum principal that pull-out consumers authenticate as — how rapidmail/User Platform authenticate once App is gone is addressed by ADR-0006, not by this decision.