Server-side logic in Common Data Service for Apps

Common Data Service for Apps has been launched and this is what XRM developers have been waiting for since xRM 2011.  With these new capabilities, PowerApps (v2) and the Common Data Service for Apps now power Dynamics 365 for Sales, Marketing, Customer Service and Talent. PowerApps P2 officially becomes the new platform SKUand will be called Canvas Apps, moving away from being a admin and maker focused plan to becoming THE plan for users of stand-alone model driven apps.

If you’re already a Dynamics 365 user, this means as soon as your Dynamics 365 apps are upgraded to 9.0, your data will be available in Common Data Service for Apps. Existing Dynamics 365 environments will show up in PowerApps, assuming you have the right access permissions. Dynamics 365 customizers will start using PowerApps to customize Dynamics 365 (no worries: Solution Explorer and other familiar editors remain available), and if you already know how to customize Dynamics 365 then you already know how to build model-driven apps!

By using the concept of XRM of 2011, this makes Common Data Service for Apps instantly Enterprise Ready — server-side logic and here are several types that are supported:

Declarative logic, that does not require writing any code. In this category Common Data Service for Apps provides:

  1. Business Process Flows – BPFs are a way to describe business processes as a sequence of stages with specific steps in each stage. Use a business process flow when you want users to move through the same stages and follow the same steps to interact with a customer for example. BPF allows modelling of sophisticated processes through capabilities like enforcing certain conditions are met before advancing to the next stage, or dynamically switching stages depending on input from prior stages.
  2. Workflows – CDS for Apps support synchronous (“real-time”) and asynchronous workflows. Custom workflows can be triggered on a wide range of events such as creation of a new record, BPFchanges to a record, deletion, etc. The workflow itself can then take one or multiple actions like modifying fields, creating new records or even preventing the operation that triggered the workflow from completing.
  3. Business rules – Ensuring accurate data, regardless of the app that created or edit it is important to maintain data consistency, and ensure apps and analytics continue to operate as expected. Business Rules provide a nice graphical UI for defining these rules and actions that will be executed sychronously when a record is created/updated.
  4. Calculated and roll up fields – entities can now include calculations and roll ups of related records to allow you to create Excel like formulas on both number and text-based fields. This enables calculations to be defined once, ensuring a consistent value is used across all your apps.

In addition to the graphical, declarative editors, CDS for Apps now also supports pro-dev extensibility:

  1. Code plugins – Plugins define custom business logic through .NET that can be triggered by a wide range of events in the platform. They provide the ultimate in fine-grain extensibility for pro-devs.
  2. Custom Workflow activities – Similar to plugins, these can be written in C# and allow definition of custom activities that can be triggered as part of a workflow to execute custom business logic not easily expressed declaratively.

What do these changes mean for your existing canvas apps (Power Apps v1) and any new canvas apps (Power Apps v1) that you can build on the Common Data Service for Apps?

New canvas apps (Power Apps v1) will continue to be able to use the Common Data Business Rule Designer.pngService for Apps as a data source and will also gain some new and much requested capabilities. The most exciting being the ability to use the above mentioned server-side logic in your canvas apps. Business Process Flows are not yet supported in Canvas apps (Power Apps v1), but all the other types of entity scoped server side logic can be used with Canvas apps (Power Apps v1).

For existing canvas apps (Power Apps v1) currently using the Common Data Service there will be some manual upgrade work required to enable the new functionality for those instances, you will begin receiving notifications starting in April with details. No worries, your existing CDS instances will continue to work, new CDS for Apps instances will already have all the new capabilities enabled.BPF

How to Get the List of Users Inside an Access Team

Many of you have probably tried to use the Access Teams feature of Dynamics 365 Customer Engagement (D365CE) to provide special access for specific records but one of the rather odd requirements that was asked of our project recently was to query the list of Access Team users on an Account Record and Pre-Filter the Owner field to limit the Lookup only to the specific users in the Access Team list.  Pre-Filtering is nothing new in D365CE so I went ahead and added a Pre-Filter that would probably look like something like this:

var filter = Some Fetch XML Filter
Ownercontrol.addPreSearch(function () {
  Ownercontrol.addCustomFilter(filter);
});

