Porting the token + webhook + backprop rails into a multi-brand codebase, the Integration enum (salesforce/hubspot) turned out limiting:
- Integrations are often per-tenant — each tenant enables/configures their own (sometimes more than one of a kind). A global enum forces a migration to add one and can't carry per-tenant config.
- The downstream codebase already had a per-tenant
IntegrationSource table, so the brand token, webhook subscription, and originIntegration all FK to it instead. originIntegration became a row id (matched against WebhookSubscription.integrationSourceUuid in the escape hatch) rather than an enum value.
Suggestion: consider modeling integrations as a table (FK) rather than the Integration enum, so Token / WebhookSubscription / originIntegration reference per-tenant integration rows — keeps the rails extensible without enum migrations.
Context: originIntegration / backprop landed in #63. Not urgent — capturing the learning from a downstream port.
Porting the token + webhook + backprop rails into a multi-brand codebase, the
Integrationenum (salesforce/hubspot) turned out limiting:IntegrationSourcetable, so the brand token, webhook subscription, andoriginIntegrationall FK to it instead.originIntegrationbecame a row id (matched againstWebhookSubscription.integrationSourceUuidin the escape hatch) rather than an enum value.Suggestion: consider modeling integrations as a table (FK) rather than the
Integrationenum, soToken/WebhookSubscription/originIntegrationreference per-tenant integration rows — keeps the rails extensible without enum migrations.Context:
originIntegration/ backprop landed in #63. Not urgent — capturing the learning from a downstream port.