Good CRM security is about ensuring the right people have the right privileges to your information.

But what are those privileges?

Although the names vary from system to system, there are four basic CRM user privileges: read, write, create, and delete.

There are other user rights, of course. For example, Microsoft Dynamics 365 for Sales also uses append, append to, assign, and share. But create, read, write, and delete will be at the core of most of your work in CRM.

Who you give these rights to is very important. Too many privileges to too many users can create a free-for-all database; too few can make it difficult for people to do their jobs.

In this article, we’ll take a closer look at each of the 4 core CRM user privileges. The better you understand what each can do for the various members of your organization, the better you’ll be at managing your CRM security.



The most basic CRM user privilege is the read privilege (sometimes called “view”). A user with read rights to a field, record, or entity can see that information.

For some businesses, controlling read rights is about keeping things simple for users who only need to interact with certain records.

But for businesses with commission-based sales positions or highly sensitive data, controlling read rights can be critically important.

For example, one of the most common fears among commission-based sales teams is that CRM could allow others to steal their leads. And if your sales team has unrestricted read access to everyone’s leads, that could be a very real problem!

Determining who can see what in CRM is an important series of decisions. Read rights should mirror your existing business processes. So if your sales team is competing for sales, don’t make CRM a liability by revealing too much information. But if your sales team is collaborating on sales, don’t undermine their efforts by hiding too much.



The write privilege (or “edit,” in some systems) allows a user to make changes to a field, record, or entity.

The most important thing to remember about the write privilege is that when a user makes changes to your database, those changes become true. At least, that’s how your CRM sees is.

Too many writers—or worse, the wrong writers—can result in inconsistencies in your information. Too few can make it difficult to update that information.

This is especially important across business units. For example, you may want your sales team to see customer service information related to their accounts, but you probably don’t want them to be able to edit records owned by your service department (and vice versa).

As with read privileges, your write privileges should mirror your business processes as best as possible.



The create privilege allows a user to make a new record.

For some of your users, this will be an essential CRM user right. For example, many members of your customer service team will need to create new cases. Similarly, many members of your sales team will likely need to create new opportunities.

But in order to limit duplicate data entry (and prevent the need for massive data cleaning sessions), you’ll want to limit create rights to users and contexts that truly need them. In other words, just because User A needs to create Record X doesn’t mean they need to create Record Y.

Limiting create rights to too few people, or giving them to the wrong people, can make working in CRM unnecessarily difficult for your team. Still, we suggest you start simply, and adjust as needed. It’s much better to learn that you need to add a few create rights than it is to learn that your database is full of duplicate and incomplete records.



This is the big one. The delete privilege allows a user to permanently erase a record. Delete rights are the most dangerous CRM user privileges to get wrong.

Some of your users will absolutely need this privilege. But only those who need it should have it, and you should err on the side of caution when doling out delete rights.

If that means saving delete rights for system administrators, especially at first, then so be it. The majority of your users may end up needing to send an email to get a record deleted, but that’s typically going to be far less onerous than doing so to get a record created, and the consequences of deletion errors are much more dire to your database.

Remember: Your information is valuable. If it weren’t, you wouldn’t need CRM to manage it.



Your CRM security matters!

Learn CRM security best practices that will help you get the most from your system in our CRM Security archives!

For specific questions, or to get help setting up, cleaning up, or changing up your Microsoft Dynamics 365 for Sales CRM security, contact us to consult with one of our experienced CRM success coaches!



Was this post helpful? Enjoyable? Do you have feedback or additional questions? Let us know in the comments, or contact us directly. We’re here to help!