Permissions That Make Sense: Who Should See and Edit What

Somebody in sales sorted the shared customer sheet by region last quarter and didn’t notice that two columns weren’t selected. For three weeks, every account had someone else’s renewal date. Nobody was malicious. The sheet simply let anyone with the link do anything to everything.

When you move a process into proper tooling, permissions are one of the biggest upgrades you get. They are also one of the easiest to get wrong, either by copying the spreadsheet’s free-for-all or by overcorrecting into a system where nobody can do their job without filing a ticket.

Why spreadsheets fail at this

Your spreadsheet tool offers roughly three settings: can view, can comment, can edit. Those apply to the whole file. Some tools let you protect a range or a tab, but in practice those protections get switched off the first time they block someone on a deadline and never get switched back on.

So teams compensate in other ways. They make copies “just for finance.” They hide columns and hope nobody unhides them. They keep the salary tab in a separate file with a different owner. Each workaround creates another copy of the data, and every copy drifts.

A real internal tool can do much better. It can control access at the level of a whole table, an individual record, or a single field. It can tell the difference between creating something, editing it, approving it and deleting it. That flexibility is the good news and the bad news, because now you have to decide.

Start with jobs, not people

The most common mistake is setting permissions person by person. Priya gets edit access to these three tables, Marcus gets view access to that one, and so on. Six months later you have forty individual exceptions and no idea why any of them exist.

Instead, define roles: a named bundle of permissions that matches a job someone does in the process. Then assign people to roles. When Priya changes teams, you change her role, not twenty settings.

Take a fictional field services company tracking jobs. Their roles might look like this:

Four roles, described in plain language, covering about thirty people. Anyone can read this table and understand who does what.

The four questions for every role

For each role, work through these questions. Write the answers down before you touch any settings.

1. Which records? All of them, only their own, only their team’s or region’s? “Only my own” usually means records where they are the assigned owner or the creator.
2. Which fields? Most people need most fields. Identify the few that are sensitive (pay rates, margins, personal contact details) and decide who needs them.
3. Which actions? Create, edit, change status, approve, delete, export. These are separate decisions. A technician might create a job note but never delete one.
4. When? Some permissions depend on state. Once an invoice is marked as sent, perhaps only billing can change it. If you’ve read Replacing the “Status” Column: Designing Real Workflows with States and Transitions, this is where those state rules turn into actual guardrails.

Avoiding lockdown

Overcorrection is real, and it is usually driven by one bad incident. After the sorting disaster, the sales lead locks everything down and makes every change go through an admin. Within a month, people are back to keeping private copies, because the official system is too slow to use.

A few principles keep you out of that trap:

• Default to visibility, restrict edits. Most data isn’t secret. Letting people see the full picture reduces the “can you send me the latest numbers” messages. Be stricter about who can change things.
• Restrict deletes almost entirely. Deleting is rarely necessary. Archiving or marking as cancelled keeps history and is reversible. Give delete rights to one or two admins.
• Protect fields, not whole records. If only the discount field is sensitive, lock that field instead of the entire deal.
• Rely on the audit log. Good tools record who changed what and when. Knowing that every edit is traceable lets you be more generous with access, because mistakes can be found and fixed.

That last point matters more than people expect. In a spreadsheet, a bad edit is often invisible. With a proper change history, a wrong value is a five-minute fix rather than a three-week mystery.

Handling the awkward cases

A few situations come up in nearly every rollout.

The person who does three jobs. In a small team, one person might dispatch in the morning and do billing in the afternoon. Most tools let you assign multiple roles. Do that, rather than inventing a “Dispatcher-plus-billing” role for one person.

Contractors and external partners. Give them their own role with the narrowest scope that works, typically only the records tied to their work. Set a review date for their access when you create it.

The executive who wants everything. Usually they want to see everything, not edit everything. A read-only “Leadership” role, plus the dashboards from Reporting Without Exports: Getting Dashboards from Your New System, satisfies the need without letting a well-meaning director overwrite a field during a meeting.

The admin role. Keep it to two people, ideally not the same two who do daily data entry. Admins can change the rules themselves, so treat that access with more care than any other.

Review it like you review anything else

Permissions decay. People change jobs, contractors finish, a temporary exception becomes permanent. Put a quarterly reminder in the calendar to export the list of users and their roles and check it against reality. It usually takes about twenty minutes and nearly always turns up someone who left months ago.

Where to start this week

• List the roles in your process as jobs, not names. Aim for three to six.
• For each role, answer the four questions (records, fields, actions, when) in a one-page table like the one above.
• Identify the two or three genuinely sensitive fields and decide who needs them.
• Pick your two admins and remove delete rights from everyone else.