---
id: ADR-CRM-ENT-006
title: Compensate Platform-held Templates After CRM Commit
product_area: crm
module: entities
revision: 1
status: proposed
design_intent: proposed
source_sha:
  services-crm: 7ea48a414c42eade10d60753b8bcc323b1dd726f
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
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.
constrains:
  - WF-CRM-ENT-008
  - SVC-CRM-ENT-configuration-types
  - DOM-CRM-ENT-002
origin: >-
  the composed-property contract of 2026-10-09, cited in
  services-crm:modules/entities/services/templates/compliance-notification-template.ts;
  FND-CRM-ENT-024; FND-CRM-ENT-025
alternatives:
  - option: Use one distributed transaction for type and template.
    why_not: >-
      The services do not share such a transaction. The bounded communication
      request-object exception does not create a general template-write
      exception.
  - option: Persist the template before the type.
    why_not: >-
      A later rejected type save would leave a template associated with
      nonexistent or outdated owner data.
  - option: Queue template mutation with an outbox entry.
    why_not: >-
      That would make acceptance asynchronous and require a new editor feedback
      and reconciliation contract; the current workflow does not implement it.
consequences:
  - 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.
evidence:
  - >-
    services-crm at 7ea48a41:
    modules/entities/services/persistence/organization-types.ts;
    modules/entities/services/templates/compliance-notification-template.ts
---
# 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.