Compensate Platform-held Templates After CRM Commit

Context

Type policy and notice content appear in one editor but belong to different persistence services. The workflow validates template content first, then performs the CRM and Platform writes sequentially.

Decision

Organization types commit in CRM before their owned templates are changed in Platform; template-write failure triggers a compensating CRM delete or restore; template cleanup after type deletion is logged if it fails.

Alternatives Considered

Use one distributed transaction for type and template. The services do not share such a transaction. The bounded communication request-object exception does not create a general template-write exception.

Persist the template before the type. A later rejected type save would leave a template associated with nonexistent or outdated owner data.

Queue template mutation with an outbox entry. That would make acceptance asynchronous and require a new editor feedback and reconciliation contract; the current workflow does not implement it.

Consequences

Compensation is another write rather than transaction reversal. Callers must reread after template or compensation failure. The existing findings record failed restoration and orphan-template risks; adopting another architecture requires a product decision.

A restored type gets another version but no record-history revision. Concurrent writes, locks or dependencies can prevent compensation and leave type and template out of step. Failed cleanup can leave content that a later type reusing the identity associates with again.