How can collaborators suggest spreadsheet changes without editing the source list?
Quick answer
Use a separate change-request queue rather than treating suggestions as edits to the source list. Ask collaborators to identify the exact row and proposed change, then have a reviewer mark each request Pending, Approved, Declined, or Applied. In Google Sheets, a linked Google Form can collect proposals separately, while cell comments can support discussion; neither route automatically approves and applies a change to the source list. [S1] [S2]
The question, the details, the next step.
I need people to flag corrections to a shared spreadsheet list, but I don’t want the list itself changed before someone checks the request. What’s a simple setup?
Make a separate change-request queue and treat it as the place for proposals, not as the source list. Give each request its own row with fields such as request ID, date received, affected row or record, current value, proposed value, reason, status, reviewer, and decision note. Use a stable identifier for the source row if one exists; a name alone may not identify the intended record clearly.
For a low-friction intake, a Google Form can collect proposals separately and link responses to Google Sheets. It is an intake route, not an approval process: a reviewer still needs to check each proposal and decide whether to apply it. [S1] Keep the source list unchanged while a request is pending.
What if someone notices the issue while looking at a particular cell? Would comments be better than a form?
Comments can be convenient when the proposal needs context tied to a cell. In Google Sheets, collaborators with comment or edit permission can reply in a comment thread, and a comment can be resolved to close the discussion or reopened later. [S2] But resolving a comment is not the same as approving a change or editing the cell automatically; the reviewer must decide what happens. [S2]
Use a form or separate queue when you want requests gathered in one place with consistent fields and explicit status tracking. Use comments when the conversation depends on the context of a particular cell. You can also ask collaborators to submit a queue entry and add a comment when extra explanation is needed. Pick one place as the official record of the decision so a discussion does not get mistaken for an applied change.
How should we handle the review so it’s obvious what’s waiting, approved, or finished?
Use statuses with distinct meanings and move each request through them deliberately:
- Pending — received, not yet reviewed.
- Needs information — reviewer cannot decide yet; note what is missing.
- Approved — reviewer has decided the proposed change should be made, but it has not been made yet.
- Declined — reviewer decided not to make it; record a brief reason where appropriate.
- Applied — the approved change has been made to the source list; record when and by whom.
A reviewer can check whether the request points to the right record, compare the current and proposed values, and consider the stated reason. If approved, the reviewer applies the change to the source list and then marks it Applied. If declined, leave the source list as it is and record the decision. In a comment-based discussion, resolving or reopening the thread can manage the discussion, but it does not replace that review and decision record. [S2]
Can you show me what one complete request and review might look like, including what collaborators should submit?
Here is a copyable example using invented placeholder information. Replace it with your own field names and records:
Request ID: CR-014 Affected record ID: [item-027] Field to change: [Department] Current value: [Operations] Proposed value: [Facilities] Reason or evidence: [The assigned team name on the latest internal record is Facilities.] Status: Pending Reviewer: [name or role] Decision note: [blank until reviewed]
After review, the reviewer might set the status to Approved, enter a short decision note, make the change in the source list, and then set the status to Applied with the application date. If the request cannot be confirmed, use Needs information and state what is needed. If the reviewer declines it, record Declined and a concise reason. These are suggested workflow fields and labels, not built-in automatic approval features.
A practical checklist
Choose a separate request queue, cell comments, or a clearly defined combination.
Ask for a stable record identifier, the field, current value, proposed value, and reason.
Keep every new proposal Pending until a reviewer checks it.
Distinguish Approved from Applied so approval does not imply the source list is already changed.
Record the decision and, when applied, who made the change and when.
A few more useful answers
Does linking a Google Form to a spreadsheet approve requests automatically?
No. The form and linked sheet can collect proposals, but a reviewer still needs to check each one and decide whether to apply it. [S1]
Does resolving a cell comment mean the proposed change was accepted?
No. Resolving closes the discussion, but it does not automatically accept the proposal or edit the cell. Record the decision separately and apply approved changes deliberately. [S2]
Which method should I choose for a small team?
Choose the route your team will consistently use: a separate queue for structured, trackable requests, or comments for cell-specific discussion. Whichever you choose, define where the final decision and application status are recorded.
Sources
References used for this guide.
- [S1] Publish and share a Google Form with responders support.google.com · Checked
- [S2] Use comments, action items, and reactions in Google Sheets support.google.com · Checked