The grid would not save an edit
The grid does not save anything itself. It hands every edit to the service that owns that record, and a cell that snaps back is that service declining. The refusal carries a reason, and it is one of six: a field the service never accepts, a value it will not take, a permission you do not have, a rule that governs the field, a stale row, or a column that is derived rather than stored.
What you see, and what it means#
You type into a cell, press Enter, and the old value returns. Sometimes with a message beside it, sometimes with a marker on the row you have to hover to read. What has happened is that #/data sent the change to the owning service — people, companies, leads, prospects, follow-ups, deals, conversations, calls, cases, onboarding, knowledge, files or memory — and that service said no.
This is the same answer you would get editing the record on its own screen. The grid is a view over thirteen sheets, not a second system with its own rules, so there is no version of the field that is easier to change somewhere else. Finding *which* rule refused is therefore the whole job.
The six reasons, most likely first#
| Reason | How it reads | What actually helps |
|---|---|---|
| The value fails validation | A format or range complaint about the thing you typed | Match the format the record's own screen uses — a date, a stage name, an identifier |
| A required field would be emptied | A refusal on a blank rather than on a value | Set the replacement in the same edit instead of clearing first |
| The column is derived, not stored | The cell does not enter edit mode at all | Change the thing it is derived from; a last-contact date follows the contact |
| Your permission does not cover it | A refusal that mentions access rather than the value | Ask someone with rights on that record type, or have your access changed |
| A rule governs that field | A refusal naming a policy rather than a format | The rule is the thing to change, on the screen that owns it — not the cell |
| The row is stale | Your value looks reasonable and is still refused | Refresh the sheet; something changed the record after your page loaded |
What Connect completed#
- The edit was carried to the owning service rather than dropped in the browser, which is why a reason exists at all.
- The record is untouched. A declined edit is not a partial write: no field moved, no timeline entry appeared, nothing has to be undone.
- Other rows in the same selection are unaffected when the refusal happened during a bulk run — see editing many records at once.
So the state you are looking at after a refusal is exactly the state you were in before you typed. That is worth knowing before you start reconstructing anything by hand.
What Connect did not complete#
The change was not saved anywhere, not queued for later, and not turned into a request for somebody to approve. There is no pending edit sitting behind the scenes waiting for a permission change to release it. If you fix the cause tomorrow, you type the value again.
Nothing was written to the audit trail either. The decision log records changes that happened; a refusal leaves the record's history unchanged, which means a colleague looking later will see no trace of the attempt.
Getting to the reason, and who can change it#
Read the refusal text before retrying, and note whether it talks about the value, about access, or about a policy.
Result Those three groups separate the six causes into ones you can fix, ones an administrator fixes, and ones that are working correctly.
Open the record on its own screen and make the same edit there.
Result Same refusal means a rule; a different or absent one means the sheet was showing you a stale row.
If it is validation, copy the shape of a value that already exists in that column on another record.
Result You are matching what the service accepts rather than guessing at its format.
If it mentions access, stop and ask rather than trying a different route in.
Result The routes all end at the same service, so a second attempt through the Assistant or an import produces the same refusal.
An administrator can change permissions on a record type, and can change the rules that govern a field on the screen that owns them. What an administrator cannot do is let one edit through as an exception: there is no override that applies to a single cell, and a do-not-contact entry in particular is not something to clear casually.
Escalate when the refusal names no reason at all, or when the same edit is accepted on the record's own screen and refused in the grid on a freshly loaded sheet. Both are inconsistencies rather than rules, and they are worth reporting with the sheet, the column and the wording.
Questions#
Can I see who set the rule that is refusing my edit?
Rules are held on the screens that own them rather than in the grid, and the decision log records changes people made, including changes to how Connect behaves. Between the two you can usually establish what the constraint is and when it appeared, which is generally more useful than the name attached to it.
Does asking the Assistant to make the change get round the refusal?
No, and it is worth understanding why. data_update calls the same owning service with the same validation, and the Assistant's rights are narrower than yours rather than wider — no pricing, and it cannot clear a do-not-contact entry. If a route existed that skipped the rules, the rules would not be rules.
Why did the cell not even let me type?
That is the derived-column case. Some columns are computed from other records — the date of the last contact, a count of open items — and there is nothing to store, so the cell is not editable. Change the underlying event or record and the column follows on the next read.