Record lock
Purpose
The lock lifecycle explains customer restrictions on record changes and the separate protection maintained by Rhythm. An association may allow corrections to a record while preventing deletion, or temporarily block both. Staff need to know whether an ordinary grant is enough, an audited unlock is required or the restriction belongs to Rhythm.
The recorded lock decision provides dedicated changes with reasons and an audit. Our reading is that treating protection as an independent overlay prevents customer administration from accidentally releasing configuration that the platform depends on. Ordinary field editability and protection against lock changes are therefore assessed separately.
Ownership and Authority
Customer lock operators use the corresponding lock permission; unlock operators use the separately named unlock permission. The dedicated action checks version, reason and ownership of selected elements. A full lock does not forbid the very administrative action intended to change that lock. Ordinary saves cannot establish a new owner lock on contacts or organizations.
Migrations and operators maintain Rhythm protection, and application access to that registry is read-only. No model recommends or executes a lock transition in this module. The older contact-role save path remains a documented evidence exception to universal dedicated-lock auditing.
The Lifecycle
States
unlocked
Ordinary permissions allow updating and deleting the record. Entry requires this condition: No customer lock value applies to the subject. Available behavior is Ordinary read, update or delete with their grants and other record guards; dedicated lock.. There is no customer lock blocking mutation, but archive and protection can still apply.
delete-locked
Updates remain allowed, but deletion is locked. Entry requires this condition: A dedicated action selects the deletes restriction. Available behavior is Read; ordinary update under other guards; dedicated lock replacement or unlock.. Deletion is refused while ordinary corrections can remain available.
fully locked
Ordinary updates and deletion are both locked. Entry requires this condition: A dedicated action selects updates & deletes. Available behavior is Read; dedicated lock change or unlock; inspect lock history.. Ordinary save and deletion are restricted, including relevant aggregate work.
protected
An independent Rhythm protection entry prevents customer lock changes and deletion, while ordinary field editing remains allowed. Entry requires this condition: A Rhythm-maintained registry entry names the subject. Available behavior is Read; ordinary fields can remain editable under all other guards.. Customer lock, unlock and delete are refused with the protection explanation.
Transitions Explained
unlocked → delete-locked
An authorized lock operator starts this change when the following occurs: Apply a delete lock using the dedicated action. The transition checks this boundary: Lock permission, matching version, nonblank reason within 1,000 characters and no Rhythm protection. The accompanying work is advance version and modification stamps; append owner lock audit; capture contact or organization history and event. A changed dedicated lock action stores reason, actor, time and before-and-after locks, including released elements. Contact and organization changes also enter aggregate revision history; requesting an unchanged restriction with no released elements records no change.
unlocked → fully locked
An authorized lock operator starts this change when the following occurs: Apply a full update-and-delete lock. The transition checks this boundary: Dedicated lock checks apply; ordinary saves cannot create a full lock. The accompanying work is persist full lock; advance version and audit the change. A changed dedicated lock action stores reason, actor, time and before-and-after locks, including released elements. Contact and organization changes also enter aggregate revision history; requesting an unchanged restriction with no released elements records no change.
delete-locked → fully locked
An authorized lock operator starts this change when the following occurs: Strengthen a delete lock to a full lock. The transition checks this boundary: Use dedicated lock authorization, version and reason checks. The accompanying work is advance version; append the changed lock audit. A changed dedicated lock action stores reason, actor, time and before-and-after locks, including released elements. Contact and organization changes also enter aggregate revision history; requesting an unchanged restriction with no released elements records no change.
fully locked → unlocked
An authorized unlock operator starts this change when the following occurs: Unlock the owner and selected or all owned elements. The transition checks this boundary: Unlock permission, matching version, required reason, valid owned element references and no Rhythm protection. The accompanying work is advance owner version when any lock changes; audit each released element and the owner lock if changed. A changed dedicated lock action stores reason, actor, time and before-and-after locks, including released elements. Contact and organization changes also enter aggregate revision history; requesting an unchanged restriction with no released elements records no change.
delete-locked → unlocked
An authorized unlock operator starts this change when the following occurs: Release a delete lock using the dedicated action. The transition checks this boundary: Dedicated unlock checks apply. The accompanying work is clear owner lock; advance version and append audit. A changed dedicated lock action stores reason, actor, time and before-and-after locks, including released elements. Contact and organization changes also enter aggregate revision history; requesting an unchanged restriction with no released elements records no change.
fully locked → delete-locked
An authorized lock operator starts this change when the following occurs: Replace a full lock with a delete lock. The transition checks this boundary: Lock action authorization applies; the current full lock does not block its dedicated change. The accompanying work is advance version; audit replacement of the owner lock. A changed dedicated lock action stores reason, actor, time and before-and-after locks, including released elements. Contact and organization changes also enter aggregate revision history; requesting an unchanged restriction with no released elements records no change.
What Cannot Happen
Customer unlock cannot remove Rhythm protection. The service returns an illegal-operation refusal describing the protected system record, regardless of customer grants.
An ordinary customer write cannot create a protection entry. The application has read-only access to that registry; only the operator or migration boundary can maintain it.
Permissions by State
The CRM model separates lock, unlock and read grants for contacts, organizations and contact roles. Administrator and Power User hold lock and unlock authority; Standard User and Read Only can inspect records but do not receive those administrative grants. Protection refuses customer lock changes regardless of the grant.
A customer full lock restricts ordinary mutation, while dedicated administrative changes remain available under their own permissions. A deletion-only lock leaves ordinary editing possible. Element locks and archive still add checks, so the absence of an owner restriction does not establish that every operation is allowed.
Concurrency and Timing
The dedicated action locks its subject and compares the supplied read version before changing restrictions. A stale action receives a version conflict instead of overwriting a newer lock. Reasons and element references are validated before the successful change is committed with its audit.
A request for the current owner lock can still change the aggregate if it releases selected element locks. Full locks can delay scheduled affiliation work, and a later unlock does not establish a deadline for backlog recovery. Rhythm protection remains an independent check; the current seed contains no protected CRM records.
Invariants
Our reading is that separating customer locks from Rhythm protection preserves the intended administrator boundary. Unlock authority can release a customer restriction, but cannot release platform protection. A required reason and committed before-and-after audit make actual lock changes explainable. Owner and nested-element restrictions can differ, so releasing an owner lock alone need not make every detail editable. The contact-role ordinary-save exception remains explicit rather than falsely extending dedicated-action audit guarantees to all role edits.