I went ahead and opened Advanced Find and to my surprise I didn’t find any Entity named Access Team or some name that was connected to Access Team. I opened the Users Entity to search and to my dismay I didn’t find a single field that pointed to Access Team or Account where the Access Team was enabled. So I went and searched the fields in Account and saw a field named preferredsystemuserid. I thought, this is it! But when I tried to query a value using XrmToolBox’s FetchXML Builder by Jonas Rapp of Innofactor Sweden, I was disappointed to find out that the field wasn’t even displayed on the results view.

So I tried so search until I noticed a reference to some entity called the principalobjectaccess and found that this entity is quite useful in help us out of our problem.

The results of this Fetch XML statement will return a list of System User Guids which I can now use to populate my Pre-Filter query.  I passed this Fetch XML query through D365CI’s Web API and got the results. If you want to know how to pass Fetch XML using the Web API you can read about it HERE or you can use Jason Lattimer’s CRM Rest Builder to do the heavy lifting for you. After you have retrieved the results you can pass the results to the data parameter and create the Pre-Filter as follows:

filter = "";
filter += "";
var index = 0;
for (index = 0; index < data.value.length; index++) {
    filter += "" + data.value[index].user_x002e_systemuserid + "";
}
filter += "";
Ownercontrol.addPreSearch(function () {
 Ownercontrol.addCustomFilter(filter);
});

 

How to Do Complicated Queries in Dynamics 365 Customer Engagement REST Web API using Fetch XML

There are two ways to do this the first one is to use the fetchXml keyword as shown below or use Jason Lattimer’s CRM Query Builder.

var fetchXML = "<fetch>";
fetchXML += " <entity name="account">";
fetchXML += " <filter>";
fetchXML += " <condition attribute="accountid" operator="eq" value="f7b4ef42-250c-4a53-a8c5-6adfce984c93" />";
fetchXML += " </filter>";
fetchXML += " <link-entity name="principalobjectaccess" from="objectid" to="accountid" link-type="inner" alias="poa">";
fetchXML += " <attribute name="objectid" alias="objectid" />";
fetchXML += " <link-entity name="team" from="teamid" to="principalid" link-type="inner" >";
fetchXML += " <link-entity name="teammembership" from="teamid" to="teamid" link-type="inner" intersect="true" >";
fetchXML += " <link-entity name="systemuser" from="systemuserid" to="systemuserid" link-type="inner" alias="user" >";
fetchXML += " <attribute name="systemuserid" />";
fetchXML += " </link-entity>";
fetchXML += " </link-entity>";
fetchXML += " </link-entity>";
fetchXML += " </link-entity>";
fetchXML += " </entity>";
fetchXML += "</fetch>";
 var encodedFetch = encodeURI(fetchXML); //encode fetchXML
 var req = new XMLHttpRequest();
 req.open("GET", Xrm.Page.context.getClientUrl() + "/api/data.8.2/accounts?fetchXml=" + encodedFetch, true);
 req.setRequestHeader("Accept", "application/json");
 req.setRequestHeader("Content-Type", "application/json; charset=utf-8");
 req.setRequestHeader("OData-MaxVersion", "4.0");
 req.setRequestHeader("OData-Version", "4.0");
 req.setRequestHeader("Prefer", "odata.include-annotations=\"*\"");
 req.onreadystatechange = function () {
 if (this.readyState == 4 /* complete */) {
     req.onreadystatechange = null;
     if (this.status == 200) {
       var data = JSON.parse(this.response)
       successCallback(data);
     }
     else {
       errorCallback(handler);
     }
   }
 };
 req.send();

Customer Engagement Hubs

If you have tried out the NEW Dynamics 365 Customer Engagement v9, you will notice that they have added “Hubs” to the existing Apps. Currently, we have the Sales Hub, Customer Service Hub, Project Resource Hub, and Field Resource Hub.

Hubs

If you actually click on one of the Hubs it will bring up the Dynamics 365 App which is similar to its none-Hub counterpart except for one subtle change — you can now see a side menu which looks and behaves like the Windows 10 Creators Update side menu.

Hubs2

I think Microsoft did a good job of bringing in some of the positive UI Elements of Windows 10 into Dynamics 365 Customer Engagement v9. Having similar UI Elements will make users adopt quickly when they shift from using Windows 10 to Office 365 to Dynamics 365.

What do you think?