I have had an opportunity recently to start getting to grips with the wonderful world of PowerBI. For those who have walked the tightrope between Excel and SQL Server Reporting Service (SSRS) Reports, PowerBI appears to be the tool with these individuals in mind. It enables you to leverage existing Excel knowledge (through PowerQuery or Excel-based formulas/calculations), whilst also offering a number of easy to setup Visualisations, that are not too dissimilar to the charts, maps and other objects that can be setup on a .rdl report. What’s also good to know, from a Dynamics CRM/365 for Enterprise (D365E) point of view, is that you can very quickly hook up your CRM data to a PowerBI dashboard/report. In addition to this, integrating with other data sources – such as SQL, JSON or flat file sources – or even with completely different application systems is possible (even with SalesForce – shock, horror!). In the days of increasing need for tight integration between a dazzling array of different application and database systems, PowerBI gives you a broad framework to achieve any reporting goal you may have in mind. Having said that, it is still rough around the edges and in need of some further development before it, arguably, becomes the de facto tool to use. For example, I have found some of the formatting and design options available to be rather basic and light-years behind what is possible with SSRS or even Excel. There are also some features missing that are somewhat baffling, such as the ability to send out dashboards/reports via email on a predefined schedule. I would hope that we see increasing attention towards PowerBI in the months and years ahead in order to bring the very best of features from these more traditional applications but exposed in a non-daunting and wholly accessible way.

As referenced above, getting set up with your Online CRM/D365E data is incredibly straightforward via the inbuilt Dynamics 365 connector “wizard” – simply login into your online organisation, specify the entity data that you want to work with and PowerBi will push this data into a table for you, enabling you to start building your report in seconds. The connector “wizard” is suited to most typical data retrieval scenarios, providing a GUI interface to visualise the entity data within your CRM/D365E instance and the ability to put together related entities and return them as part of your query. Before you start using it, however, I would highlight the following:

  • The OData feed is rather indiscriminate in its retrieval – all records from an entity will be returned. Some pre-filtering will occur based on CRM’s/D365E’s security model (e.g. if the account you log in as has Business Unit level Read privilege on the Lead entity, only records in the accounts Business Unit will be returned), but typically it will be System Administrators who set up a PowerBI Dashboard; therefore meaning you have to deal with a lot of records being returned into PowerBI. Given that the two different PowerBI plans have limitations in regards to record retrieval, this could cause problems if you are working with large CRM datasets.
  • Tied in with the above, because you have no way via the “wizard” interface to specify record retrievals, you cannot take advantage of filtering your data based on certain attributes or even take advantage of some of the native functionality within CRM to aggregate your data. Whilst PowerBI is certainly more than capable of doing this, relatively n00bish users may find this an unwelcome barrier that hinders adoption.
  • Lookup and Option Set attributes are returned as a special data type of Record – with the underlying properties of the related record (GUID, display name etc.) stored within this sub-record. Having the data stored in this manner causes additional administrative effort on the PowerBI side, as you will need to figure out how to access the underlying properties of this PowerBi data type.

Fortunately, if you are inclined towards building very specific and focused queries that you can execute against your Online CRM/D365E, there is a way – and the best thing is, we get to use something that has been recently introduced into CRM as well 🙂

The Web API to the rescue!

The Web API was introduced in Dynamics CRM 2016, which implements version 4 of the Open Data (OData) Protocol, and will eventually replace the traditional means that developers would use to access CRM via web services (namely, the Organization service and the old OData service). CRM Developers will need to start becoming increasingly familiar with the Web API in the years ahead, and no doubt a lot of work will need to be done updating existing coding to look at the new Web API.

Because the Web API is a web service, PowerBi can connect to it via the Web connector. By querying the Web API, you have access to all of the messages that are exposed to get data from CRM – Retrieve, Retrieve Multiple and Predefined Query – with multiple options available to use in terms of how you return, filter and aggregate your data. Results will be returned in JSON format, so there will be some additional work that needs to be done to get the data into an accessible format. This post will now take a look at what you need to do in order to return data based on a FetchXML query, as well as (hopefully!) providing a useful code snippet that you can adapt to your environment.

