How EspoCRM record locking keeps approved records unchanged
Sales and service leaders need approved quotes, contracts and cases to stay fixed once they are signed off. EspoCRM 10 record locking answers that need by freezing records per entity type, so a locked quote or case cannot be changed by the people who normally edit it. Enable the Lockable parameter for each entity type you want to protect. Use locking when the rule is that a record must not change after a defined event, such as customer acceptance or contract signature. Use status-based permissions when edits should be restricted by stage but an authorized person may still correct the record in the normal course of work, for example while a deal is still in negotiation.
According to the EspoCRM record locking documentation, a locked record cannot be edited, except in the fields you designate, and it cannot be removed. Only users who hold the Lock permission can lock or unlock a record. That makes the Lock permission the control point of the design: decide which roles hold it, confirm whether they are the same people who approve records, and check that an unlock is traceable to a named person. The documentation describes this behavior for v10.0, so confirm the exact behavior in your target version before you finalize the design.
Before rollout, list the fields that must stay editable after locking, such as a internal status or a follow-up date, and test each one against a locked test record. Also test how a locked record behaves in mass actions, workflows and API updates, since a rule that blocks the user interface may not block every path into the record. The EspoCRM record locking documentation is the reference to check these behaviors against your own roles and entity types.
How to enable Lockable and the Lock permission in EspoCRM
This sequence turns record locking on for the entity types that hold approved quotes, contracts or cases, limits who can lock and unlock, defines which fields stay editable, and proves the behavior with a non-admin user in a test instance before production. The result is a tested lock setup your approvers can rely on.
Confirm your EspoCRM version and lock scope
Record locking is part of EspoCRM 10.0 and later, and it is enabled per entity type with the Lockable parameter. Before changing anything, confirm the instance runs a 10.x release and list the entity types that hold approved records, such as Quote, Contract or Case. Ask your EspoCRM administrator to check the running version under the administration area. Done when you have a written list of entity types in scope and the version is confirmed in a test instance, not just in your notes.
Enable Lockable on each entity type
In the Entity Manager, an administrator opens each entity type in scope and enables the Lockable parameter, then saves. Enable it only on the types you listed, because the setting changes how those records behave for every user with edit access. Check that the entity type shows Lockable as enabled after saving, and reload the record list to confirm the change took effect in the interface.
Grant the Lock permission to a narrow role
Create or adjust a role that carries the Lock permission, and assign it only to the people who own the approval step, such as a sales manager or contracts lead. Users without this permission cannot lock or unlock records, so keep it off general sales and service roles. Verify by logging in as a user who holds the role and confirming a lock control is visible on a record, then logging in as a user without it and confirming the control is absent.
Define the fields that stay editable
Decide which fields must remain writable after approval, such as a status field, a internal note or a next-action date, and configure them as editable in the locked state. Everything else on the record stays frozen. Document this list with the business owner, since a field missed here will block legitimate work, and a field included by mistake weakens the lock. Done when the list is signed off and each field is checked on a locked test record.
Test lock and unlock with a non-admin user
Create a test record of each in-scope type, then log in as a non-admin user with the Lock permission and lock it. Attempt to edit a frozen field, confirm it is blocked, and then edit one of the designated editable fields and confirm it saves. Unlock the record and confirm the full form is editable again. Repeat with a user who lacks the Lock permission and confirm they cannot lock or unlock. Record the results with screenshots for your change log.
Confirm mass lock behavior in a test instance
Select several test records in a list view and apply the mass lock action, then check that every selected record shows as locked and that unselected records are untouched. Next, attempt a mass unlock with a mixed selection and confirm the outcome matches the permission model. Also check that mass actions on locked records do not bypass the designated editable fields. Only repeat these steps in production after every result matches the test expectations, and ask your EspoCRM partner or administrator to confirm any behavior that differs from the official record locking documentation.
Roll out to production and keep the test evidence
Apply the same Lockable settings, role assignments and field list to production, then repeat a short lock and unlock check with a non-admin user on one live record. Keep the test evidence, the role list and the editable field list together in your configuration records so changes can be reviewed later. Done when production shows the same behavior as the test instance and the evidence is stored where your compliance or operations team can find it.
Lock configuration options and when each fits
This table compares the main ways to configure record locking for quotes, contracts and cases, with the situations each suits and the flexibility it costs. Read each row as a design choice you can combine with the others, and confirm the exact behavior of each setting in your EspoCRM 10 instance before rollout.
| Option | When it fits | What it costs in flexibility |
|---|---|---|
| Lockable on for quotes only | Approved pricing must not change after sign-off, while other entity types stay freely editable. | Any edit to an approved quote requires an unlock step, so sales staff may need a route to request changes. |
| Lockable on for contracts and cases | Signed terms or closed case records need a fixed audit state, and other records stay in normal use. | Support teams may lose the ability to correct typos or update status on locked cases unless designated fields remain open. |
| Lock permission granted by role | A named group, such as contract administrators, is the only group allowed to lock or unlock records. | Account managers who approve a deal cannot lock it themselves, which adds a hand-off and can slow closing. |
| Designated editable fields | Notes, attachments or follow-up fields must keep changing after a record is locked. | Each editable field is a gap in the lock, so every extra field needs a review of what it can change. |
| Mass lock actions | Month-end or batch approval of many quotes or contracts at once keeps the process consistent. | Mass actions are harder to reverse selectively, so a wrong selection can lock records users still need to change. |
| Unlock limited to privileged roles | Changes after approval require a documented decision, which suits regulated contract and billing records. | Every correction waits for a privileged user, so you need a named owner and a service level agreed internally. |
| Unlock available to record owners | Low-risk entities where small corrections are common and the owner is accountable for the content. | Owners can reopen approved records without oversight, which weakens the audit trail for sign-off decisions. |
Where record locking fits alongside approvals and status fields
Record locking is a control on the record, not an approval engine. Lockable decides whether a record can be edited once it reaches a certain state, and the Lock permission decides who can apply or remove that state. It does not decide who must approve a quote, contract or case, route the request to an approver, or record the decision. Those steps belong to a process layer. In EspoCRM, the Advanced Pack provides Workflows and Business Process Management, and a workflow or BPMN process can run an approval step and then trigger the lock action once approval is recorded. Teams that expect locking to produce an audit trail of approvals should confirm with their own design that the approval decision is captured in a field, a status or a process log before the lock fires. The Advanced Pack is included in all EspoCRM Cloud plans, according to the EspoCRM pricing page. Self-hosted deployments need to confirm which official extensions they license and install.
The main trade-off is between a hard lock and status-driven editing. A hard lock is simple to explain and hard to bypass: a locked quote cannot be changed except in the fields you designate, so sales staff cannot quietly alter pricing after approval. The cost is friction. Every legitimate correction, such as a typo in a billing contact or a revised close date, needs an unlock by a user with the Lock permission, so the team must decide who holds that permission and how requests are handled. Status-driven editing, where a status field such as Approved or Signed controls which layouts or dynamic logic apply, gives more flexibility but depends on consistent use of the status values. If users can move a record back to Draft, the status alone does not protect the content. Before choosing, list which records need true immutability and which only need a visible checkpoint.
Security risks in record locking and how to limit them
Record locking only protects approved quotes, contracts or cases if the people who can lock, unlock and write to those records are limited deliberately. The cards below cover where control tends to slip, from the Lock permission itself to admin bypass, audit gaps and integration writes, and the checks to run before go-live.
Scope the Lock permission
The Lock permission decides who can freeze and release a record, so it is the first control to review. Grant it through a role tied to a defined function, such as contract administration, rather than to general sales roles. Before go-live, list every role holding Lock and confirm each holder can name the approval that authorizes a lock. Ask your implementation partner to show the role matrix for each Lockable entity type.
Control unlock decisions
Unlocking an approved quote or contract reopens it for edits, so unlock is the higher-risk action and should be narrower than lock. Decide whether unlock sits with the same role or a second, smaller group, and whether a unlock requires a documented reason outside EspoCRM, such as a change ticket. Test the flow with a non-admin user to confirm the permission split works as your approval process expects.
Limit admin bypass
Administrators can change roles, entity settings and layouts, which means an admin can often change the rules that govern locks. Keep admin accounts separate from daily work, as the EspoCRM security guidance recommends, and use a named admin account for lock configuration only. Restrict admin logins by IP address and require two-factor authentication, noting that EspoCRM's own 2FA is not compatible with OIDC sign-in, so confirm your identity provider's MFA covers admins instead.
Close audit trail gaps
Your review of who locked or unlocked a record depends on the audit history EspoCRM retains for those actions. Before relying on it, test a lock and an unlock on a sample record and confirm the actor, timestamp and change are visible to the people who review them. Ask your partner which log or stream captures lock events, how long it is kept and whether it can be exported to your SIEM. Do not assume a field-level history covers the lock state itself until you have tested it.
Handle API and import writes
Locked records can still meet writes from outside the UI. API users, CSV imports and workflows may attempt to update a locked record, so their behavior must be tested rather than assumed. Decide which integration accounts should be allowed to write to locked records, and whether a failed write should alert the owning team. Confirm the import mode you plan to use, such as Update Only, will not silently skip locked rows, and check how API errors are returned to your integration.
Restrict API user permissions
API users authenticate with API keys or HMAC and carry role-based permissions, so an API user with broad edit rights can change records that a human user cannot. Give integration accounts a dedicated role that excludes the Lock permission and limits edits on Lockable entity types. The EspoCRM API docs describe HMAC as the most secure method and basic authentication as not recommended, so choose HMAC for any integration that writes to approved records.
Questions teams ask before enabling record locking
How much effort does enabling record locking in EspoCRM take?
The effort depends on how many entity types you lock, how many roles need the Lock permission, and how many layouts must keep specific fields editable after approval. Enabling the Lockable parameter on one entity type is a small configuration change, but the surrounding work is where time goes: agreeing which statuses trigger a lock, deciding which fields stay open (for example, a closing note or an internal comment), and checking that roles and layouts behave as intended. Ask any partner to break the effort into configuration, role design, layout changes, testing and handover, and to state which items are one-time and which need ongoing review as the sales process changes.
Can our internal admin enable record locking without a partner?
Yes, if your administrator is comfortable with the Entity Manager, roles and layouts in EspoCRM 10. The Lockable setting and the Lock permission are administrative configuration, not custom code. The risk is less about the setting itself and more about gaps: a role that can still edit through another path, a layout that exposes a field you meant to freeze, or a mass action run on the wrong set of records. An internal admin should test with a non-admin user account in a staging copy before changing production, and document who holds the Lock permission and why.
What does a partner add to role design and testing for locking?
A partner usually adds a structured review of who should lock and unlock records, which fields must remain editable on a locked record, and how those rules map to your teams. The testing step matters most: each role should be exercised against approved, draft and edge-case records, including attempts to edit, delete and mass-update. Ask for a written test matrix, the roles covered, the environment used and the evidence returned, so your team can repeat the checks after upgrades or new roles are added.
How does record locking interact with approval processes?
Record locking controls editing; it does not decide whether a record is approved. Your approval step, whether it is a manual status change, a workflow, or a process built with the Advanced Pack's Workflows and BPMN 2.0 engine, should set the state that triggers the lock. Confirm the order of events: the approval must complete before the lock applies, and an unlock must be limited to a named role with a recorded reason. Check that workflows running after approval can still write to the fields you intend to keep editable, such as a signature date or a fulfilment status.
Does locking help with audit or compliance evidence?
Locking supports a control objective, that approved commercial records cannot change without authorization, but it does not produce an audit report on its own. Auditors and certification bodies assess the design and operation of your controls. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications. Ask your auditor which evidence they expect, such as role exports, configuration screenshots, test results and change records, and agree that format before the build starts.
What should we ask for in a written scope for locking?
Ask the partner to list the entity types in scope, the statuses that trigger a lock, the roles that get the Lock permission, the fields that remain editable, and the mass actions your users will use. The scope should also name the environments, the test cases, the handover documents and any upgrade or retesting after future EspoCRM releases. Most engagements are fixed-scope, so a clear written scope is what makes a quote comparable. Ask for each item to be listed as a deliverable with an acceptance check.
What recurring work follows after locking goes live?
Locking needs periodic review rather than a one-off setup. New roles, new layouts, new entity types and EspoCRM upgrades can all change what a locked record allows. Plan for a regular access review of the Lock permission holders, a retest after major changes, and a check of the editable-field list whenever the sales or service process changes. Ask whether ongoing review is included in the quote or offered as a separate retainer.
What a record locking engagement includes
A written proposal for record locking should start with an entity inventory: every entity type that holds approved quotes, contracts or cases, with its current layouts, workflows and any formula or before-save scripts that write to those records. Record locking is enabled per entity type through the Lockable parameter, so the proposal must state which entity types get it and which stay open. The same inventory should list the fields that must stay editable on locked records, such as a status field, a closing note or an internal comment, and the reason for each. Those field decisions are the part most often left vague, so ask the partner to show them in a table before build starts.
The proposal should also cover role and permission design. Only users with the Lock permission can lock or unlock a record, so the team needs to decide which roles hold it, whether a manager or an operations group performs unlocks, and how that maps to existing roles and teams. Mass lock actions need the same treatment, because a bulk action that locks many records at once should be limited to the people who would be trusted to do that one record at a time. The written scope should name the test cases: locking a record as each role, editing a locked record through a permitted field, confirming that other edits are refused, unlocking, and running a mass action against a mixed selection. Handover documentation should record the settings, roles and test results so an administrator can repeat the checks.
Recurring work is smaller than the build but should be written into the proposal. Each EspoCRM upgrade needs a review of role permissions and the Lockable settings on each entity type, and each new entity type that holds approved records needs the same inventory, field decisions and tests. Ask the partner which of these checks are included in a fixed-scope build, which are covered by a retainer, and how long the handover test pack is expected to remain valid. Confirm with your own team which administrators will own the Lock permission after handover, because that ownership determines who runs the recurring review.
How DeployOpen scopes and delivers record locking
DeployOpen treats record locking as a controlled change to how approved quotes, contracts and cases can be edited. We agree the entity types, roles and editable fields in writing first, then configure, test and document the lock in your own EspoCRM instance, inside the infrastructure you control.
How we scope
- List the entity types that need Lockable, such as quotes, contracts or cases, and the status that triggers a lock
- Name the users who hold the Lock permission and who may unlock records, with the approval path for each
- Agree the fields that stay editable on locked records and the reasons each one must remain open
How we build
- Enable Lockable per entity type in the Entity Manager and set the Lock permission on the agreed roles
- Build layouts and mass lock actions so approvers can lock batches of approved records consistently
- Test locked and unlocked states with representative user roles, including attempts to edit and delete locked records
How we hand over
- Provide a written configuration record covering entity settings, role permissions and the editable field list
- Document the lock and unlock procedure for approvers, administrators and support staff
- Walk your administrators through changes so later edits to layouts or roles keep the lock behavior intact
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and reviews of role and layout changes are available as a retainer
- Confirm lock behavior again when you plan an EspoCRM upgrade, since permissions and layouts may need review
