So you’ve got an Office 365 licence that comes with seeded Power Apps and Flow. This means that you can connect to SharePoint as a datasource – brilliant so let’s start building some apps and automating some process. Well this is absolutely fine but I would class a SharePoint as a data source that can do Personal or a Team productivity data store.
I would not use SharePoint as the data source for business critical or line of business (LOB) applications. If you have the correct licensing available and skillset available I would suggest that the CDS is also considered for applications that are team based.
Now lets break down into why I think that the CDS is better than SharePoint for developing applications – this isn’t the case for every single business application or business process but should be considered on a case by case basis.
Please remember this isn’t an article about licensing costs. But for clarity using the CDS in general will require licensing that has a cost associated – https://go.microsoft.com/fwlink/?linkid=2085130
If you’ve been using SharePoint for any period of time to create business applications I’m sure you’ve heard the phrase ‘SharePoint isn’t a relational database’! What this means is that SharePoint shouldn’t be used to mimic a relational data structure.
This is because you can’t create the types of relationships that the CDS can create. In the CDS you can create an Entity that has a relationship to another Entity. These relationships can be defined as:
- One to Many – A record in one entity relates to many records in another entity. An example of a one to many relationship would be a relationship between Vehicle Manufacturers and Vehicle Models. This is because a Vehicle Manufacture has many different models.
- Many to Many – When many records of one entity and be related to many records of another entity.
In addition to being able to create relationships you can also define the behaviour that these two entities have. A sample type of relationship would be Parental. In the One to Many relationship of a Vehicle Manufacture to a Vehicle Model this could be created as a Parental Relationship. This would mean that if a Vehicle Manufacturer is deleted it would delete all the Vehicle Model records that are related to that manufacture.
Now, even though in SharePoint you could try to mimic the types of relationships above you would have to build the logic into the canvas application. The issue with this is that if you want to build out this level of logic then you have to do it all in the Power App. With the CDS it isn’t part of the interface but instead is separated out of the application interface.
|Entity Relationship Behaviour||https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/create-edit-entity-relationships|
Management of Data
So you’ve created an application that uses SharePoint as a datasource. This list or library exists in one site collection that is used by team A. Now team B need an application that is identical but they can’t have access to team A’s SharePoint site. This now means that you are basically creating the same data structure in two different locations. Now if this were to get replicated to more sites then the problem gets worse.
Another issue that can occur is that it becomes more difficult for the IT Administrators to understand where all the data is stored for the applications that are created in the Power Platform. As it isn’t easy to identify what sites the SharePoint connectors are going to. This can create problems as if a Site Owner isn’t aware that a user created a list used in an application and then the Site Owner deletes the list the application would break until the list is restored.
SharePoint security is provided by giving levels of access to areas of SharePoint. A user gets access to a SharePoint site. By default this would give them a level of access to all the content of that SharePoint Site. For example, the contribute permission would give edit access to each list or library in that site. This permission can be changed but it still means that the user is given a level of access to a list. This means that the individual has access to each item in that SharePoint list.
The CDS is secured at the record level. This means one record could have different permissions to another record but they are are all stored against the same entity. In addition to this the security can be applied to the fields of an entity. This would mean that a field could be read only for one user and editable for another. This would all be done without writing any code as it is just configuration against the entity.
The CDS security model is based on Role Model Security. A role can be created against the entities that you create as part of a system and can be assigned to users, teams or business units.
Mode Driven Applications
Model-driven applications are component focus applications. They aren’t as customisable as canvas applications but as the layout is defined by the designer. However, model apps provide a consistent user interface between different applications and can be similar to develop the canvas apps as the components available have more in-built features than canvas apps.
When using SharePoint you can’t create model driven applications. Model-driven applications can only be created using the CDS. They can’t connect to any other data sources so this becomes a limitation of model driven applications. However, a canvas application can connect to CDS. So if the CDS was used as a data source you can create a mix of canvas and model apps.
From my experience in the CDS I tend to create modal apps for back end users, users that will be desk based or administrative parts to applications. I would then supplement with canvas applications.
I will use another car example to demonstrate this.
A car company wants an application to manage the stock of their forecourt. I would create this application in the CDS and not SharePoint as I could create a modal-app for the users inside the car showroom. However, a canvas app could be created to capture pictures of the vehicles or be used to find details of a particular car on the forecourt. All of this data would be stored against the same datasource.
|Overview of Modal-driven applications||https://docs.microsoft.com/en-us/powerapps/maker/model-driven-apps/model-driven-app-overview|
The CDS is where all the customisations to your business solutions exist. The majority of the customisations are done against the entity and not in a model-driven app. A model-driven app is the structure of an application but it doesn’t really contain the customisations that you create. For example, if you want to create an input form for an entity this would be done against the entity and not in the modal app.
In SharePoint when you make a customisation for an app this would usually be done in the Canvas App. For example, logic that would show and hide fields based on another fields value. In the CDS you could create a business rule to accomplish this and this business rule could be re-used or scoped to different levels.
Another benefit of the CDS is that if you have two applications that utilise the same entity then you can simply reuse the screen that you created in the second application in a number of minuets.
I want to make this clear that SharePoint still has it’s place for being used as a data source for the Power Platform. However, I think that a decision should be made based on the benefits that the CDS can offer over SharePoint on an application by application basis.
It would be great to see the reasons why you would use SharePoint over the CDS from a functionality point of view and not cost.