Before starting, ensure that you have installed the CRM Rest Builder Managed Solution within your CRM development environment. This tool allows you to quickly generate code snippets in JScript that perform web service calls into CRM/D365E and is a massive help in a number of different ways. A big shout out and thanks to Jason Lattimer for the work he has done on this.

  1. To begin, you need a FetchXML query that returns the data you need. This can be written manually or generated automatically via Advanced Find. In this example, we are going to use the following snippet that queries the Case entity, that will return 7 sample data records from CRM:
<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
  <entity name="incident">
    <attribute name="title" />
    <attribute name="ticketnumber" />
    <attribute name="createdon" />
    <attribute name="incidentid" />
    <attribute name="caseorigincode" />
    <attribute name="customerid" />
    <order attribute="ticketnumber" descending="false" />
    <filter type="and">
      <condition attribute="prioritycode" operator="eq" value="1" />
  1. Next, we need to generate the URL that will be used to query the Web API endpoint. There are two challenges here – the first being that the FetchXML query needs to be included in the URL and that it needs to be encoded so that it is a valid URL. The start of the URL is fairly straightforward to put together – it’s just your CRM organisation URL, in the following format:

https://<Organisation Name>.<Region Code>.dynamics.com

So if your organisation name is crmchap and your CRM tenant is based in the EMEA region, then the URL would be as follows:


The rest of the URL can be obtained from the CRM Rest Builder. Open the Managed Solution, navigating to the Configuration page. It will look something like this:


Update the page so that the Action is set to Predefined Query. Ensure that the Primary Entity is set to Incident (always something you have to remember when working with the Case entity 🙂 ) and then copy and paste the FetchXML query into the box below. The window should look similar to the below once ready:

2Press Create Request to put together the code snippet. On Line 2, you will see the following piece of code:

