Permission design is where security and usability collide. Lock things down too tightly and salespeople email spreadsheets around to get their work done. Open things up too widely and a single compromised or careless account can expose the whole customer base. A good model protects sensitive data while staying invisible to people doing legitimate work.

This article describes a design approach rather than a product-specific recipe, since permission features differ between platforms. Check your vendor’s current documentation for the exact mechanisms available.

Separate the Three Questions

Permissions answer three different questions, and mixing them up creates confusion.

What can this person do? This covers actions such as creating, editing, deleting, exporting, and administering. It is usually governed by roles or permission sets.

Which records can they reach? This covers visibility: their own records, their team’s, a region’s, or everything. It is usually governed by ownership, hierarchy and sharing rules.

Which fields can they see within those records? Some fields, such as discount approvals, contract terms or personal identifiers, may need tighter control than the rest of the record.

Designing each question separately keeps rules simple to explain and audit.

Start From Roles in the Business

Map your organization’s real roles before opening the admin console: sales representative, sales manager, customer success, support agent, marketing user, finance viewer, operations administrator. For each, write a sentence describing what they need to do and what data they need to do it.

Aim for a small number of well-defined roles. A model with dozens of one-off exceptions becomes impossible to review, and every exception is a place where access can quietly outlive its reason.

Grant Narrowly, Then Layer On

A sound pattern is to start every user with the minimum baseline and add capabilities through named, documented permission sets. Prefer additive grants to special-case removals. It is easier to reason about “baseline plus these two additions” than “everything except these exceptions.”

Treat high-risk capabilities with special care:

• Mass export and report export
• Bulk update and delete
• Creating or authorizing integrations and API access
• Managing users and permissions
• Changing platform configuration

Restrict these to people with an explicit need, and consider an approval step for temporary elevation.

Think About Record Visibility Deliberately

Choose a default visibility stance for each object. Many organizations make accounts broadly visible for collaboration while keeping opportunities or cases tighter. Then use hierarchy, teams and sharing rules to extend access where the business demands it. Document why each rule exists, because six months later nobody will remember.

Permission Model Summary

Layer	Controls	Design Tip
Action permissions	Create, edit, delete, export, administer	Bundle into role-based permission sets
Record visibility	Ownership, hierarchy, sharing rules	Set a default, then open access with documented rules
Field access	Hidden or read-only sensitive fields	Reserve for genuinely sensitive data
Administrative rights	User management, configuration	Keep the group very small
Temporary access	Time-limited elevation	Require approval and expiry

A Realistic Example

Imagine a hypothetical company with regional sales teams, a central finance group and a customer success department. Initially, everyone had broad access because it was easier to set up. After a near miss in which a departing representative downloaded a large account list, leadership asked for a redesign.

The administrator defined five roles, made export rights a separate permission set approved by managers, limited visibility of opportunities to the owner’s team and management chain, and masked contract-value fields for roles that did not need them. Customer success kept read access to accounts across regions, because their work depended on it. Complaints were few, mostly because the design followed how people actually worked.

Test Like a User

Before rolling out a model, test it using representative accounts for each role. Walk through daily tasks, such as finding an account, logging an activity, creating a quote, running a report, and see whether anything is blocked or exposed. Many platforms offer a way to view the system as a given user. Use it, and fix gaps before launch rather than after a flood of access requests.

Keep the Model Healthy

Permissions decay. People change roles, projects end and exceptions pile up. Schedule periodic access reviews, particularly for administrators and anyone with export rights. Ask managers to confirm that each person’s access is still needed. Remove what is not.

Also record changes. When permission sets are edited, log who changed what and why. This audit trail is invaluable during an investigation and helps new administrators understand intent.

Frequently Asked Questions

Should everyone be able to see every account? Not necessarily, but broad account visibility often helps collaboration. Decide based on data sensitivity, regulatory needs and how teams work, and tighten selectively.

How many roles are too many? When you can no longer explain each one in a sentence or review them in a reasonable session, there are too many. Consolidate and use additive permission sets instead.

What about contractors and temporary staff? Give them time-limited accounts with narrow access that expire automatically, and review them more often than permanent staff.

Is field-level security worth the effort? For genuinely sensitive fields, yes. Applying it everywhere adds complexity without proportional benefit, so use it sparingly.

How do we handle requests for extra access? Use a short, documented request process with an owner who can approve, and record the justification. Fast, consistent handling reduces the temptation to share logins.

Next Step

Draft a one-page role map listing each business role, the actions it needs, the records it should see and the sensitive fields it should not. Review it with a sales manager and a security colleague before touching any settings.