Common Data Service is an Azure based service that allows you to bring data together from the Dynamics family of products, along with other external sources. It is based on the concept of having data living together in one place, where it can be served to apps created through PowerApps.
As described in this previous article, you start by creating an environment. With that in hand, you are ready to create your first database. Make sure you are an administrator in the current environment where the database is to be create, and that the correct license is assigned to you. You create the database either through the Admin center as described in the linked article, of directly from the PowerApps working console, by selecting first the environment you will work in, and then navigating to Common Data Service > Entities.
During the creation wizard, you are prompted to select the user access model you want. You can change this later, but the choices are Restrict access or Give all users access. Open access (Give access to all users option) disables security, while Restrict access enforces the security model. Unless you have a good reason for Open access, select Restrict access (the default option).
Now you have a database in your environment, and are ready to delve deeper into how to use it.
Database Security
Before you even do anything with your newly created database, review the security model and make adjustments as necessary. Let’s have a quick look at the database security in CDS.
The security model is based around simple CRUD (Create, Read, Update, Delete) permissions on entities. The exercise here is to determine which users require which type of access to the entities defined.
By default, CDS comes with two security models defined: read-only and full access. These are available as Permission Sets, per entity. Permission Sets and User Roles combined give you the ability to create a complex security model for your applications.
You get to the configuration by selecting your environment, and on the Security tab you’ll find both User roles and Permission sets as seen in the screenshot below.
In order to configure permissions, you first start by creating Permission sets. You do this from the Permission sets area, by selecting New permission set. The wizard allows you to give the set a name and description, after which you open the record and select the permissions required by entity.
Have a look at the default Permission sets for inspiration on groups of permissions, then design your own sets as needed.
Once you have the sets defined, you move on to User roles. Here, you can create a custom role, and assign on the Permission sets tab the sets that comprise the security needed for this type of user. You do that by typing a name in the search box, and selecting from the results. Do not rush to press enter, that will select the first result in the list.
As you can see in the screenshot above, for a Sales User I’ve added four permission sets. Add as many as you need for a complete user role. It makes sense to have granular Permission sets, and assign as many as you need for a User role.
Once you have the Permission sets assigned to a User role, go to the Users tab and assign the users to the selected role. You do it same way as adding permission sets, by starting to type the user name in the search box and selecting the user from the results.
When done, make sure to Save your configuration.
And with that, now you have a standard database, along with a security model defined.
You can edit or remove Permission sets and User roles at a later time, by clicking the Edit (pencil) icon or the Delete (trash can) icon on each record.
Next article will look at basic configuration of the database, adding and removing entities, and working with data.
Enjoy!
thatcrm.com 
Leave a Reply