req.open("GET", Xrm.Page.context.getClientUrl() + "/api/data/v8.0/incidents?fetchXml=%3Cfetch%20version%3D%221.0%22%20output-format%3D%22xml-platform%22%20mapping%3D%22logical%22%20distinct%3D%22false%22%3E%3Centity%20name%3D%22incident%22%3E%3Cattribute%20name%3D%22title%22%20%2F%3E%3Cattribute%20name%3D%22ticketnumber%22%20%2F%3E%3Cattribute%20name%3D%22createdon%22%20%2F%3E%3Cattribute%20name%3D%22incidentid%22%20%2F%3E%3Cattribute%20name%3D%22caseorigincode%22%20%2F%3E%3Cattribute%20name%3D%22description%22%20%2F%3E%3Cattribute%20name%3D%22customerid%22%20%2F%3E%3Corder%20attribute%3D%22ticketnumber%22%20descending%3D%22false%22%20%2F%3E%3Cfilter%20type%3D%22and%22%3E%3Ccondition%20attribute%3D%22prioritycode%22%20operator%3D%22eq%22%20value%3D%221%22%20%2F%3E%3C%2Ffilter%3E%3C%2Fentity%3E%3C%2Ffetch%3E"

The bit we are interested in is the string value after the Xrm.Page.context.getClientUrl() function, which will need to be appended to our CRM URL. So based on the above, our URL to use with PowerBI would be as follows:


A bit of a mouthful I agree!

  1. Now that we have the URL, we can connect up to CRM within PowerBI. Create or Open a new PBIX file and select Get Data -> Web:


  1. On the From Web window, copy and paste the URL we’ve built and press OK. You will be prompted to log into your CRM organisation; select Organisational account and log in as you would normally via the Office 365 login page. Once logged in, the data will be retrieved and the Query Editor will open, displaying something similar to the below:4
  2. Some additional work is required in order to get our data into a standard, tabular format. In addition, the data at the moment is returning the underlying Option Set and Lookup values from the Incident entity, as opposed to the Display Name; not good from a reporting point of view:

5We, therefore, need to modify the underlying PowerQuery in order to achieve the following:

Right click on Query1 and select Advanced Editor to open the underlying PowerQuery text. Delete everything here and then copy and paste the following into the window:

    //Get the CRM data, including the Formatted Values as part of the returned data
    Source = Json.Document(Web.Contents("https://crmchap.crm4.dynamics.com/api/data/v8.0/incidents?fetchXml=%3Cfetch%20version%3D%221.0%22%20output-format%3D%22xml-platform%22%20mapping%3D%22logical%22%20distinct%3D%22false%22%3E%3Centity%20name%3D%22incident%22%3E%3Cattribute%20name%3D%22title%22%20%2F%3E%3Cattribute%20name%3D%22ticketnumber%22%20%2F%3E%3Cattribute%20name%3D%22createdon%22%20%2F%3E%3Cattribute%20name%3D%22incidentid%22%20%2F%3E%3Cattribute%20name%3D%22caseorigincode%22%20%2F%3E%3Cattribute%20name%3D%22customerid%22%20%2F%3E%3Corder%20attribute%3D%22ticketnumber%22%20descending%3D%22false%22%20%2F%3E%3Cfilter%20type%3D%22and%22%3E%3Ccondition%20attribute%3D%22prioritycode%22%20operator%3D%22eq%22%20value%3D%221%22%20%2F%3E%3C%2Ffilter%3E%3C%2Fentity%3E%3C%2Ffetch%3E", [Headers=[#"Prefer"="odata.include-annotations=""OData.Community.Display.V1.FormattedValue"""]])),
    //Get the underlying list of records returned
    values = Source[value],
    //Create a new table with one column, populated with the values list of records
    #"Table from List" = Table.FromList(values, Splitter.SplitByNothing(), null, null, ExtraValues.Error),
    //Query will error if no results, therefore use an if statement to build an empty table with the correct column headers
    Expand = if List.IsEmpty(values) then #table({"title", "ticketnumber", "createdon", "incidentid", "caseorigincode", "_customerid_value@OData.Community.Display.V1.FormattedValue"}, {"title", "ticketnumber", "createdon", "incidentid", "caseorigincode", "_customerid_value@OData.Community.Display.V1.FormattedValue"}) else Table.ExpandRecordColumn(#"Table from List", "Column1", {"title", "ticketnumber", "createdon", "incidentid", "caseorigincode", "_customerid_value@OData.Community.Display.V1.FormattedValue"}, {"title", "ticketnumber", "createdon", "incidentid", "caseorigincode", "_customerid_value@OData.Community.Display.V1.FormattedValue"}),
    //For some reason, if there are no results, then the empty table contains error records - so need to specifically remove them
    #"Removed Errors" = Table.RemoveRowsWithErrors(Expand),
    //Finally, rename the _customerid_value field
    #"Renamed Columns" = Table.RenameColumns(#"Removed Errors",{{"_customerid_value@OData.Community.Display.V1.FormattedValue", "Customer Name"}})

   #"Renamed Columns"

The comments should hopefully explain what the code is doing, but to summarise: the PowerQuery is parsing the JSON data into a tabular format, using the returned data to build column headers, and then renaming the _customerid_value field to match our requirements. There is also a logic statement in there to check if we actually have any data; and if not, then build an empty table (since JSON does not return anything that we can use if 0 records are returned).

With our updated PowerQuery, our result set should look similar to the below:


Nice, presentable, filtered and exactly what we need to start building our PowerBI report! 🙂

Conclusions or Wot I Think

Whilst I’ll be the first to admit the above example is rather code-heavy and would require significant tinkering to suit specific scenarios, I would argue that the approach demonstrated adheres most closely to some of the common rules when it comes to querying data for reports:

  • Only return the columns you need
  • Filter your data to reduce the number of results returned
  • Ensure that your report-side columns are giving presentable database column values

This approach is the only one adheres most closely to the above and, therefore, I feel that the extra effort is warranted; particularly when it means that those who are more familiar with CRM can stick to the tools they know best. As the default Dynamics 365 connector uses the Organization Data service, I would imagine that eventually this will be updated to use the new Web API instead. I hope that when this happens, we can begin to achieve all of the above via the PowerBI interface, as opposed to resorting to code.

Your business has decided it wants to implement Dynamics CRM/Dynamics 365 for Enterprise (D365E). That’s great news! Your next crucial decision will be what approach you take in implementing the system, in particular, who you involve as part of the planning, designing and building phases. Businesses that lack individuals with dedicated, technical know-how will often need to engage the services of a Microsoft Partner or consultant to assist with some or all of this. On the flip-side, if you have a capable and technically competent team that is able to get up and running with how to use the system quickly, then there is a case to be made for deploying CRM/D365E as an internally led project.

In this week’s blog post, I will evaluate the 3 potential routes open to you if you are looking to implement CRM/D365E within your business, looking at it purely from a small to medium size business’ perspective. For enterprise-size deployments, then it really does make practical sense to go down the Partner route, as this will ensure you can leverage the maximum level of expertise, as well as take advantage of resources/price breaks that can be leveraged via this route.

Microsoft Partner

It’s hard to argue some of the clear and immediate benefits of involving a Microsoft Partner as part of rolling out CRM/D365E. With access to resources like PartnerSource/the Dynamics Learning Portal and, depending on the partner’s relationship with Microsoft, there is a lot of expertise that a Partner can bring to the table. Most Partners live and breathe the product, with a lot of passion backing this up, so it is a great way to get individuals involved in your system deployment who know the system inside and out. No need to worry as well if your CRM/D365E “expert” is ill/away or if your consultant is unavailable, as you can pick up the phone and speak to anyone there and guarantee that there will be someone there to help. This is definitely very attractive if your business cannot afford the overhead of a dedicated  resource and gives you peace of mind that your system will always have someone there who can make the changes you need.

The downside? None of this comes cheap, unfortunately. Depending on the size and nature of your deployment, you could be looking at anything in the region of £20,000 – £120,000 or upwards for a deployment or migration away from an existing system onto CRM/D365E. Most partners will have specific change control procedures in place to manage any alterations to the original scope of work. If you’re a small business or in a market where your internal processes are subject to change at a drop of a hat, then that CRM/D365E deployment that your originally thought would cost £50,000 has now almost doubled as a result. It can also be very difficult to find a partner that aligns with your vision and objectives for the deployment. You want to make sure that your new system is a great success and that everyone in the business is shouting off the rooftops about it, but is this something that your chosen partner ultimately cares about? Or is their focus more geared towards, for example, hitting their required revenue goal and/or deployed seats in order to maintain their CRM Partner Competency? You have no doubt done your due diligence on which CRM system you want for your business; this should also be applied to any Microsoft Partners who are in the frame for helping to deliver your CRM/D365E project. You should focus on their track record, customer testimonials and, ultimately, your gut feeling when meeting them for the first time.

Independent CRM Consultant/Developer

You can potentially get a consultant on board that suits the level of expertise that you are looking for: if, for example, you anticipate using mostly out of the box elements of the system, then it may make practical financial sense to get on board a fairly junior level consultant; on the flip-side, if you anticipate needing to integrate with other systems within your business, then a consultant with development experience may be a better choice. You may also be able to secure more “face-to-face” time with an independent consultant or ensure that a set number of day(s) are spent within your business as part of the project, something which you may not always be able to guarantee going down the partner route.

Having just one consultant in charge of your entire deployment can prove to be incredibly risky for a business. For example, if the Consultant falls ills or is otherwise incapacitated, your entire project could be held up for long periods, costing the business money in the process. You may also find yourself in a situation where a Consultant is deliberately attempting to stretch out the time and length of the deployment, for selfish reasons. Businesses will also need to think carefully about their plans once a consultant/developer has finished the project. Who will be responsible for managing the CRM/D365E system? Who will carry out end-user training? These and other questions are ones you would need to have solid answers for if you’re are going down the independent consultant/developer route.

Internal Project

Speaking from experience, if you already work heavily with a number of “Microsoft stack” technologies within your business (SQL Server, C# etc.), then you should have very little difficulty in getting to grasp with CRM/D365E; which makes the internal project route a potentially attractive option. If you do get stuck at all, then CRM/D365E training courses are plentiful, and you could find yourself paying as little as 10-20% of what a fixed cost deployment from a Microsoft Partner comes back at, for what would be training for 2-3 individuals on the Microsoft exam curriculum (including the developer track). This assumes, of course, that your business has individuals within it who already have experience that you can potentially use as part of a systems rollout. These individuals may already, in addition, be well placed to understanding what the business needs and may already have a lot of passion around delivering solutions and service that meets and exceeds the expectation of colleagues. Who is better, therefore, to potentially spearhead and implement CRM/D365E within your business? There is also the risk that you potentially involve people within your project who may not fully understand or get how your business operates. Let’s face it, at the end of the day, you know your business better than anyone. You can avoid a situation where you are having to do additional work internally just to create process maps, documents etc. just so that someone else coming into your business cold can understand just what is that you do. And if there is any misunderstanding or confusion with this, then your project could get set back considerably and waste additional resource as a result.

Going down the internal route does present some major challenges and difficulties, which need to be mitigated from the outset in order to ensure the project is delivered on budget and on time. Getting a project manager involved from the outset (assuming your business has such a person available) is one way in which you can prevent against this, but be prepared for lots of frustrating moments. Getting to grips with learning CRM/D365E, even for those who have a good knowledge of the underlying technology, can be a major curve and you will need to be prepared to fail more than you succeed at first. You also need to carefully review and ensure that you have a fallback in case things go catastrophically wrong – if you go down the Online route, then this is provided for to an extent via Microsoft Support; but if you are adopting an on-premise version of CRM/D365E, then such support will be non-existent unless you involve a Microsoft partner.


Each business is different, so you can never make a number of arbitrary assumptions in respect to business size, turnover etc. when advising on the best route to go when rolling out a system like CRM/D365E. So, to summarise, my thoughts on this are:

  • If your business does not have any existing, internal IT technical expertise and a very fixed/focused line of business, then the Partner route is definitely the way to go
  • Ditto above, but if your business is subject to fluctuations, then a blended approach of getting a consultant on board for a fixed period and end-user training in how to use and customise CRM/D365E means that you get that immediate technical expertise, but ensure that you are not reliant long-term on unnecessary overheads
  • If you a small to medium business with already a lot of technical expertise, a tight budget, flexible deadlines and a business model that is subject to sudden changes, then the self-taught/internal project route is ideal and guaranteed to ensure there is sufficient passion and drive within your organisation to make your deployment a success.
  • Ditto above, but if you have a deadline and your business is highly specialised, then getting a consultant and/or Partner involved can really speed things along. Just ensure that you have a fixed budget in place and beware of scope creep or massive changes in requirements.

I hope that my analysis has been fair and balanced, and proves useful if you are currently contemplating how to go about your CRM/D365E deployment. It would be great to hear other people’s views and thoughts on the best approach in the comments below.

An oft-requested requirement as part of any Dynamics CRM/Dynamics 365 for Enterprise (D365E) deployment is a level of integration with another application system. In some of these cases, this will involve pulling through external web pages and passing them form-level attribute values, to load an external systems report, record page etc. From a CRM/D365E point of view, this can be very straightforwardly achieved thanks to some of the functionality provided as part of the Xrm.Page object model. For example. let’s assume that you have an IFrame control on your form and you wanted to load an ASP.NET web page, passing the ID of the record as a query parameter in the URL. Setup your IFrame on your form, with a random URL and set to hidden. Then, a JScript function like this on the OnLoad event would get the job done for you:

function loadIFrame() {

    //Get the current record ID

    var entityID = Xrm.Page.data.entity.getId();

    //Replace { & } with their appropriate URL counterparts in entityID

    entityID = entityID.replace("{", "%7b");
    entityID = entityID.replace("}", "%7d");

    //Create the URL

    var url = "http://myexternalwebpage.com/MyAspPage.aspx?id=" + entityID;

    //Then, update the IFrame with the new URL and make it visible on the form


What helps with the above is that there are well-documented code samples that assists when putting together this example, so you can be confident that the solution will work and is fully supported.

Things get a little more complicated once we are operating outside the standard CRM/D365E environment. Assume that instead of displaying this IFrame control on a form, it needs to be displayed as part of an Entity Form in Adxstudio/CRM Portals. Here is where the head scratching can commence in earnest, and you need to look at getting your hand’s dirty writing custom code to achieve your requirements. There a few hurdles to overcome in the first instance:

  • How do you access attribute values from an Entity Form, such as a record ID?
  • Once you are able to access the attribute value, how to you set this up on your Entity Form?
  • How do you embed an IFrame within an Entity Form?

Let’s take a look at one approach to the above, working on the same basis as above – an external URL that we pass the record ID to, from within an Entity Form Web Page. Things may get a bit more difficult if you need to access other entity attribute values, which may require some kind of trickery with Liquid Templates to achieve successfully.

Accessing Entity Form Record ID

When your Entity Form page is loaded on your Portal, there are a number of properties regarding the record that are exposed on the underlying web page – the name of the entity, the record ID, Status and Status Reason values. These can be accessed via a div element on the page, which can be viewed within the DOM Explorer as part of a Web Browsers developer tools (in the below example, Internet Explorer is used):


The id of the div class will always be the same, except for the value in the middle, which is the GUID for the Entity Form record within CRM/D365E, but without the dashes. So you don’t need to necessarily go into the DOM to get this value; as a time-saving mechanism, simply export your Entity Form record into Excel and view the first hidden column to obtain this value.

Suffice to say, because we know that this value is accessible when our Portal page loads, we can look at programmatically accessing this via a JScript function. The following snippet will do the trick:

var recordID = document.getElementById('EntityFormControl_31c41a020771e61180e83863bb350f28_EntityFormView_EntityID').value;

Now that we have a means of accessing the attribute value, our options in terms of what we can do with it greatly increase 🙂

Executing Entity Form Custom JScript Functions

There are two ways you can place custom JScript on your portal page – you can either place your functions within the Custom JavaScript field, located on the Entity Form form within CRM:


Functions will be added to the bottom of your Web Page when loaded, meaning they can be freely accessed after the page has loaded. The second way, which leads us nicely onto the next section, is to wrap your JScript function as a custom HTML snippet on the Web Pages Copy (HTML) field.

Embedding an IFrame on your Web Page

All Web Pages in Adxstudio/Portals – irrespective of what other content the page is loading – contain a Copy (HTML) field. This enables you to write your own bespoke text or other HTML content that is displayed on the Web Page. In the case of an Entity Form Web Page, then the content will be displayed just below the Entity Form. Thanks to the ability to access and write our own custom HTML code for this, options for bespoke development are greatly increased – simply click the Source button to switch to the underlying HTML editor:


Then, using a combination of the snippet we used earlier and utilising the <iframe> HTML tag, we can place the following in our Copy (HTML) to do the lot for us – get our record ID, pass it to an external web page and then load this within an IFrame:

        function getEntityID() {
            var url = "http://myexternalwebpage.com/MyAspPage.aspx?id=";
            var entityID = document.getElementById('EntityFormControl_31c41a020771e61180e83863bb350f28_EntityFormView_EntityID').value;
            var iframeSrc = document.getElementById('myiframe').src;

            if (iframeSrc != url + "%7b" + entityID + "%7d") {

                setTimeout(function () {
                    document.getElementById('myiframe').src = url + "%7b" + entityID + "%7d";
                }, 2000);
<h1>My IFrame</h1>
    <iframe width="725" height="250" id="myiframe" src="" onload="getEntityID();"></iframe>

The reason why setTimeout is used is to ensure that the entity form <div> class loads correctly, as this is one of the last things that Adxstudio/Portals loads last on the page. For obvious reasons, if this hasn’t loaded, then our JScript function will error. Putting this aside, however, the above solution gets us to where we want to be and means that we can achieve the same outcome as the CRM/D365E example demonstrated at the start of this post 🙂

Conclusions or Wot I Think

Adxstudio/Portals presents some interesting and different learning opportunities, both given its genesis as a separate product to its gradual integration as part of the CRM/D365E family. This can often mean that you have to abandon your base assumptions and ways of thinking when it comes to CRM/D365E development, and instead look at things from a more general approach. I would hope that, in time, we will begin to see the gradual introduction of common XRM object models within CRM Portals, as it is crucially important that there is a unified approach when developing Portal extensions in the future and that we are not in the situation where unsupported code becomes rampant across different Portal deployments. This latter concern would be my chief worry with the examples provided in this post, as there is currently no clear way of determining whether the approach taken is supported or considered “best practice” from an Adxstudio/Portal perspective. I would be interested in hearing from anyone in the comments below if they have any thoughts or alternative approaches that they would recommend to achieve the above requirement.

Last week has been a particularly busy one for all things Microsoft concerned. Future Decoded 2016 came and went, with a whole range of interesting announcements and presentations from those within the industry. And, of course, we saw the release of Dynamics 365 for Enterprise on Tuesday, an event which I discussed more closely as part of last week’s blog post. There’s a lot about Dynamics 365 which is going to take some time to fully understand, and also a lot of features which are not yet fully available. I have been hearing rumours that there will be a December update, targeted at existing CRM Online users who wish to make the jump across, that will unwrap a couple of features that are currently disabled within Dynamics 365. Chief among these looks to be the App Builder and also what looks like some kind of sitemap editor tool! :O In the meantime, there a lot of changes that need digesting, and I wanted to focus this week on a particular group of new features/changes relating to Processes. For the uninitiated, processes is a broad term to describe a group of different Dynamics 365 for Enterprise (D365E) components that can be created within the system- namely, Workflows, Dialogs, Actions, Business Process Flows and Business Rules. Whilst not all of these have received attention as part of the new release, the ones that have definitely look to be in a much more enhanced and polished position compared to Dynamics CRM 2016 Update 1. Let’s take a look at some of these changes in more detail:

Process Designer

The introduction of the Process Designer for Business Rules, Business Process Flows and Task Flows is perhaps the most noticeable and welcome enhancement to processes. Now, instead of linearly attempting to visualise how your processes operate, you can very quickly grasp how they look via the visual designer. What’s more, you have the ability to drag and drop your components quickly and easily, re-ordering them accordingly and seeing clearly how each step flows into the other:


Out with the old…


…and in with the new!

What’s also welcoming about this is that, for those who prefer a more “old school” approach to seeing how a Business Rule is structured, the Text View window provides a means of accommodating this. A nice and welcome touch!

Business Rule Recommendations

I really like this next new feature 🙂 When it comes to data inputting, one of the major challenges you face is ensuring that the data is entered correctly. These problems can be compounded in situations where data needs to conform to specific rules – for example, if Field A and Field B equal ‘ABC’, then set Field C to ‘DEF’; otherwise, set to ‘GHI’. The common solution to this problem in the past is to look at programmatic means of ensuring data is entered correctly – generally via a Business Rule or a form-level JScript function. Whilst these generally are effective at addressing the problem, they could be prone to errors and can be seen as being too absolute a solution, that doesn’t address what could be an underlying problem within a business; namely, a lack of understanding of business processes and how things should be done.

The new Recommendation Action as part of Business Rules would appear to seek towards addressing this gap, by providing an unobtrusive way of alerting users that there is a problem with the data they have entered onto a form and giving them an opportunity to correct their mistake. In the process of doing this, you can provide contextual information that explains why the data needs to be changed – increasing transparency and understanding from end users of the application. Setting them up is very straight-forward – just setup your Condition and then you can drag and drop the new Recommendation component onto the designer screen. To see how this works in practice, let’s look at an example on the Contact form – we want to ensure that if the Spouse/Partner Name field contains a value, that the user is prompted to update the Marital Status field accordingly. First, we build our condition as we would normally in a Business Rule:


Next, we hook up our Recommendation component and configure it accordingly – setting the Recommendation properties and then our Set Field Value action

4 5

Your Business Rule should look like the below when ready:


When activated and then, upon navigation to the Contact form, we can see it in action; when the Spouse/Partner Name field is changed, a blue exclamation mark appears next to the Marital Status field. Once clicked, we get some guidance information and the ability to update the field:


Et voila! The introduction of this new feature is a welcome surprise on my part. One limitation currently is that only one type of Action is supported with a Recommendation – Set Field Value. Here’s hoping that this is expanded as part of a future version of D365E to include additional Actions.

Validation for Business Rules

Previously, when building a Business Rule, the only way you could effectively determine that there were logic problems in your Business Rules is by activating them and testing them yourself on the form level. This is a potentially torturous process that could very well result in errors seeping through unintentionally. Now, as part of the new visual designer, the logic can be validated at any point and is also validated upon save. If unsuccessful, you are alerted to this fact and given some guidance on what is wrong so you can look at fixing the issue:

8 9

Hopefully, having this built in now will help avoid some of the most obvious mistakes that can sometimes seep through when building a Business Rule.


Often, when you are attempting to document a system, you will want to include some kind of pictorial representation of the system – a process map, diagram or something similar. Now, with the updates made to Business Rules and Business Process Flows, you have the ability to obtain screenshot of the designer window – all through the click of the Snapshot button:




Pressing this will download a .png image of the Process, that you can very easily include as part of existing documentation relating to your system:


This is a very handy new feature that will no doubt save a lot of time in the future! One thing to remember is that, if you wish to include all Components underneath the Details section, then you will need to expand it first before pressing the Snapshot button.

Task Flows

Having come out of Preview from Dynamics CRM 2016 Update 1, Tasks Flows are still very much in their infancy and something which I am still trying to get my head around fully. My understanding is that they are essentially a combination of Workflows and Dialogs, but designed solely for the Dynamics CRM/365 for Tablets Mobile Application. From the mobile app, they are accessible from the new Summary area that appears when the app first launches (and where the heavily touted Relationship Assistant will reside once released). Taking the example After Meeting Task Flow, we can see how this looks in the mobile app. First, we launch the app and navigate to Summary area:


From there, we can see along the bottom of the tab all available Task Flows that can be launched based on the clipboard task list icon:

13Clicking this then launches a New Appointment record screen and then the first Page of the Task Flow which, once completed, will then execute the custom logic in the background:


Task Flows look very versatile and powerful, but I think will require some closer testing and experience before I’m able to comment further… :S

All in all, Processes seem to have received a lot of love and attention as part of the initial Dynamics 365 for Enterprise release. Microsoft has set the bar at the right level in creating the process designer, and the hope is that this is eventually rolled out for Workflows and other processes as well. Workflows, in particular, can benefit greatly from having a more visually accessible appearance, especially given the complexity that these can have when used to their fullest potential.