Privacy and permissions in CRM: how to build a policy

14 Oct 2024

Any new business system raises questions about who in the business should be able to access what. We refer to this as your privacy and permissions policy which, as I’m sure you can imagine, is a pretty big deal when it comes to CRM.

In an ideal world, all of your business data is going to be held within this single system. All the major processes will be conducted and/or tracked within it. Deciding who gets to see (and interact with) what is essential.

It’s a conversation I typically start to have with people as soon as they mention how many people in their organisation will be using the system. Often it starts with an offhand:

“And will all of these users be able to see each other’s data/records?”

I use it, in many ways, to prompt people to think about it. About half of people already have a vague plan in mind, while the other half haven’t really started to think about it yet.

Both are fine, but it is something you should definitely have a strategy for before you start your system configuration or data import. Honestly, it is one of (if not the most important) part of your CRM implementation.

I’m going to start this blog by discussing the difference between privacy and permission when it comes to your CRM solution. Then, I’d like to give you an overview of how we usually approach the question here at OpenCRM…both as a company that uses a CRM (our) and as a company that provides a CRM system to other businesses.

What is the difference between “privacy”, “permissions”, and all these other words?

When you’re building a policy on who can access (and interact with) your company data, you’ll need to be familiar with a few words.

Privacy
This refers to how visible a record, type of record, or elements within a record are by the members of your organisation.

Permission
On the other hand, this refers to what people can do with these records and the data within them.

Security
Finally, system security is all about protecting your system as a whole from outside sources. This blog isn’t really going to discuss this element, but it’s worth noting that there is also the other kind of protection going on.

Building your policy

When it comes to actually building your policy, there are three things you HAVE to do…and then two more that you probably SHOULD do.

And I don’t mean you should just sit around a table and chat about what your policy should be. Ok, you probably will do that. But once you’ve finished that very important chat, you really should document the policy and store it with all your other business management policies. It should sit right alongside your disaster preparedness and GDPR plans.

A privacy and permissions policy for your CRM and other systems is just as important. It’s your business data. And being able to say who can do what with it.

Step 1: Identify the data

The first step is to decide what data you’re talking about…and this isn’t as stupid or obvious as it sounds.

Start with the really obvious stuff…the people and organisations you deal with (Leads, Contacts, and Companies), then think about how you interact with these people. This will start you down the path of looking at your Activities, Emails, Documents, Projects, Tickets, and so on. Then you’ll think about the financial stuff: Invoices, Contracts, Quotes, Opportunities.

Naming all the areas of the system you plan to use is just the start, though.

Once you know which modules or record types you’re dealing with, you must consider the fields and data within them. For example, maybe everyone in your organisation should be allowed to see Company records, but do they need to see the Credit Control fields? Or the costs held against a Project?

In building your privacy and permissions policy, get down to the granular level. The goal here is to label your data with one of three categories:

1. Private: Stuff no one should see
2. Restricted: Stuff some people should see but not interact with
3. Open/Shared: Stuff everyone can see and interact with

Once you know whether data should be restricted, private, or shared, you’ll already have an idea of who those restrictions refer to…which leads me to the next step.

Step 2: The privacy and permissions of each

Now that you have your data into its various categories, let’s start by looking at its privacy. It’s time to decide who should be able to see the various types of data…who will be placed in the allowed vs. not allowed groups for each.

Let me explain with a little visual that I think will make it easier:

Data	Category	Allowed	Not All
Companies (except credit control fields)	Shared	All	None
Companies credit control fields	Restricted	Finance, Senior Sales	Everyone else
Leads	Restricted	Sales	Everyone else
Activities	Shared	All	None
Projects	Restricted	Operations, Sales	Customer service
Emails assigned to one of the directors	Private	Only assigned user	No one else

You can see how the list could easily grow into something quite complex.

Then, we make it even more complex by discussing what those people in the “Allowed” group should be able to do with the data—moving from privacy to permission.

What I mean by this is should their permission stop at just viewing or accessing the record/fields or should they be able to edit it? Should anyone be allowed to delete records? If so, which ones?

And how should permissions change for records “owned” by other company employees?

Don’t worry, I’m going to go through each of these options in a bit more detail…I know it’s a lot to take in and think about.

Viewing/Accessing

The first thing to consider when giving people viewing permission (so the privacy of the module, record, or field) is to think about the information held there that they need to do their job. You wouldn’t want to restrict your customer service team from seeing a Contact record, for example, but do they need to see each person’s address or some of the custom fields you’ve created.

Quite often, record privacy is controlled at a very high level. One of your users can either see the module as a whole or they can’t. But we do have some customers (and do this ourselves a bit) where restricting access to individual fields is necessary.

