Not everyone should see the margin, a client page should stay read-only, and a technician doesn't need to see prices. Here's how to set up who on the team sees and can change what, once and for good.
The question "who should actually see this" comes up sooner or later in every growing company - the margin on an order, clients' personal details, internal notes on a business negotiation. The solution isn't one shared file for everyone, but setting access rights exactly as precisely as you actually need, without having to set them up over and over again.
Three levels at which permissions are set
Page or database - who has access to it at all, and whether it's read-only or also editable.
Column - a specific sensitive field (margin, personal data, internal note) can be restricted independently of who sees the rest of the record.
Sharing outward - what's meant for the team only, and what can be safely shared outside the company, for example with a client or on a public website.
Permissions that inherit, instead of being set up over and over
Pages and subpages can be nested inside each other endlessly, and permissions are inherited from the top down - you set them once at the highest level and they apply across every subpage and order beneath it, without needing to set them individually for each one.
Nest pages inside each other endlessly - permissions are inherited.
Access is set once at the top level and then applies throughout every subpage - you don't have to set it up separately for every order or client.
A sensitive column on its own, independent of the page
Sometimes it's not about a whole page but one specific field - say, the margin on an order that only the sales director should see, while the rest of the team sees the rest of the record. Column-level restriction works independently of who has access to the page as a whole, so it can be combined however you like.
Safe sharing to the outside
Not everything is meant for the internal team only. A view, page or report can be shared outward - read-only, with a client, or even as structured data (JSON) to connect to your own website or app. Sharing outward is always an explicit decision, not the default state.
How to plan your setup
Before you start setting up permissions, it's worth answering three questions: who on the team should see sensitive fields (prices, margins, personal data), who should only read and who should also edit, and what - if anything - should be visible outside the company. The answers then translate into a role structure you set up once and that applies across the whole system.
What hiding a single column looks like in practice - alongside two other CRM edits - is shown in What a CRM you can edit yourself looks like.
Frequently asked questions about access rights
Do I have to set up permissions for every order separately?
No, thanks to permission inheritance it's enough to set access at the top level (for example the whole orders database), and it then applies automatically across every subpage and record beneath it.
Can I restrict just one field and leave the rest of the record visible?
Yes, column-level restriction works independently of permissions on the whole page - a sensitive field (say, the margin) is then seen only by a chosen role, while the rest of the team sees the rest of the record.