Organization record lifecycle
Purpose
This lifecycle explains the availability of an organization without discarding its organizational context. A chapter can close while past representatives and hierarchy still need its name. Staff can mark business status or archive the record for different reasons, and hard deletion must account for references that still depend on it.
Our reading is that the organization’s continuity matters independently of its current representatives. Archive retains an identity people can understand in dated views, while deletion removes owned live data. Role compliance is a separate assessment lifecycle; an inactive or archived organization is not automatically a compliant organization.
Ownership and Authority
Creators establish an organization and its initial information. An API editor changes business status through a versioned save. Archive operators use dedicated actions, and deletion requires the delete grant plus dependency and protection checks. The built Organization 360 offers selected actions but does not provide a general editor for every service operation.
Compliance workers may change stored assessment and version without requesting a business-status transition. No inference operation recommends or executes organization lifecycle actions here. A parent relationship describes structure rather than authority; access continues to come from Platform security and the CRM operation grants.
The Lifecycle
States
new
No organization is stored under the requested identity. Entry requires this condition: There is no live organization at this identity. Available behavior is Submit a valid create request.. The create form is still a draft with no saved organization number.
active
The organization has its normal active status. Entry requires this condition: A create defaults to active or an authorized save records it. Available behavior is Read; update under ordinary guards; archive; delete if dependencies permit.. The body can appear in ordinary discovery.
inactive
The stored organization is inactive but retains hierarchy, affiliations and revisions. Entry requires this condition: A versioned save records inactive business status. Available behavior is Read; edit if otherwise available; restore active status; archive.. The identity and its hierarchy remain readable.
duplicate
Duplicate status identifies a record awaiting data-quality treatment. Entry requires this condition: A save records duplicate status. Available behavior is Read; correct under ordinary guards; use separately authorized Data Quality work.. The body remains a live CRM identity pending further treatment.
archived
Archive independently preserves status and relationships while blocking ordinary organization editing and default selection. Entry requires this condition: The archive action records the overlay without changing stored status. Available behavior is Direct read; unarchive; inspect authorized history; request guarded deletion.. Badges identify retained closed context, including archived ancestors or affiliation labels.
deleted
The live organization and owned data are removed, with history and its spent number retained. Entry requires this condition: The guarded delete transaction succeeds. Available behavior is Inspect retained revisions under history authority.. The live organization is absent; ordinary restore is unavailable. This row’s lifecycle ends here; a new request or new record is separate work.
Transitions Explained
new → active
An authorized creator or integration starts this change when the following occurs: Create an organization using active or default status. The transition checks this boundary: Create permission, valid name and workspace references; a blocked duplicate requires authorized override and reason. The accompanying work is allocate organization number; attach logo; evaluate initial compliance without a notice; publish attention only when enabled; capture event and revision. A changed organization transaction produces its aggregate revision and event. Archive metadata records the actor and optional explanation; ordinary deletion retains its historical record.
active → inactive
An authorized API editor starts this change when the following occurs: Save inactive status. The transition checks this boundary: Organization update permission and matching version; no archive or full lock. The accompanying work is persist the new status. A changed organization transaction produces its aggregate revision and event. Archive metadata records the actor and optional explanation; ordinary deletion retains its historical record.
inactive → active
An authorized API editor starts this change when the following occurs: Save active status. The transition checks this boundary: Pass ordinary organization save authorization and concurrency checks. The accompanying work is persist active status. A changed organization transaction produces its aggregate revision and event. Archive metadata records the actor and optional explanation; ordinary deletion retains its historical record.
active → duplicate
An authorized editor or data-quality process starts this change when the following occurs: Mark the organization duplicate in a save. The transition checks this boundary: Use the same guards as other status edits. The accompanying work is persist duplicate status. A changed organization transaction produces its aggregate revision and event. Archive metadata records the actor and optional explanation; ordinary deletion retains its historical record.
active → archived
An authorized archive operator starts this change when the following occurs: Archive the organization in its current status. The transition checks this boundary: Archive permission, matching version and no full lock; optional reason is at most 500 characters. The accompanying work is store archive metadata; advance version and capture revision; preserve affiliations with archive information; exclude default selection. A changed organization transaction produces its aggregate revision and event. Archive metadata records the actor and optional explanation; ordinary deletion retains its historical record.
archived → active
An authorized archive operator starts this change when the following occurs: Unarchive without changing the underlying status. The transition checks this boundary: Archive permission, current version and no full lock. The accompanying work is clear archive stamps; keep unarchive reason; advance version and capture revision. A changed organization transaction produces its aggregate revision and event. Archive metadata records the actor and optional explanation; ordinary deletion retains its historical record.
active → deleted
An authorized delete operator or bulk job starts this change when the following occurs: Delete the organization directly or through a bulk job. The transition checks this boundary: Delete permission, no deletion-blocking owner or element lock, no protection, no child organizations and no affiliation references. The accompanying work is remove contact points and custom values; resolve enabled attention; detach logo; apply enabled owner-deletion policy; capture deletion history. A changed organization transaction produces its aggregate revision and event. Archive metadata records the actor and optional explanation; ordinary deletion retains its historical record.
archived → deleted
An authorized delete operator starts this change when the following occurs: Delete while the organization is archived. The transition checks this boundary: Archive does not relax the normal delete checks. The accompanying work is perform ordinary organization deletion. A changed organization transaction produces its aggregate revision and event. Archive metadata records the actor and optional explanation; ordinary deletion retains its historical record.
What Cannot Happen
The service returns a dependency refusal when children or any affiliation reference the organization. Past and future ties still preserve their organization context.
Archive refuses general correction with the archived-record response. An authorized unarchive action is the supported way to reopen ordinary editing.
No deleted-to-active restore exists. Live reads return not-found; a fresh create is a different creation with another allocated number.
Permissions by State
The state rows reference grants from the CRM authorization model. Read access is distinct from mutation, and history requires the corresponding history and read checks. Administrator and Power User hold administrative record actions; ordinary Standard User grants include applicable read and update operations, while Read Only grants do not authorize edits.
Archived records remain directly readable, but ordinary update is blocked. Archive authority permits restoration subject to the dedicated guards. Deleted records have only retained history rather than another ordinary update state.
Concurrency and Timing
Version checks and the organization row lock order simultaneous saves. Compliance uses that lock and an advisory lock and can advance the organization version, so an administrator’s type change can conflict with system work. The hierarchy constraint refuses a competing move that would form a cycle.
Hard deletion has no read-version input. Creation does not have the contact service’s fingerprint replay behavior: a repeated supplied identity conflicts, and an unkeyed retry can create another organization. Initial compliance evaluation occurs during creation, while later type edits require another trigger or reprocess to refresh assessments.
Invariants
Our reading is that preserving organizational identity and hierarchy through ordinary corrections prevents a parent move from changing who a person worked for. Archive overlays availability without rewriting business status. Deletion must account for people’s ties of every date and for children, because those references remain meaningful even when a record is inactive or archived. Current-version and lock checks apply to the action actually performed; read visibility alone never supplies authority to reopen or remove an organization.