So when you’re deciding who has access to a type of record, consider the following:

• What information do they need to do their job?
• Is there other information in that module that is more sensitive?

Of course, there will always be individual records that you need to restrict further, but those two questions are a good starting point.

Editing

Similarly to the above question of privacy, deciding whether a particular user role (or profile) needs to be able to edit a record is about assessing whether they need it for their role and whether certain fields should be restricted further.

The question here shouldn’t be “what damage could they do” by being able to edit or create records, but rather if you don’t give them permission to edit, is that going to impact other people’s jobs.

For example, if you let your sales team view Invoices, but not edit or create them, someone else will have to do that job on their behalf. And that may be the right answer for your team, but it does need to be considered at the same time you’re deciding whether a group of users should have this permission.

Saying that, if you are worried about the damage users could do by changing information within records, you might want to think about features like being able to audit all field changes. This way you still have the previous information if you need it.

Deleting!

Before you decide whether you should give your users permission to delete records, make sure you read through our guide on what deleting records actually means.

Read it? Good.

Now it’s time to think about whether any of your users should have permission to do this. When do people actually need to be able to delete something? Is it just that they need it off their lists?

I’ll give you another example, this time from the point of view of our own projects team. Although they live in the Projects module, a lot of the actual work is done based on the Activities they create, edit, and use to manage their unending list of to-do’s.

Projects rarely get created so incorrectly that it’s faster to delete and start fresh. But Activities? Those are easy to create by mistake and sometimes our project managers will just make the decision that it’s easier to delete one to restart.

Because of this, we don’t let them delete Projects, but we do let them delete their own Activities. In the rare case that Project records actually need to be deleted rather than just archived (one of our many statuses), they can be bounced to someone more senior. It happens so rarely that this isn’t a big ask or something that ties up these people’s days.

Sharing with others…and who are they?

All of the above options are further complicated by the question of privacy and permission between users and groups of users. Simply put: who’s records your users should be allowed to view, edit, and delete. Is it only the people in their department? Or everyone?

The example I usually use here is sales…those competitive salespeople causing trouble again. But it’s a cliché because it’s true. You might need to restrict your salespeople from editing (or even seeing) other salespeople’s Leads to stop them from poaching from each other.

Or you might not need to make any restrictions here at all. But it’s a question you should ask yourself…and for each module. The answer for Activities, for example, might be very different than the one for Personnel or Emails.

Step 3: Recognise the exceptions (and the administrators)

Now there will always be people in your organisation that need extra permissions or even administrator control because of their job role or position in the company.

Managers, for example, will probably have subtly different permissions from the people they manage. Maybe they can edit EVERYONE’s records, while everyone else can just SEE each other’s records.

Other people, your design team, for example, may be given limited administrator access to create and edit email, pdf, and other templates for the business as a whole.

On the other hand, certain users will need to have stronger privacy and permission control around the records assigned to them…I’m thinking of directors here. The Emails and Activities of your board could easily need some additional restrictions to ensure they are able to work on business sensitive information without worrying about who can or can’t see it.

So once you’ve decided the rules for the majority, consider which people will stand slightly outside this model and how you will accommodate them.

Step 4: Ask for advice

I suggest one more step before you implement your entire permissions and privacy policy.

Whoever your CRM provider is, take your documented policy and ask them for the best way to implement this in their system.

They will know what options are available, the best way to account for your exceptions, and may even come up with some extras you weren’t aware of. As most CRM systems evolve, new features are added with additional controls and permissions around them.

For example, when we added permission controls around the creation and editing of custom views, we added a setting to let you choose whether this was restricted to admins or if everyone should be able to do it. It’s not a setting you might notice at first, but it is one that can come in useful.

Asking for advice on something as important as this is never wasted.

Step 5: Implement and review

You’ve got your privacy worked out and documented all of the various permissions, as well as the exceptions to these rules. So it’s time to start building.

Whether you do the actual implementation yourself or pay your provider to do the set up, the important step comes after. Once your users start actually using the system.

You will quickly see where different permissions (and even privacy) need to be tweaked. People will struggle to do their work, or they’ll edit things they shouldn’t. Other things will work perfectly for a while, and then people’s roles will change and evolve, making it necessary to adjust your policy.

Regularly reviewing your policy and documenting the changes you need to make is key.

The ongoing work

There will always be new types of data, new departments within the business, people who suddenly become more of an exception than they were before, and on and on. Businesses change and evolve; your privacy and permissions policy needs to do the same.

So when it comes to your regular review (maybe at an annual company or board meeting) think about what has changed and go through the above steps to determine how this new data or job role fits within the wider policy.