Only Revenue Can Touch the ADR

Most CRMs treat edit access as one setting: a person can change a deal, or they can't. That's a blunt tool for a real B2B sales floor, where a junior account manager might reasonably update a contact's phone number or log a call, but shouldn't be the one who can quietly drop the negotiated ADR by fifteen euros a night on their own authority. The usual fix is a role, but a role is still all-or-nothing across every field on the deal. What a hotel group actually needs is narrower: this specific field, on this specific pipeline, editable only by these specific people.

The 15 fields a hotel group can actually lock

Field locks don't apply to a deal's whole record. They apply to a fixed, deliberately short list of the fields that actually move money or commit the hotel to terms: things like the deal's value and currency, the rate type, the estimated ADR, the commitment room nights, the promo code, whether payment terms have been accepted, a commission rate override, MICE budget lines, contract dates, and the cancellation penalty on a lost MICE event. Fields that identify the deal, who it belongs to, and how to reach someone about it, the deal's name, its account, its primary contact, are deliberately never lockable. A lock is allowed to restrict money and terms. It's never allowed to make a deal anonymous or unreachable.

Read-only versus propose: two different answers to "no"

A locked field has two possible behaviors, chosen per field, per pipeline. Read-only is a hard stop: if someone outside the named list tries to change it, the whole save is rejected, not just that field, because silently dropping a field from someone's save while pretending the rest went through is worse than a clear refusal that tells them exactly what happened and who owns it.

Propose is softer. The locked value isn't applied, but it isn't thrown away either. It's queued as a pending change request tied to that exact deal and field, waiting for one of the named owners to accept or reject it. A single save can mix both outcomes at once: the fields the person is actually allowed to edit go through immediately, and the locked ones get queued, with the response telling them plainly which is which. Nothing about proposing a change requires leaving the deal screen or filing a separate request somewhere else.

Restrict CRM field editing by role, without losing the request

The practical difference between the two modes is what happens to intent. A hard read-only lock on a field like the negotiated commission rate protects it completely, at the cost of a rep having no way to flag "I think this should change" without a side conversation outside the system. Propose mode keeps that signal inside the deal itself: the request sits visibly on the record, the person who can actually decide it sees exactly what was asked and why, and the decision, accepted or rejected, becomes part of the deal's own history rather than a Slack message nobody can find again in three months.

Which mode fits which field is a real judgment call a hotel group makes once, not something the software decides for them. A field where any unauthorized edit is a real problem wants read-only. A field where the concern is more "let's just make sure someone senior signs off" fits propose better.

One decision, every door it has to hold

A lock is only as good as its weakest entry point. A CRM that enforces a field lock in the deal-edit screen but not in its own API, or not in whatever automated path moves a deal forward, hasn't built a lock, it's built a suggestion with a UI on top. The enforcement here sits in exactly one place, the function every write path actually calls to update a deal, dashboard edits, the external API, and even the path that applies an accepted change request all route through the identical decision. There's no second door that skips it.

That single point of enforcement also means the check is change-based, not presence-based. Saving the whole deal form back with a locked field's value completely unchanged from what's already stored isn't treated as an edit attempt at all, so a rep isn't blocked from saving the rest of the form just because their screen happened to submit every field, including ones they never touched.

Why the PMS can still write the rate, but a person can't

There's one deliberate exception, and it matters: a lock governs people, not systems. An integration writing a rate back from a property management system, or any caller authenticated with an API key rather than a logged-in user, bypasses the lock entirely. That's not an oversight. A field lock exists to control who on a hotel's own sales team can override a negotiated term. It was never meant to interrupt the system of record updating itself, and a lock that broke an integration the moment a hotel group turned it on for the first time would make the feature unusable rather than safer. Locks stop a person from quietly overriding a number. They don't get in the way of the system that's supposed to be writing that number.

A sales deal approval workflow that can't approve itself

A proposed change doesn't just sit there waiting for anyone with deal-editing permission to wave it through. Deciding someone else's proposal requires being one of the field's specifically named owners, or an admin. Being able to manage deals in general isn't the same as owning this one locked field, and without that distinction the whole feature would be theatre: a commercial rep could lock a field to protect it, and then approve their own proposed change to get around their own lock.

Only one change request can be pending per deal and field at a time. A second proposal replaces the first rather than stacking a second conflicting number for an approver to untangle. And deciding a request is a genuine race in a fast-moving pipeline: the system claims a pending request before writing anything, so if two approvers try to decide the same request at once, only one of them wins the claim, and the loser gets told clearly that someone already decided it rather than silently overwriting their colleague's decision.

The lock that would trap a deal, refused before it's saved

One more failure mode is worth naming because it's the kind of thing that only shows up the first time it actually happens: what if a hotel group locks a field that a pipeline stage requires to be filled in before a deal can advance, and locks it to zero people? Every deal at that stage boundary would be stuck forever, with nobody able to unblock it. That configuration is refused before it can be saved at all, not caught after the fact when deals start silently piling up. A lock is meant to control who can change a number. It's never allowed to quietly seal a pipeline shut.

Until a hotel group actually sets up a policy, nothing here changes at all: every field on every deal stays exactly as editable as it always was. Field locks aren't a mode a B2B CRM is in. They're a specific, narrow rule a hotel group turns on for the handful of numbers where it actually matters who's allowed to say yes.