As I prepare for my Dynamics 365 certification in sales (MB 210), I’m creating blog posts based on my revision. I hope that collectively these posts may prove useful to anyone also preparing for the MB 210 exam. This time I will cover the concepts around business process flows.

You will see that business process flows are mentioned in the skills measured statement within the section headed “Perform Configuration”. This statement (I believe) hints as several things we’ll need to know about. Firstly, we’ll need a general understanding of how to maintain business process flows. Additionally, we’ll need to be aware of the stages / steps in the sales related out of the box business process flows. This second learning objective implies an understanding of the overall sales process, so we can then appreciate how business processes fit into that scenario.

Therefore, we have three key learning objectives;

• Understand the overall sales process
  
• An awareness of the out of the box business process flows, including their stages / steps and how to operate them as a user
  
• Knowledge of how to customize business process flows
  

Because of this I plan to split this blog post into three sections to reflect these distinct learning objectives.

• Section one – Sales Processes
• Section Two – OOB Business Process Flows
• Section Three – Customizing Business Process Flows

SECTION ONE – Sales Processes

As the MB 210 exam is all about sales, we should expect that we will return to detailed parts of the sales process multiple times during our revision. Working with business process flows is just one example of this, it is also important for us to appreciate the overall sales process when considering leads, opportunities, quotes etc etc.

As this sales process is an essential element let’s begin with a conceptual overview.

What is a sales process and why do organisations have them? A sales process is intended to help an organisation follow a set of pre-defined steps that when followed correctly should help give the best possible opportunity of gaining a sale. This approach is commonly taken with several goals in mind. Sales processes need to be;

• Repeatable
• Consistent
• Predictable
• Focused on positive customer relationships

Repeatable activities. Following a process means doing the same thing over and over. The repeatability means automation might be used to make progression in the process simpler or quicker. Additionally, a repeatable approach helps to support a consistent experience for customers. A clearly defined sales process can help give predictable outcomes. By having a set process, we can easily compare multiple won and lost deals. (etc.) This analysis could lead to increased margins or better conversion rates. A well-defined sales process will also be focused on fostering on going customer
relationships. Establishing and maintaining relationships with customers should be at the heart of everything organisations are trying to achieve with their sales process. As most organisations will be looking to foster a long term relationship with customers which will ultimately lead to repeat business!

Sales Process – Dynamics 365 Entities

From a Dynamics 365 point of view you’ll first need to understand the entities that directly or indirectly play a part in the sales process. Some are listed below;

Dynamics 365 Default Sales Process

Some organisations have very simple sales processes, but others will have longer and more complex sales cycles. In my experience some implementations of Dynamics 365 will use all of the entities involved in the sales cycles but in many circumstances, it will be common that only a limited set are used.

It is a common customization to “tweak” the sales process and additionally add workflows (or flows) to automate routine tasks. (Like sending a thankyou email for new orders to the customer.)

Conceptually we can assume that a lead will progress to an opportunity. Then this might spawn the creation of other related transactional items. (Meaning quote, order then invoice.) Additionally, qualification of a lead will involve associating the opportunity to an existing account and contact or creation of new records.

SECTION TWO – OOB Business Process Flows

I hope you can see that the sales process for each organisation could be quite different …. it is a common task to tailor the process for each new implementation. Within Dynamics 365 we use a concept called business process flows to help drive the sales process. (Or other processes.)

Using a business process flow makes navigation of the system easy for users and helps enforce the good practice.

Whilst it will be common for organisations to tailor the business process flows, Dynamics 365 does ship with an out of the box (OOB) set of processes. Before understanding how to tailor these it will be key to appreciate their OOB stages / steps.

Below you can see I have a lead, I have entered the key information, but I have not yet qualified the lead. Notice the business process flow towards the top of the form. The “Qualify” stage is currently active.

Tip:
Also notice the length of time this stage has been active is shown. In my example the qualify stage has been active for less than one minute as I have only just created this lead!

Tip:
Clicking on a business process flow stage heading will show the steps (aka fields) which should (or must) be completed at that stage.

Clicking “Qualify” on this lead will move the business process forward to the develop stage. Additionally, an opportunity will be created and loaded. Also notice that I didn’t link my lead to an existing contact or account. So, a new contact and account will automatically be created and associated with this opportunity.

Once the opportunity loads, I am ready to progress the opportunity. Out of the box this will involve developing the detail on the opportunity, making a proposal to the customer and then closing the opportunity as won or lost. Along the way I would create whatever transactional records are needed. Such as a quotation at proposal stage.

The “Next Stage” option is there for the user to move the process forward when required. (Assuming they first complete all the required fields!)

I hope you can see that each business process flow has several stages. And that each stage will relate to an entity. (For example, the qualify stage was linked to the lead entity, whilst the develop stage is linked to the opportunity entity.) Plus, each stage contains a number of steps (or fields) which dictate what information should be captured at each stage in the process.

Out of the box we have two key sales processes. “Opportunity Sales Process” and “Lead to Opportunity Sales Process”. The lead to opportunity sales process applies when we follow the “full” process. (By that I mean we have a lead that later gets qualified into an opportunity.) The opportunity sales process is very similar and may come into play if you start the sales cycle by creating an opportunity rather than a lead.

Below I have shown the stages and steps in the out of the box lead to opportunity sales process. You may need to become familiar with these ….

SECTION THREE – Maintaining Business Process Flows

Dynamics 365 ships with several out of the box business process flows. Including common ones such as “Lead to Opportunity Sales Process” and “Phone to Case Process”. In addition, further example (ready to use) processes can be enabled. You do this by using the “Add Ready-to-Use Business Processes” option that can be found in the data management area of Dynamics 365 advanced settings.

Note:
Be aware that if you add these ready-to-use business processes they cannot be removed. If you wish to experiment with them that might be best done in a development environment!

I will often take an existing business process flow and tweak it to meet a company’s needs. It is also (obviously) possible to create new business processes from scratch.

Enabling Entities for Business Process Flows

Before you can create business processes on an entity it needs to be enabled for business process flows. We do this by amending the properties of an entity. (As shown below.)

Each business process flow will have a primary entity. If an entity is to be used within a business process flow as a primary or “secondary” entity it must be enabled for business process flows.

Note:
Once set you can NOT turn off business process flows. But having said that, just because an entity is enabled for business process flows doesn’t mean you have to use them with it!

When we enable an entity for business process flows some fields get automatically created on the entity. Including Process Session and Process Stage. These are links to the current process and the stage within it.

Tip:
Notice that I have shown this property being set within classic style of entity customization. At the time of creating these notes this property was not available in the newer style entity customization screens. (Although we should expect that to change over time!)

Create or Edit Business Process Flows

You can edit existing business process flows and create new ones at “make.powerapps.com”. Below you can see that under the flow section I have a Business Process flows option. And with this option I can opt to edit existing processes or create new ones.

When creating a new business process flow, I enter a name and select the primary entity for the business process flows. (Tip: The entity will first need to be enabled for business process flows to be selectable.)

Once you have a business process flow you can define which roles can access it or when multiple flows exist define a order to help define which will get applied by default.

Order Process Flow

It is possible for one entity to have multiple business process flows. The sequence that the process flows are presented to a user is governed by selecting the Order Process Flow option.

Below you can see that I have two business process flows for leads and their order can be defined. (I have two as marketing users will get a different process to the “standard” sales users.)

Enabling for Roles

In addition to defining the order of business process flows they can be enabled for selected roles or all roles. Using the “Enable Security Roles” ribbon button.

Stages, Steps and Stage Category

A business process is split into multiple stages. Each stage is represented by a colored heading as the process runs.

Each stage relates to an entity. All of the stages in a process can relate to the same entity. Or different entities can be used as the process progresses. For example, with the lead to opportunity business process flow processing moves from lead to opportunity after the qualify stage.

Each Stage is made up of a number of steps. (Each step being a field that should be completed at that stage in the process.) Some steps will be mandatory, some optional.

The fields in each step will show in the business process flow but the exact same fields can also present on the form.

The stage category is really just for reporting and logically groups the stages.

Notes:

• There can be no more than 10 active business process flows per entity.
• Each process can contain no more than 30 stages.
• Multi-entity processes can contain no more than 5 entities.

Conditional Branches

Understanding how to create a business process flow with a conditional branch will be required. Try actually creating a conditional branch, it will help you understand them! As always the best revision approach is to create “something” to see how it performs.

Below you can see that I have created a conditional branch which effectively adds an extra stage for leads. When a budget greater than 20,000, I want to make some additional information mandatory!

You can see below that once this change has been applied a different stage appears when the budget amount is greater than 20,000.

Workflows and Business Process Flows

We can also additionally add workflows into the stages on a business process flows. Dragging a workflow component allows us to trigger a workflow. This trigger can be set to start the workflow on stage entry or exit. Importunately, the workflow you select must be an active, OnDemand workflow.

Additionally, we can add global workflows. As shown below these have different triggers. For example, you could run a workflow whenever a process is completed or abandoned.

NOTE: In the above example I have explained triggering a “classic” on demand workflow. We now also have the ability to trigger a Microsoft Flow in a similar manner! (At least we do as a preview feature.)

I have covered quite a few concepts in this post! But hopefully these notes will serve as a good revision guide for MB 210 when you are considering sales processes and associated business process flows. Enjoy.

As I prepare for my Dynamics 365 certification in sales (MB 210), I’m creating blog posts based on my revision. I hope that collectively these posts may prove useful to anyone also preparing for the MB 210 exam. This time I will cover the concepts around record creation rules.

You will see that record creation rules are mentioned in the skills measured statement within the section headed “Perform Configuration”.

Record creation rules are something I often think about in context of service scenarios rather than sales! I might, for example, want to create a case for all emails received into a support mailbox. But I guess there is also a valid use case to create leads (or other entities) as messages are received. Having said that record creation rules are created / configured in the advanced settings area of Dynamics 365 under the heading of “service management”. (Hence why I typically think about them in a service context.)

But regardless of where they sit in the navigation they are referenced in the skills measured statement and we should therefore be prepared to answer questions on them!

Rule Creation

Initially we create the record creation rule “header”, this includes setting the source type, queue and such like. Below you can see I have linked my record creation rule to a queue I’ve called info@npdynamics.com.

The queue field allows me to define the source queue. Often this could be a queue associated with a “generic” email account. For example, info@npdynamics.com. Meaning any customer who sends a message to this type of address may be registering a service request or sales enquiry. Prior to creating the record creation rule you may need to create and test a suitable mailbox. (I will give additional details below.)

Source types, a common use case is to create records as emails are created. But we can configure multiple other source types. Including;

• Phone call
• Email
• Appointment
• Task
• Social Activity
• Booking Alert
• Chat Activity
• Service Activity
• Alert Subscription
• Invite Redemption
• And many more!

Additionally, we have options to decide if cases should be created when customers have a valid entitlement etc. As MB 210 is a sales exam, I am not going to explain these concepts here. But you should investigate these options to fully understand the capabilities of record creation rules.

Having specified the “header” details I can then add the record creation and update details. In my example I will keep this very simple. I “just” want to create leads for all emails that arrive into my “info” mailbox. But hopefully you can see that I could add conditions and other actions as required.

Tip:
I didn’t add any conditions or other actions in my very simple example. You might want to experiment with these to understand how more complex rules could be created!

Creating a shared mailbox

Before creating your record, creation rule you might want to create a generic email, such as info@ or sales@, I will explain how to achieve that below …

Create mailbox in Exchange

Within the office 365 admin area, I have opened the Exchange admin center and created a shared mailbox.

Tip:
I guess / assume you could use other mailbox types. But in my example (and often in production scenarios) a shared mailbox is ideal. As it will not be associated to an individual user. And also, won’t consume a license.

Notice below that we can list the users who have access to this mailbox in the mailbox delegation option.

Create queue in Dynamics 365

Once we have defined a shared email address / mailbox in Exchange we can create a queue within Dynamics 365. This can be done in the advanced settings area of Dynamics 365. You will find the queues option (show below) under business management within the advanced settings.

You can see below that I have created a public queue and given my shared mailbox as the incoming email address.

Approve then Test & enable the mailbox

Once my queue is saved a mailbox within Dynamics 365 will be created. Before you can receive incoming email messages you will need to check /edit the details. In my example I have altered the synchronisation rules, notice how I have configured incoming mails for server-side synchronisation, but the outgoing email option is set to “none”. This might be typical, as an “info@” address would be used to capture emails, but any responses will be sent from “real” users.

Once you are happy with any changes, you will need to click the “Approve Email” option to approve that this mailbox can be linked to Dynamics 365.

Next use the “Test & Enable Mailbox” option. Assuming you get no errors the mailbox will be ready for use after a few seconds.

Testing / Using the Rule

Having created your mailbox and rule. Plus tested the mailbox and activated the record creation rule you will be ready to test it.

Once an email is received (and tracked into Dynamics 365) the record creation rule will be trigger. And (as you can see above) emails will be created. By default, the leads will be owned by the owner of the record creation rule. You may need to be aware of this and consider how to handle the ownership of leads. (Either by changing the owner of your record creation rule or by setting the owner within the creation rule.)

In this post I have given you one simple example / use case for record creation rules but I hope you can see that my example could be expanded to cover more complex scenarios.

Additionally, you should consider that record creations are just one approach available to automatically create records within Dynamics 365. Other options existing including traditional workflows and Microsoft Flow.

I suggest you include creating and activating a record creation rule into your MB 210 revision. Then trigger the rule (in my example by sending emails to the queue) and review how your leads are created. Enjoy.

As I prepare for my Dynamics 365 certification in sales (MB 210), I’m creating blog posts based on my revision. I hope that collectively these posts may prove useful to anyone also preparing for the MB 210 exam. This time I will cover how to configure the sales content pack for Power BI.

You will see that the sales content pack is mentioned in the skills measured statement within the section headed “Perform Configuration”.

Power BI is a big subject…. but luckily for us…. only the ability to configure the sales content pack is mentioned in the skills measured statement! I doubt that the MB 210 exam will require us to become Power BI experts but knowing the basic concepts and specifically how to enable the sales content pack will be essential.

Power BI is used to transform data into “rich visuals”. What this means it is a powerful graphical reporting tool that can greatly extend the standard reporting feature of Dynamics 365.

Install Power BI

Assuming you will be preparing for you MB 210 using a trial of Dynamics 365 …. Before you can work with Power BI you may need to purchase Power BI. Don’t worry as the free version of Power BI will work for our purposes. Although we still need to “buy” it. Therefore, your first task will be to open the 365 admin center and select the purchase services option. Search for Power BI and select the free version.

Next you can review the details and select the “get it now” option.

Now we make our purchase. Notice that the value is zero per user per month.

Unfortunately, despite being free we must now place the order using “check out now”. This process will involve entering your credit card details. You will get a monthly “bill” from Microsoft but the value will be zero and nothing will be charged to your credit card.

Once the order process is completed, find your Dynamics 365 using in the 365 admin center and assign the newly purchased license. (As shown below.)

Open Power BI and Discover Content

Now Power BI is ready you can access it from https://app.powerbi.com
or select the Power BI app from the “waffle” icon”. (As shown below.)

Your first task will be to connect Power BI to your Dynamics 365 instance. To do this use the “Get data” option. And under the services option also select “Get”.

Power BI can connect to many different data sources. But the one we are interested in is “Sales Analytics for Dynamics 365”. Below you can see that I have searched using the word “sales”. I have then located the package I require allowing me to click the “get it now” option.

First you will need to enter the url for your Dynamics 365 instance. Power BI will also need to know the last month of your fiscal year. (Typically, this will be 12, assuming you wish to report yearly data in terms of typical calendar years.)

After clicking next you will be asked to confirm the authentication method. Enter “OAuth2”.

Open Power BI App

Now you have completed the setup of your Power BI app you can open it. Under the apps option, you can see below that I now have the sales analytics for Dynamics 365 app.

Opening my app will show a dashboard, similar to the one shown below.

Clicking on any tile in the dashboard will drill into the report behind that tile. By doing this you can review and filter additional information.

Our skills measured statement only reference ed the need to configure the content pack for Power BI but I still encourage you to explore the resulting dashboard / report. Maybe you could (should) mark some opportunities as won and review the impact on these reports!

Refresh Dynamics 365 Data

Changes to your Dynamics 365 data will (by default) be refreshed automatically into Power BI daily. Whilst testing you may want to manually force a refresh or change the frequency of data updates. For this select the “list” icon in the top right hand corner of the screen. (As shown below.)

Under the datasets option you will find a refresh icon. Selecting this will manually force a data refresh. Assuming you are using a trial with the typical sample dataset this process will only take a few seconds.

Additionally, if required, you can also use the “schedule refresh” option to control the frequency of data refreshes. Although whilst testing in a trial instance the default of daily is probably enough!

In terms of MB 210 revision, I do encourage you to configure Power BI and then experiment with what data is available. I hope this post has given you enough pointers to get started with that. Enjoy.

I love it when I’m asked fantastic questions! Recently someone reported a problem whilst using the window.IsUSD command. If you don’t know this is a JavaScript command we can use to see if our code is being run within USD or not.

The problem was that the window.IsUSD command seemed to no longer work. Probably because they were now using the new Unified Interface rather than the web client or possibly because Chrome Proecss was now being used for the hosting type. One possible (partial) solution is to alter your JavaScript to use “parent.window.IsUSD”. Certainly in some circumstances this appears to resolve the issue.

However even this could still result in an occasional reliability issue! If you are using chrome process as the hosting type then you may still see the IsUSD command fail occasionally. Microsoft explain here. My limited understanding is that the potential “reliability” issues with window.IsUSD relates to the asynchronous nature of chrome process. Meaning, your JavaScript code using a window.IsUSD command could be triggered before the IsUSD value has been set to true. Meaning the code could be unpredictable. One solution is to ensure all of your code is triggered only from predefined USD events such as PageReady. That is fine but you may prefer to add code directly to your Dynamics 365 form. In this post I will describe an alternative approach which you might want to consider.

This alternative approach relies in using a RunScript action when the hosted control is first loaded. By running localStorage.setItem(“isUSD”, “true”) I can then use commands like localStorage.getItem(‘isUSD’) to confirm if the code is being run within Unified Service Desk or not.

I originally blogged about the window.IsUSD feature here. I also showed one possible use for this feature in triggering the load of an account’s website in this post.

Whenever I describe a feature I like to offer an example solution, as in my opinion that helps to give context. Therefore I returned to my earlier example of wanting to load the account’s website from the on-change event on the account form. I decided to update this example, to work with this alternative approach. (And as a result support both the Unified Interface and Chrome Process.)

The steps involved are;

1. Create a hosted control
2. Create JavaScript on OnChange of Website
3. Create a RunScript Action
4. Create an action to load the account website
5. Create an event

Tip: This steps might sound complicated but this is a pretty simple example!

Step One – Create a Hosted Control

My first step was to create a hosted control to hold my accounts website. As when a user changes the website field on my account form I want a tab to open containing the newly entered website.

Step Two – Create JavaScript on OnChange of Website

I am going to assume here that you know how to add JavaScript into Dynamics 365 forms!

Essentially what I required was some code that would trigger a USD event each time the website changed. But I didn’t want this code to be triggered if the same onchange event was triggered from outside of USD. You can see below that I have added a form library and in that I have created a function which will be triggered on change of the website field on my account form.

Additionally I have used the edit button and ensured that the “pass execution context as first parameter” option is selected.

The code I added looked like this;

function onChange_Website (executionContext) {
  var context = executionContext.getFormContext(); 
  // *** Ensure website is a fully qualified address
  var website = context.getAttribute("websiteurl").getValue();
  if(website.substring(0, 4) != "http") {
    website = "http://" + website
  }
  var isUSD = localStorage.getItem('isUSD');
  // *** If I am in USD then fire a USD event!
  if(isUSD == "true") {
    window.open("http://event/?eventname=AccountWebsiteOnChange&WEBSITE=" + website);
  }

Notice that I have highlighted in red the command(s) used to check if this code is being run within USD. We will look how to set the “isUSD” value in a second!

Step Three – Create a RunScript Action

Next I want a RunScipt action call that will set my isUSD value.

This RunScript action needs to be triggered when my Account hosted control is loaded. So I simply added it to the PageReady event on Account. The end result being that each time my Account hosted control loads a value of “isUSD” will be set to true.

Step Four – Create an action to load the account website

I wanted an action to actually load my account website. That was simply a navigate action.

Step Five – Create an event

Next I wanted to create an event on my Account hosted control, this will be triggered each time the website on the account form changes. I will simply add my navigate action into that event.

Below you can see that I have used the “Related” option to open the “Events” tab. Within the events tab I have simply used the “New Event” button to create an event called “AccountWebsiteOnChange”. This event will be triggered by the JavaScript that will run on my account form.

Once I’d created my event I opened it and added the navigate action we created in step four.

Hopefully within this simple example you can see that I can use a RunScript command including “localStorage.setItem(“isUSD”, “true”)” to set “isUSD” to a true value. Then in any JavaScript I can use “localStorage.getItem(‘isUSD’)” to reference that value. And therefore know if the code is being run within Unified Service Desk or not. Enjoy.

Earlier this year Microsoft released a new set of Dynamics 365 exams, the new exams are broadly similar to the older ones but include updated content and have a slightly different focus.

The old exams used to “simply” test our knowledge of Dynamics 365 these newer exams additionally attempt to test our abilities to be a Dynamics 365 consultant. That means not just regurgitating a set of facts about Dynamics 365 but demonstrating real insight into how the product is used and implemented in the real world. This is reflected in a new set of certifications, as by passing multiple exams we can gain a “Dynamics 365 Functional Consultant Associate” certificate.

There are multiple associate certifications, including being an associate for sales, service, marketing and more. Each certification requires you to pass a core exam and a related specialism. For example, to become a Functional Consultant Associate for Sales, you need the sales exam (MB 210) and the core exam (MB 200).

If you’ve passed Dynamics 365 exams previously you may want to be aware that the core exam (MB 200) has a great deal in common with the older MB2-716 exam. But it will additionally cover new topics. These include new features like Microsoft Flow and new concepts around systems implementation. (Such as discovery, planning and analysis tasks.)

I have created multiple revision guides in the past, but this one will be a first for me! As I normally create these guides as I actually revise for the exam. In this case I’ve already taken and passed the MB 200 exam. But many people have contacted me requesting that I still publish a revision guide …. Hence this introduction to the revision guide I am about to retrospectively create.

My normal practice at this point is to print the skills measured statement and take time to very carefully review every bullet point. I painstakingly highlight each one that I m not 100% confident on and plan my revision accordingly.

As already mentioned, I have already passed this exam … hence no painstaking preparation! The approach I followed (this time) was very different and not one I can recommend! I had limited time available and an exam voucher burning a hole in my pocket so, I just booked the exam and took it half expecting to fail. It turned out that I was lucky and passed.

One of the reasons I did this was to experience the new style of questions. With past exams the questions were simply multiple choice. Meaning we selected one or sometimes two correct answers from a list. Traditional multiple choice questions do still exist, but you’ll find a greater variety of question formats. Examples include sequencing possible steps in a process, clicking on screen a shot or selecting possible answers to a statement from a pick list. If you haven’t experienced the new style questions, I should stress I don’t believe they are anything to worry about. I liked the varied question formats and often found them more logical.

But this has raised a question in my mind …. “why do I take these exams?“. Passing the exam (for me) is simply a piece of paper the main benefit is always the actual studying process and gaining new knowledge. It’s that knowledge that will enhance my career by hopefully making me a better consultant. Passing the exam is simply confirmation of what I’ve learnt. Obtaining a pass without deeply learning all of the content possibly misses the real reason I take the exams.

Any consultant working with Dynamics 365 will be aware that the product evolves rapidly. For me keeping certified helps ensure my knowledge is kept current. Therefore, I have come to understand that the process of learning is my primary goal. Passing the exams is simply a by product of my learning process.

I hope (like me) your reason for preparing for the MB 200 exam is to be a better consultant and that means learning new things. And having completed your learning journey the exam will “just” be a final confirmation step.

With that said, I encourage you to start your learning journey by very closely reviewing the skills measured statements and painstakingly highlighting everything you need to learn. A copy is shown below ….

I am creating a series of blog posts that collectively are designed to help anyone preparing for the Microsoft Dynamics 365 Customer Engagement Core exam. (aka MB-200) In this post I will look at concepts around entity relationship diagrams.

You can see below that the entity relationship diagrams are mentioned in the perform discover, planning and analysis section of the exam.

Firstly I’d like to bring your attention to the percentage of marks for this section of the exam! Its “just” 5 to 10%. You might want to consider this when deciding how deep to learn each area of the exam. As other sections of the exam could be as large as 25%. Meaning I suggest you should spend your valuable revision time wisely!

Having said that 10% is still a significant portion of the exam so we can’t just ignore the topics in this or any section!!

Secondly, I hope you can see that the topics covered here aren’t necessarily directly testing your knowledge of the Dynamics 365 product. The scope actually goes wider, the purpose seems to be to test your experience of being a functional consultant.

Entity relationship diagrams are a good example of this as they are a commonly used diagram in many types of project well beyond “just” Dynamics 365. A it will be a common design task to define and document your database structure.

What is an Entity Relationship Diagram (ERD)

An Entity Relationship Diagram (or ERD) is a chart that illustrates how entities relate to each other. When thinking about databases this will mean the tables within the database. (The term table and entity are pretty much interchangeable!)

Typically a standard set of symbols will be used to represent entities. Connecting lines between the entities will show how they relate to each other. By this I mean is it a one to one, one to many or many to many relationship. Sometimes we might also see notes to highlight any mandatory relationships.

The concept of an ERD is certainly not a new one. Peter P Chen is recognised as creating ERDs in the 1970s. You can read more about Peter on Wikipedia here. Although you should be aware that Chen’s notation is just one way to draw an ERD.

Types of ERD

There are multiple ways are drawing an ERD. Including Chen, Bachman, and crows foot notations.

You may also need to consider the level of detail to represent. For example, do you simply want to show the key relationships between entities or do you wish to show all relationships and also all attributes for an entity. Whilst the later maybe more “correct” it could become cumbersome to maintain. Plus developers reading the chart may find it difficult to “see” the core meaning you wished to portray. Therefore the level of complexity should be revised based on the purpose and audience for the diagram. Often it will be logical to only represent the key entities and key relationships.

If we think about Dynamics 365 for a second, I will often just draw any new relationships or custom entities to be added to the CDS data model. But I wouldn’t always try to draw all of the out of the box system entities and their relationships.

Tip:
CDS stands for Common Data Service. CDS is built on the common data model that represents all of the entities used within Dynamics 365. CDS contains many standard entities and relationships to represent accounts, contacts, cases and much more. Hence why I will often only draw the alterations to this model rather then feeling the need to document what is a standard set of entities and relationships.

As mentioned there are multiple types of ERD notation. One being Chen’s original notation. Here we have rectangles to represent entities and diamonds to represent the relationships between the entities. We may optionally wish to name these relationships. For example, contacts associated to an account could be considered employees of the account. Connecting lines would further define which relationships are 1 to 1, 1 to many or many to many.

Admittedly I don’t often see Chen’s notation! In my experience, more commonly a crows foot diagram will be used. The connecting lines on a crows foot diagram give rise to its name … as these clearly show which relationships are 1 to many, many to many etc. (With the “many” option resembling a crows foot.)

The example diagram below does include attributes, the addition of these is optional. You could just draw the key fields between entities or even just the entities.

Why is the ERD important

A very good question is why is the ERD important! Why is ERD often a key design artefact?

I guess because drawn properly it should clearly explain what entities exist and how they are connected. As Dynamics 365 model driven applications are data focused understanding the data relationships is often a major step in the overall solution design.

Drawing the relationships may help highlight any limitations in the design. Assuming you create an ERD before actually starting to build your entities it may prove extremely valuable in spotting design weaknesses / limitations before you start to develop anything.

Personally I have often found a well-drawn ERD to be one of the most important pieces of technical documentation. Mapping out the data is often the first step I’d take in creating any design.

Tools for creating an ERD

There are many tools out there to help you draw an ERD. I certainly won’t attempt to mention them all here! And I don’t expect the MB-210 exam to question us on specific tools. Understanding what as ERD is and why we’d create one (I assume) will be the key requirements for the exam.

In some circumstance you could draw the most simple diagrams directly in PowerPoint or by using Windows Paint. But unless your diagrams are very simple you will probably need a more sophisticated drawing tool.

For me that generally means Microsoft’s Visio.

Below you can see that Visio allows me to create ERDs using various notation types. You may want / need to experiment with which one fits your requirements best. (Although I personally routinely use the crow foot notation!)

Hopefully I have given you a high level description of ERDs and why we need them. This will be important for the MB 200 exam. But more importantly, if you don’t already routinely create entity relationship diagrams I suggest (I your revision) you try to create some for projects you are currently working on. Enjoy.

I have been completing a series of posts to help people prepare for the MB 200 certification (Microsoft Dynamics 365 Customer Engagement Core). Here is a collection of links to all of those posts. I hope these might serve as a useful revision aid for the MB 200 exam.

The MB 200 certification is not easy! But it is an important exam, as it is a prerequisite in gaining any of the Functional Consultant Associate certifications.

Additionally, the MB 200 (being the core exam) has quite a wide focus, meaning you will have lots to revise. Hopefully that will be a fun process, but you will need to be prepared to cover a significant number of topics.

Note: This guide is a work in-progress, please keep checking back for updates. (Links to items in red will be added later!)

Introduction

Revision Guides

<<Overall Project Approach>>

<<Project Artefacts>>

<<Requirements Gathering>>

Entity Relationship Diagrams

<<Customer Collaboration>>

Revision Guides

<<Dashboards>>

<<Charts>>

<<Views>>

<<Forms>>

<<Apps / Site Map>>

<<Mobile>>

<<Email Templates>>

<<Excel Templates>>

<<Work templates>>

<<Language Translations>>

<<Business Rules>>

<<Business Process Flows>>

<<Workflows>>

Revision Guides

<<Entities>>

<<Accounts and Contacts>>

<<Export / Import Data>>

<<Data Management>>

Revision Guides

<<User Creation>>

<<Security Roles>>

<<Teams>>

<<Field Security>>

<<Hierarchy Security>>

Revision Guides

<<Outlook add-in>>

<<Email Integration>>

<<SharePoint Integration>>

<<OneNote Integration>>

<<Microsoft Flow>>

Revision Guides

<<Environments>>

<<Solutions>>

<<Currencies>>

<<Subject Tree>>

<<Custom Help>>

<<Session and inactivity timeouts>>

<<Auditing>>

<<Relevance / Category search>>

<<Performance>>

I can’t believe the summer is almost over and we are busy planning our next Birmingham event! We’ll be hosting a fantastic evening of Dynamics 365 content in Birmingham on 25^th Sept. All are welcome.

We’ll be at our now regular venue of the Wesleyan Building. The presentations will start at 7pm but we encourage you to arrive early between 6pm and 6:30pm. As you can then join us for some fantastic networking time and most importantly our famous free buffet!

Networking and amazing free food are all well and good but what can you expect to learn at our latest event. As always we love to cram in loads of great content…. meaning we have five great speakers and three awesome topics. (Details below.)

Spaces are limited so please register now on D365UG here or on meetup.com here.

What’s new in the Wave 2 update for Dynamics 365 & Power Platform?

Join @Andrew Bibby, @Sophie Loor and @Craig Seymour for a look at the best bits coming in Wave 2 in October. I’m looking forward to this presentation as it is always essential for everyone working with Dynamics 365 to stay updated on the latest features. And these three experienced consultants are the ideal people to showcase what’s coming soon.

Product overview of ClickLearn

The guys from QGate will be on hand to give us an overview of ClickLearn, the awesome tool for creating e-learning materials and documentation for Dynamics 365. Training and documentation are important topics in any project but also topics that are often not given the time they deserve. I’m therefore excited to here about these new tools from QGate.

Dynamics 365 Portals in Action

@James Glover from Microsoft partner M-hance will be showcasing some examples of portals they have built in the not-for-profit sector that enable their customers to manage cases and documents. Last time Imtiaz gave us a great overview of Dynamics 365 portals, we received lots of feedback that people would like to learn more about portals. Therefore in this event James will showcase some examples of portals he’s created.

Spaces are limited so please register now on D365UG here or on meetup.com here.

I am creating a series of blog posts that collectively are designed to help anyone preparing for the Microsoft Dynamics 365 Customer Engagement Core exam. (aka MB-200) In this post I will look at concepts around CDS entities.

You can see below that we have a section of the exam which covers managing entities and data. Therefore you can expect quite a bit of revision to be required as this section can be up to 20% of the exam.

Entities are at the centre of anything and everything we do concerned with customising Dynamics 365, obviously it ships with many out of the box entities such as contact, case and phone call. Beyond this you can create your own custom entities to extend the capabilities of the base product. One important concern here is knowing when to use an existing system entity and when to create your own from scratch. You will hear the term common data service or CDS, as this is the location all of our Dynamics 365 entities reside. I will therefore begin by giving an overview of CDS.

Dynamics 365 is created using the Power Platform. The Power Platform includes PowerApps, Flow and Power BI. We have two types of PowerApps canvas apps and model driven apps. I won’t explain the differences between app types here! But for this purpose it is worth understanding that Dynamics 365 is effectively “just” a model driven app sitting within the Power Platform. Model driven apps locate their data in the common data service (or CDS for short). Data within CDS is stored within a set of entities. An entity is a set of records used to store data, similar to how a table stores data within a database. CDS includes a base set of standard entities that cover typical scenarios, but you can also create custom entities specific to your organisation

Entity Types

There are three types of entities in CDS, system entities, custom entities and activities.

• System Entities
  • Built-in entities which are created when a new organization is created. (Such as Account, Contact, Case etc.)
  • Most can be modified, such as account, contact etc.
  • Some system entities can’t be customized or have certain elements restricted.
  • Can never be deleted.
  • When considering solutions, cannot be locked down by a solution. (They will always be customizable!)
• Custom Entities
  • Can be created by system customizers to address specific needs.
  • Can also be created when importing managed or unmanaged solutions.
  • Can be fully customized. (Unless locked down with managed properties.)
  • Can be deleted. (Generally!)
• Activities
  • Used to log interactions with other entities, such as a phone call to a contact or an email to an account.
  • Some properties are predefined and can’t be changed.
  • All activity entities share some common fields within the activity pointer entity.
  • Share a common set of security role privileges, your access rights to emails, phone calls and tasks will always be the same!
  • Out of the box examples of activity include appointment, email, phone call and task.
  • You can create custom entities of type activity.
  • When required activities can be hidden from the activity menu.

Note:
I will cover the activity pointer entity in more detail in a later post. It is essentially a “special” join between the primary entity and the activity. Consider, for example, the “To” field on an email. The email can be sent “To” multiple recipients, plus some maybe contacts whilst others might be accounts, leads or even details from custom entities. Meaning the activity point allows us to join multiple records of multiple types to the activity.

Entity Assets

Each entity is made up of multiple assets. Later we will see that within a solution we can opt to include some or all of the entities assets. Assets are essentially the building blocks which make up the structure of the entity.

Note:
The screen shot above is from the classic method for amending entities. In this post I will attempt to use the newer style screens as much as possible! You can now access the maintenance of entities from make.powerapps.com, the screen shot below shows the more modern maintenance of entities. Generally speaking the features available in the classic interface and make.powerapps.com are identical. However you will find some minor differences. When I took the MB 200 exam I don’t recall any questions that were specific to one interface or the other. But regardless I still encourage you to become as familiar as possible with the newer interface. Unfortunately you may find the existence of two methods for maintaining entities confusing, we live in changing times and whilst the migration from old to new is completed some complexity may exist.

Assets include forms, views, charts, fields, keys, relationships, messages, business rules, hierarchy settings and dashboards.

One fundamental asset is fields, as they make up the heart of the entity. There are many different types of fields, including text boxes, date pickers, option sets etc. I will cover fields in detail in a later post.

We can also define form layouts, charts and views. And we can define how the entity relates to other entities. Plus, define business rules which contain logical rules that define how fields on the entity should behave, for example hiding and showing them as required.

Entity Ownership

There are two types of ownership for entities in Dynamics 365. User / Team ownership or organization ownership. Once the type has been set on an entity it cannot be changed.

Below you can see that I have started to create a new entity. Notice that the ownership field has two possible options.

Tip:
To be able to see the ownership field and many other parameters regarding your entity you may need to click the “More settings” option!

Note:
system activity entities or custom activities are always user or team owned. With those the ownership field cannot be amended.

Organization owned entities are available to the whole or organization (or not) dependent on security roles settings. Only the none and organization options are available in security roles for organization owned entities. Organization owned entities are useful for reference data that will be available across the entire company. One example of this might be products, as products would be referenced on multiple entities across the organization. The quote / orders (etc) that they are referenced on would be user / team owned. But the actual products would remain open to the entire organization.

User or team owned records have a greater number of ownership options available. As shown in the chart below;

As the name suggests user / team ownership means the entity can be owned by a user or team. Examples of this would include contacts and accounts. Below you can see a list of accounts, notice how each one has an owner. Typically core entities in the system that require control using security roles will have user / team ownership.

When defined for this type of ownership an additional owner field is created that will hold the owner for each record. (ownerid) When an entity is defined as user / team owned options in security roles will include none, user owned, parent / child business unit, business unit and organization.

Entity Properties / Settings

Each entity has numerous properties or settings, some of which can only be set as the entity is created. (Such as the entity ownership approach.) Others properties can be set after creation but once defined cannot be disabled. (For example, Notes.) Some properties can be enabled / disabled at will. (Such as the option to allow quick create.)

For the MB 200 exam it may be important that you become familiar with all of the main settings on an entity and appreciate which can and can’t be disabled. It will be productive preparation exercise to create some entities and experiment with what happens when you try to enable / disable various properties.

Below you can see I have opened an entity in my organization, I can use the settings option to view the various properties of the entity. These are grouped under several headings including entity type and ownership, collaboration etc.

As an example, below you can see that I have expanded the collaboration settings section. Here we can control various collaboration settings such as enabling for document management. Importantly notice that some options can not be disabled once enabled.

Settings that cannot be disabled once enabled include;

• Entity type
• Entity Ownership
• Feedback
• Activity task
• Connections
• Send email to entity
• Queues
• Notes

Tip:
Whilst I encourage you to use the newer make.powerapps.com interface as much as possible, try swapping to the classic view to also view the entity properties. At the time of creating these notes some properties existed in the classic view which have yet to be replicated in the newer interface.

Here is a quick summary of some things you might need to be aware of;

• The entity name cannot be changed, and will be prefixed with the publisher prefix.
• Display name and plural name can be changed.
• Ownership can be “User or Team” or Organization. Once set it cannot be changed.
• All entities will have a primary field, called “name” by default but this can be changed. (Whilst creating the entity.) The primary field can only have a type of “Single Line of Text”. It will default to a length of 100 but this can be changed. (Note: The primary field is not the database primary key; it does not have to include a unique value. Behind the scenes each record has a GUID which is an automatically created primary key.)
• On creation entities can be defined as being an activity entity. Custom activity entities can optionally be displayed in the activity menus. All activity entities will be by implication User or Team owned. All activities share a common set of privileges.
• Having saved an entity, the following properties are read-only, meaning they can only be defined as you create an entity,
  • Name
  • Ownership
  • Define as an activity entity
    • Display in activity menus
• Once enabled on an entity the following properties cannot be disabled;
  • Business process flows
  • Feedback
  • Notes
  • Activities
  • Connections
  • Sending email
  • Queues
• Notes, activities and connections are enabled by default when a custom entity is created. But they can be disabled on create.
• Document management, access teams, allowing quick create are all examples of properties that can be turned on and off.
• Enable for mobile, allows you enable the entity for mobile and if you require mobile offline. Plus you can configure download filters to drive how much data will be available offline.

Note: These bullet points are not an exhaustive list! A good percentage of our revision time should focus on gaining a deep understanding of entities.

Managed Properties

The managed properties option lets you define how various properties can be managed if the entity is included as part of a managed solution. You may for example, restrict creation of new forms but allow creation of views. It is worth reviewing the options available here to appreciate what can be locked down.

If is also possible to select the “can be customized” option. Setting this to false would mean no properties can be customized if this entity becomes part of a managed solution.

Tip:
Notice I am using the classic entity management below!

Update ICONS

You can use the update icons option to assign custom icons to the entity if required. Notice that two icon files are required with specific sizes, 16×16 and 32×32 pixels

If you don’t set these custom entities get a “cog” icon by default.

Note: Icons will need to exist as web resources.

System v Custom Entities

Dynamics 365 contains many system entities such as account, contact, incident, opportunity, quote, order, invoice and so on. Often when we decide to make a customization the best option is to use an existing system entity. As much of the functionality you might wish to develop is then delivered using out of the box features.

Often terminology is all that is blocking the use of a system entity. One common example is the use of the term “Account”, as many companies might use a different term such as Organization, Partner, Client etc. When this happens it is often best to still use the account entity but alter the display name to fit whatever terminology is appropriate to a given situation.

Tip: If you change the display name of a system entity you may wish to also rename views and edit any system messages. (Using the messages option whilst customizing the entity.)

Keep in mind that some entities have a very close relationship to wider system functionality. For example, marketing lists can only contain accounts, contacts or leads. So if you want to leverage the inbuilt marketing lists you will need to hold the organisations / people you engage with in these system entities.

As a general rule it is always better to use an existing system entity in preference to a custom entity. (But as with all “rules” you will no doubt find exceptions to this rule!)

You do need to be aware that there are some limitations on customizing system entities.

On occasions when you wish to create something which is really quite different to any feature provided by a system entity creating a new custom entity provides you with ultimate flexibility.

System entities will already be included in the sample security roles that ship with Dynamics 365. As you create custom entities they will show in the custom entities tab of the security roles. By default, when you create a custom entity only the system administrator will have access to the entity. So you will always need to add a custom entity to a least one security role. (And also include the altered security roles in your solution.)

Entity Controls

We can also define a number of controls on entities and fields that allow us to define how controls appear on forms within the web application and mobile applications. For example, we can decide to enable editable grids.

When editable grids first launched I created a details post explaining how to configure them, you can see that here.

Deleting Entities

You need know the following things about deleting entities;

• You cannot delete system entities. (Although you can “hide” them by creative use of security roles or amendments to the site map / apps.)
• Custom entities can be deleted.
• You cannot delete a custom entity if other entities have dependencies on it. For example a look up to that entity. You would need to remove the dependencies before attempting the delete!
• If the entity you wish to remove is part of a managed solution you will not be able to remove it directly. You would need to remove the entire managed solution.
• When we remove an entity its definition is removed along with all the data records.

Hopefully this post has given you a good overview of the items you’ll need to revise around entities. However entities are a big subject and I have only scratched the surface here. Later posts will build on this introduction, additionally I encourage you to get as much hands on experience as possible in creating and maintaining entities. In particular become familiar with which features are available in make.powerapps.com and which are only possible in the classic interface. Enjoy.

I am creating a series of blog posts that collectively are designed to help anyone preparing for the Microsoft Dynamics 365 Customer Engagement Core exam. (aka MB-200) In this post I will look at concepts around fields.

You can see below that we have a section of the exam which covers managing entities and data. Within this section needing to know how to create and modify fields is referenced.

Fields Overview

Each CDS entity is made up of multiple fields. Fields are sometimes described as attributes by developers, the two terms are pretty much interchangeable.

• Fields are used to store values of defined types. (For example a piece of text, a number or a date.)
• Sometimes fields of the same type can have different formats. (For example, a text field can be optionally formatted as an email address, URL, phone number etc.)
• Fields appear as controls on forms. (Such as a text box, date picker, radio buttons etc.)
• Fields can also be shown in user and system views and can be used as part of queries. (Advanced Finds.)
• For each field a “column” is created in its Common Data Service (CDS) entity.
• Fields can be “simple” or calculated.
• Fields can be created that contain rolled up values from related entities.

You Dynamics 365 instance can include system and custom entities. The system entities will already comprise of many out of the box fields but we can add more custom fields as required. Although it is always a good idea to check a suitable system field doesn’t already exist before creating a custom one.

When a custom entity is first created some fields will get created by default. You can see below that I have created a test entity and shown it in make.powerapps.com. Notice that I have one field called “neil_name”. The “name” field is a default primary field. By default this will be called name and will be a text field of 100 characters. It will also be a mandatory field. (Note: If required the field name, length and requirement level can be customized when the entity is created.)

Note:
My field is prefixed with “neil_”. This is because my publisher has a prefix defined as “neil_”. If you use the default publisher your field will be prefixed with “new_”. I will cover the concept of a publisher in greater depth when we revise solutions!

Swapping to the classic entity maintenance screens will show me that actually many more fields get created!

Including things like created on, created by, owner and many more. I doubt you will need to know exactly what these fields are but even so it is worth creating a custom entity and before adding your own custom fields have a look. Below you can see that I have done just that. With a “basic” user / team owned entity I have 19 fields before I start adding any custom ones.

Also notice that a field called “neil_testoffieldid” has been created and this has a type of primary key. This is the “id” or GUID field of this entity, all entities will have a GUID.

Note: A GUID (global unique identifier) is a term used by Microsoft for a number that its programming generates to create a unique identity for an attribute.

Field Types

As mentioned that are essentially three types of fields, simple, calculated and rollup fields.

• Simple, these are “normal” fields that contain data not based on any formula. Examples include test, option sets, whole numbers etc.
• Calculated, contain calculations to derive their content. (Calculated form fields on the current or related parent entities.)
• Rollup, contain a aggerated value computer from the related records.

Note:
In this post my focus will be simple fields. I will cover calculated and rollup fields in more detail in later posts.

Each type of field will have a data type. You may need to know which data types can be applied to which field types. See table below;

Notice that some field types, such as lookup, can not be a calculated or rollup field.

Below you will find a table which gives a more detailed definition for each data type;

So far the screen shots I’ve used have generally been from the classic interface for maintaining entities. You need to be aware that we currently have two approaches to maintaining entities. The classic (old) approach and make.powerapps.com the newer interface. The screen shot below shows that pretty much all the same types are available it is just that the screen layout is different. The exception to this rule is the autonumber option on text fields. As this is only accessible in the newer make.powerapps.com interface.

Creating / Maintaining Fields

When we create a field the screen looks like this (whilst using the classic approach to maintaining fields);

For completeness the equivalent screen from make.powerapps.com is shown below;

The table below covers the detail of each field, as always I strongly recommend you experiment with creating different types of fields;

I have covered a lot of detail in these revision notes! Taking time to get some hands on experience of creating fields is really important. A great revision exercise might be to create a custom entity with one field of each type, you can then really appreciate the differences in all the varied types of fields.

Despite covering a lot of detail about field there is more to come! In future posts I will expand on the details here to cover calculated fields, rolled up field, global option sets etc etc.

I hope this post will have helped anyone preparing for the MB 200 certification.

I am creating a series of blog posts that collectively are designed to help anyone preparing for the Microsoft Dynamics 365 Customer Engagement Core exam. (aka MB-200) In this post I will look at concepts around calculated fields.

You can see below that we have a section of the exam which covers managing entities and data. Within this section needing to know how to create and modify fields is referenced. Whilst this statement doesn’t explicitly reference calculated fields I think it should be a good guess that we don’t need to just know about simple fields!

A calculated field, as the name suggests, is simply a field which is derived from a calculation. The calculations can include conditions and make use of fields on the current entity and related parent entity. They can work with number fields but also date calculations and string manipulation are possible.

The best way to learn about calculated fields might be to look at an example. For this I am going to be using the entity maintenance options found within make.powerapps.com.

Calculated Fields Example

Say I have an entity which contains someone’s salary and in another field I hold the tax amount they should pay. I might want to calculate their total salary after deducting tax.

Firstly I created salary and tax fields. These were “just” simple currency fields. Next I created a field called “Salary (After Tax)” I wanted that to be a calculated field. So, after setting the data type to currency I used the “Add” option to add details of my calculation.

Having clicked “Add” you may see a message like the one shown below. If you do you’ll need to click save to save any changes to your entity. This happens because the field must be saved before you can edit its associated calculation.

Next a popup dialog will show allowing me to define a calculation. In my example I simply entered the calculation as salary pretax less tax.

Note:
You can see below that my schema names are shown in the calculation section. You can actually type the display name to find these fields, so entering these details is real simple! Also, after entering a valid calculation you will need to select the “tick” icon to commit your change.

Tip: Something to consider is the data type of the field to be returned. If my calculation is going to work with currency, for example, I will probably need to return the result as a currency. If you try to create a calculated field that returned a text field or other data type then an error may be given and this could be prevented.

To demonstrate how this will work I have then added salary, tax and my calculated field to my form.

Once I have saved and published my change I can test it. See below that I have entered a salary of £10,000 and a tax amount of £2,000. The system has then calculated the post-tax salary of £8,000.

A couple of things to notice, firstly that the Salary (After Tax) field has a lock symbol. This denotes that it is read-only. Importantly you may also need to also be aware of when the calculation happens. Calculated fields are set when the record is saved. NOT when the data is entered.

NOTE:
The calculated value is also set when a form is opened or a value viewed in a list view.

This was a simply example, I hope you can already see that conditions and else actions could be added. To illustrate how this might work I altered the calculation. Firstly, I made it more complicated by adding an extra deductions field. I’ve also added a condition, which was based on a two option yes/no field. In my example this was to decide if a £10,000 annual bonus should be applied or not. My calculated field now looked like this. I hope this demonstrates how you could start to make the logic a little more complex.

Date Fields

There are a number of functions available with date fields. Some add hours, days, weeks, months or years to date fields.

There are also a set of commands to allow you to subtract from dates.

Tip:
Also notice below NOW(). This will return the current date time. Useful if you want to add or subtract days from the current date!

Meaning, ADDDAYS(2,createdon) would return a date two days after a record was created.

You can also calculate the interval between two date in minutes, hours, days, weeks, months or years.

String Calculations

Calculations are also possible with strings.

Use CONCAT to combine two strings. And TRIMLEFT or TRIMRIGHT to return the start or end of a string.

Including Fields from the Parent

I mentioned in my opening paragraph that you can reference details in the calculated fields from parent entities. To do this in your formulae enter the name of the lookup to the parent entity and then press “.”, this will present you with a list of fields from the parent entity that can be included in the calculation.

This is actually really useful to show data directly from the parent record on the child record. By way of an example, I have created a text field that contains the account name and city from the parent account on my entity.

You can see the result below from my Dynamics 365 form. I now have a field on my custom entity including the account name and city. This field is populated as a by product of entering (and saving) a value in my account lookup field.

Note:
Really usefully … changes to the details on the account record do get reflected in my calculated field. Meaning the information on the parent and my child entity will stay in step!

Tip:
Another tip is that a calculated field can include other calculated fields!

Hopefully this post has given you the information you need to understand calculated fields in preparation for your MB 200 certification. As always I encourage you to actually create a few calculated fields as part of your revision. Enjoy.

I want to add a label to a component (list) on my dashboard. I checked the option "Display Label on the Dashboard", and view selector=show selected views. I couldn't see the label. If I selected "view selector = off", then the label option is grayed out.

Could you please tell me how to use this feature?

Thanks in advance,

Hao

I am creating a series of blog posts that collectively are designed to help anyone preparing for the Microsoft Dynamics 365 Customer Engagement Core exam. (aka MB-200) In this post I will look at concepts around rollup fields.

You can see below that we have a section of the exam which covers managing entities and data. Within this section needing to know how to create and modify fields is referenced. Whilst this statement doesn’t explicitly reference rollup fields I think it should be a good guess that we don’t need to just know about simple fields!

When I reviewed calculated fields I showed how they could take data from the current entity or its parent. This is very useful but often you will have a requirement to work with information from child records. Imagine you have an entity called “Policy” and that is linked to an account. Each account could have multiple policies. It might be that you need to calculate the total value of all the policies for the account. To do that we’d need a rollup field.

As an example I have created a policy entity, given each policy a value and added that to my account. So on an account I can see the policies and their individual values. Below you can see that I have added a policies sub-grid to my account form.

Tip:
You actually creating a similar example as part of your revision will be a very valuable exercise! (For example, In my revision I used the new form design in make.powerapps.com to create my changes and learnt quite a bit along the way!)

Next on my account I created a new currency field that will hold the total policy value. Notice that I have set the field type to “Rollup”.

Having clicked Add you may get a message similar to the one below., This is because the field needs to be saved before you can add the rollup logic.

The details for rollup field looked like this ….

Notice that I have selected my policies entity as the related entity. I then said I want a sum of policy value. (Other options available to me are count, max, min and average.) This is important to remember as rollup fields typically work with numeric values. Whereas we saw that calculated values could also work with strings. (The exception to this rule is dates as you can perform some date functions using rollup fields, as we will see later in this post!)

In my simple example I left the optional filter section blank. But this can be used to filter record. For example: If some policy values were annual and some were monthly I could decide which to rollup into a monthly total and which into an annual total.

Also commonly in the filtering you might want to only include “active” records. As I might not want to include cancelled or expired policies which would be inactive records.

Tip: Notice the yellow warning which mentions the mass calculate system job.

Once I have saved my new field I can add it to the form. Creating this one field actually created four fields. Two fields are used to hold the policy value. “Total Policy Value” and “Total Policy Value (Base)” this was because I created a currency data type. All currency fields hold a value in the base and local currency. Although it is often true that these values contain the same value. (When the base currency and local currency are the same!)

It also created last updated on and state fields. These fields are needed as rollup values are not updated real-time, meaning that in some circumstances you will want to know when they were last refreshed. And if it was successful.

Having saved and published my change when I first opened my form it looked like this;

Notice the fields were initially blank. But clicking the refresh icon (aka calculator icon) forces a refresh and the total changed to reflect the values shown below.

Note:
If I had waited for 12 hours the fields would have been refreshed with me manually selecting refresh.

Note: There are some limited capabilities with rollup dates. For example you could find the earliest or latest date from a child entity. (Using max / min functions) To illustrate this I have shown a max date on the screen below.

When you create a new rollup field a process will run to roll them up 12 hours after the field is created. After that a system job will be fire every hour to keep them up-to-date.

Calculation of a rollup Field is a recurring job. The administrator can change the timing and frequency of the recurring jobs used to rollup fields.

To change the recurrence of a rollup the administrator needs to find the system job for the calculation, opens it and selects the option to modify the reoccurrence. Below you can see that I have opened systems jobs, changed the view to give me all rollup field calculation jobs. I then use the actions menu to display and edit the recurrence.

Note: Rollup fields are not available on many to many (N:N) relationships.

Note: Calculated fields cannot be include in the rollup calculation.

The rollup field has a status; this is general not required but is useful if you get unexpected results. The possible values of the status field are shown below.

Some considerations to be aware of are listed below;

• When you manually refresh a field the maximum number of records considered for rollup is 50,000. If you exceed this when rolling up manually an error will be given. However this limit does not apply when the automated system job is used to calculated the rollup value.
• You can define a maximum of 100 rollup fields for the entire organization.
• You can define a maximum of 10 rollup fields per entity.
• A workflow wait condition cannot use a rollup field.
• You cannot rollup a rollup field.
• A rollup cannot reference a calculated field that references another calculated field.
• The rollup can only apply filters to the source entity or related entities simple fields or non-complex calculated fields.
• Rollup fields do not support many to many (N:N) relationships.
• Business rules and workflows always use the last calculated value of the rollup field.
• The rollup happens under the system user context. Meaning all users see the same rollup field value, regardless of security roll.
• If the precision of the aggregated field is greater than the precision of the rollup field, the aggregated field precision is rounded down to the precision of the rollup field, before the aggregation is performed.
• Rollup field aggregation uses only direct relationships explicitly defined in the rollup field definition, no other relationships are considered.

I hope this post has fully explained rollup fields and covered all of the points you need to learn for the MB 200 exam.


I am creating a series of blog posts that collectively are designed to help anyone preparing for the Microsoft Dynamics 365 Customer Engagement Core exam. (aka MB-200) In this post I will look at concepts around entity relationships.

You can see below that we have a section of the exam which covers managing entities and data. Within this section needing to know how to create and modify relationships is referenced.

Overview

Understanding how to relate Common Data Service (CDS) entities to each other is a key concept when you are customizing a Dynamics 365 system. Within CDS / Dynamics 365 there are several ways to create a relationship between two entities and also multiple types of relationship.

The system entities that come preconfigured already contain many relationships but you can create additional relationships between system and custom entities. It is also possible to amend relationships to alter how they behave. As cascading rules define what will happen to child records when the parent is assigned, shared, deleted etc. For example, if we delete an account what will happen to all of the contacts associated to that account?

Relationship types include;

• One to Many (1:N) or Many to One (N:1)
• Many to Many (N:N)
• Hierarchical Relationships (e.g. Account and sub accounts.)
• Connections
• Customer

Tip: There is no such thing as a one to one 1:1 relationship!

Also, linked to relationships we have field mapping rules. These are applied when one record is created from another. For example, if we create a contact from an account the address, phone number and such like for the contact can be defaulted to the details from the account.

Note: In this post I am going to exclusively use the new maintenance experience we find a make.powerapps.com. If you have been using Dynamics for sometime you will no doubt be aware of the classic approach to maintaining relationships. The classic approach does still work but I encourage you to experiment with the newer interface.

One to Many Relationships (1:N)

One to many relationships are probably the most common type of relationship in any relational database. It is very common for a parent to have one child or multiple children. Examples of a one to many relationship would include an account having multiple contacts. Or a contact having multiple cases.

With a 1 to many relationship, the child record will have a lookup field that effectively contains the GUID of the parent. A contact for example will have a look up to the account entity.

FYI:
GUID stands for global unique identifier, it is essentially a reference that uniquely identifies any record in CDS.

Let’s look at a very simple example of a 1:N relationship. Below you can see then on my account I have a sub grid of contacts. Meaning each account (1) can have many contacts (N).

The contacts are the children of the account. On a child contact we can see that it has a relationship back to the parent. We see this in Dynamics 365 as a lookup field.

Many to Many Relationships (N:N)

With a many to many relationships the parent can have multiple children and the child can have multiple parents. One example of this might be competitors and opportunities. As there might be multiple competitors on one opportunity. And each competitor can exist on multiple opportunities. In this scenario on the opportunity we’d have a sub grid of competitors and on the competitor we’d have a sub grid of opportunities.

On the opportunity we see a sub-grid of competitors….

Then on the competitor we see a sub grid of opportunities ….

With many to many relationships we have two approaches to implementation. The first is described as a “native many to many” relationships. The link between competitor and opportunity is an example of a “native many to many relationship”. These are created simply using functionality available directly in Dynamics 365.

The second type of many to many relationship is called a “manual many to many” relationship.

Before thinking about a manual many to many it might be worth considering what is happening behind the scenes when you create a “native many to many” relationship. As the system actually creates a hidden entity that acts as an intersection between the two entities. Effectively each entity has a many to one relationship with the intersection. Which in turn effectively creates a many to many relationship. A manual many to many takes the exact same approach expect the intersection is manually created.

Manual many to many relationships are used when additional fields are needed to capture extra detail. Imagine we have an entity called events and another called delegates. Each delegate could attend multiple events and each event would have multiple delegates. But each time a delegate attends an event we might wish to capture some additional details about that booking. Such as any special instructions for dietary requirements, expected time of arrival etc etc.

When creating a “manual many to many” relationship we actually create an intersection entity. (Meaning it isn’t hidden and additional fields can be added.) The intersection entity will contain the GUIDs from both of the related entities plus any additional fields.

Note: You will often see the GUID field described as the Id field, the terms are interchangeable!

Connections

Connections are essentially a special relationship that allows us to link records in a “non-traditional” manner based on a connection role. Traditional relationships are “hard” relationships, such as linking a case to a contact. Connections are useful to record “soft” relationships, such “is a friend of”, “former employee of”, “went to school with” etc etc. Below you can see an example where my lead “John Smith” is a friend of “Tony Stark”, is influenced by me, has a child called “Paul”.

Additionally my lead has a former employer of “Blue Yonder”, if we look at the Blue Yonder account we can see that John smith is described as a former employee. Hence we can see that connection roles can have two sides.

Customer

Microsoft Dynamics CRM 2016 Update 1 introduced the capability to create a customer field on any system or custom entity.

“Customer” has been a special polymorphic relationship. For example, consider the customer field on cases. It is polymorphic because a customer could be an account or contact, so we can have one field that can relate to either entity.

This relationship always existed in older versions of “CRM” but it wasn’t until CRM 2016 Update 1 that customizers could create customer fields on any entity. It is now possible to create a customer field on any entity.

Below you can see that whilst working with a customer field I can select to filter the results to show contacts or accounts. Additionally the new record option or change view options will also prompt me to work with accounts or contacts.

Creating Relationships – One to Many

I have used the concept of a custom policies entity in previous posts, so I will stick with that as an example of how to create a one to many relationship. Say I want each account to be able to have one or many policies.

First of all, I navigation to the primary entity. In this example that would be account. So I open my solution (or from the default solution using the customizations option) and then find the account entity. Next I relationships and add relationship. Now I click “+ One-to-Many Relationship”.

Tip: I could have navigated to the child entity (policy) and added the relationship as a new “Many-to-one” relationship.

I can then define the details for the relationship. As shown below.

Once I have created the relationship, you can see below that a lookup field has been created on my policy entity. On the policy entity I could open this lookup field and change / review if the field is required, searchable etc.

Relationship Behavior

In defining my relationship, in the advanced option, I kept the behavior as referential. (the default). It is important you for to know that other types of behavior exist and you can tailor these as required.

Create Native Many to Many

Creating a native many to many relationship is actually very similar to creating a one to many relationship. Except the many to many relationship does NOT have any cascading rules.

Below you can see I have added a relationship between contact and my custom entity called policy. This would mean that each policy could be associated with many contacts. And each contact could be related to many policies.

Create a customer relationship

As already mentioned the customer relationship is a single lookup between account or contact. To create a customer relationship, navigate to fields and use the add field option.

Next set the data type of your new field to be type customer.

You can see below that it will create two relationships between account and contact. It will default the names for these relationships. Typically I don’t change these names but you could!

I hope this information will be useful to anyone preparing for the MB 200 exam. But as always I should stress that you can’t rely on theory alone to pass the exam. Getting hands on experience is also essential.

In future posts I expand on these concepts by discussing entity hierarchical relationships and connections. 

I am creating a series of blog posts that collectively are designed to help anyone preparing for the Microsoft Dynamics 365 Customer Engagement Core exam. (aka MB-200) In this post I will look at concepts around hierarchical relationships.

You can see below that we have a section of the exam which covers managing entities and data. Within this section needing to know how to create and modify relationships is referenced. (This could include hierarchical relationships!)

What is a Hierarchical Relationship?

A hierarchical relationship is used to reflect how one record in an entity relates to another. A good out of the box example of this might be how accounts can have parent accounts. Allowing us to create an account structure of head office, regional offices and branch offices. You can also create custom hierarchical relationships.

Hierarchical relationships are self-referential one-to-many relationships. (Self-referential as the account has a parent account.)

NOTE: Within Dynamics 365 we actually now have another concept of hierarchical relationship! This applies to contacts and can be used to show an organisation chart of contacts within an account. (So I will also mention that later in this post!)

When a record in CRM is part of a hierarchy you can see this in the list views. As a “hierarchy icon” is displayed next to the record.

Also on the forms for the entity an option will appear to view hierarchy and the “hierarchy icon” will also be present.

Selecting any of these options will give a graphical representation of the hierarchy. An example is shown below. Notice that the hierarchy can have multiple levels as a parent account can in turn have a parent account.

How to Create / Edit a Hierarchical Relationship?

Firstly, ONLY one relationship can be defined as being hierarchical on an entity. It also needs to be a relationship with the primary entity and related entity as the same entity.

For example, parent account on an account. As shown below.

Quick Tip: You will find that you cannot amend existing system relationships, meaning you will need to create fresh custom relationships. This came up recently for me! As the case entity has an out of the box concept of parent case. But this relationship is not marked as hierarchical and cannot be changed. Therefore to show a case hierarchy you’d need to create a new custom relationship.

Next we can use the hierarchy settings to define how this relationship will behave. Note, each entity has one entry for hierarchy defined. By way of an example the hierarchy setting on account is shown below.

Notice that I only have an edit option. If a hierarchy setting didn’t yet exist a New button would also display.

On the hierarchy setting we can see that the default quick view form is defined. It is this that decides how the “cards” in the organization view should appear. Whilst the hierarchy can’t be changed you can amend the hierarchy form or create a new form as required.

Note:
I am trying to use the latest interface for amending entities as much as possible! But I found I had to swap to the classic view to maintain the hierarchy settings. The newer make.powerapps.com interface is improving very quickly. By the time you read this you may be able to find these settings in that!!

I haven’t covered the concepts associated with forms. (yet!) So I will not discuss the form in detail! At this point it should be enough to know that in the hierarchy settings we define which quick view form will be used to display the tiles in the hierarchy. And that the fields shown on that form can be customized as required.

Org Chart

More recently a new view that makes use of hierarchal relationships has been added into Dynamics 365! The is the org chart view and works slightly differently to the traditional hierarchy view. In this case we have a specific need to see the relationships between contacts within an account.

An example org chart is shown below. (Sorry Avengers geeks, this chart might not be accurate!) Hopefully you can see this is a pretty cool way of showing the organization of contacts within an account.

Also notice that if I double click on a contact I can see (and edit) the details behind their relationships

I hope this post will have been an aid to anyone preparing for the MB 200 exam. But as always I would like to stress that you need to get as much hands on time as possible.


I am creating a series of blog posts that collectively are designed to help anyone preparing for the Microsoft Dynamics 365 Customer Engagement Core exam. (aka MB-200) In this post I will look at concepts around entity relationships.

You can see below that we have a section of the exam which covers managing entities and data. Within this section needing to know how to create and modify relationships is referenced.

Overview

Understanding how to relate Common Data Service (CDS) entities to each other is a key concept when you are customizing a Dynamics 365 system. Within CDS / Dynamics 365 there are several ways to create a relationship between two entities and also multiple types of relationship.

The system entities that come preconfigured already contain many relationships but you can create additional relationships between system and custom entities. It is also possible to amend relationships to alter how they behave. As cascading rules define what will happen to child records when the parent is assigned, shared, deleted etc. For example, if we delete an account what will happen to all of the contacts associated to that account?

Relationship types include;

• One to Many (1:N) or Many to One (N:1)
• Many to Many (N:N)
• Hierarchical Relationships (e.g. Account and sub accounts.)
• Connections
• Customer

Tip: There is no such thing as a one to one 1:1 relationship!

Also, linked to relationships we have field mapping rules. These are applied when one record is created from another. For example, if we create a contact from an account the address, phone number and such like for the contact can be defaulted to the details from the account.

Note: In this post I am going to exclusively use the new maintenance experience we find a make.powerapps.com. If you have been using Dynamics for sometime you will no doubt be aware of the classic approach to maintaining relationships. The classic approach does still work but I encourage you to experiment with the newer interface.

One to Many Relationships (1:N)

One to many relationships are probably the most common type of relationship in any relational database. It is very common for a parent to have one child or multiple children. Examples of a one to many relationship would include an account having multiple contacts. Or a contact having multiple cases.

With a 1 to many relationship, the child record will have a lookup field that effectively contains the GUID of the parent. A contact for example will have a look up to the account entity.

FYI:
GUID stands for global unique identifier, it is essentially a reference that uniquely identifies any record in CDS.

Let’s look at a very simple example of a 1:N relationship. Below you can see then on my account I have a sub grid of contacts. Meaning each account (1) can have many contacts (N).

The contacts are the children of the account. On a child contact we can see that it has a relationship back to the parent. We see this in Dynamics 365 as a lookup field.

Many to Many Relationships (N:N)

With a many to many relationships the parent can have multiple children and the child can have multiple parents. One example of this might be competitors and opportunities. As there might be multiple competitors on one opportunity. And each competitor can exist on multiple opportunities. In this scenario on the opportunity we’d have a sub grid of competitors and on the competitor we’d have a sub grid of opportunities.

On the opportunity we see a sub-grid of competitors….

Then on the competitor we see a sub grid of opportunities ….

With many to many relationships we have two approaches to implementation. The first is described as a “native many to many” relationships. The link between competitor and opportunity is an example of a “native many to many relationship”. These are created simply using functionality available directly in Dynamics 365.

The second type of many to many relationship is called a “manual many to many” relationship.

Before thinking about a manual many to many it might be worth considering what is happening behind the scenes when you create a “native many to many” relationship. As the system actually creates a hidden entity that acts as an intersection between the two entities. Effectively each entity has a many to one relationship with the intersection. Which in turn effectively creates a many to many relationship. A manual many to many takes the exact same approach expect the intersection is manually created.

Manual many to many relationships are used when additional fields are needed to capture extra detail. Imagine we have an entity called events and another called delegates. Each delegate could attend multiple events and each event would have multiple delegates. But each time a delegate attends an event we might wish to capture some additional details about that booking. Such as any special instructions for dietary requirements, expected time of arrival etc etc.

When creating a “manual many to many” relationship we actually create an intersection entity. (Meaning it isn’t hidden and additional fields can be added.) The intersection entity will contain the GUIDs from both of the related entities plus any additional fields.

Note: You will often see the GUID field described as the Id field, the terms are interchangeable!

Connections

Connections are essentially a special relationship that allows us to link records in a “non-traditional” manner based on a connection role. Traditional relationships are “hard” relationships, such as linking a case to a contact. Connections are useful to record “soft” relationships, such “is a friend of”, “former employee of”, “went to school with” etc etc. Below you can see an example where my lead “John Smith” is a friend of “Tony Stark”, is influenced by me, has a child called “Paul”.

Additionally my lead has a former employer of “Blue Yonder”, if we look at the Blue Yonder account we can see that John smith is described as a former employee. Hence we can see that connection roles can have two sides.

Customer

Microsoft Dynamics CRM 2016 Update 1 introduced the capability to create a customer field on any system or custom entity.

“Customer” has been a special polymorphic relationship. For example, consider the customer field on cases. It is polymorphic because a customer could be an account or contact, so we can have one field that can relate to either entity.

This relationship always existed in older versions of “CRM” but it wasn’t until CRM 2016 Update 1 that customizers could create customer fields on any entity. It is now possible to create a customer field on any entity.

Below you can see that whilst working with a customer field I can select to filter the results to show contacts or accounts. Additionally the new record option or change view options will also prompt me to work with accounts or contacts.

Creating Relationships – One to Many

I have used the concept of a custom policies entity in previous posts, so I will stick with that as an example of how to create a one to many relationship. Say I want each account to be able to have one or many policies.

First of all, I navigation to the primary entity. In this example that would be account. So I open my solution (or from the default solution using the customizations option) and then find the account entity. Next I relationships and add relationship. Now I click “+ One-to-Many Relationship”.

Tip: I could have navigated to the child entity (policy) and added the relationship as a new “Many-to-one” relationship.

I can then define the details for the relationship. As shown below.

Once I have created the relationship, you can see below that a lookup field has been created on my policy entity. On the policy entity I could open this lookup field and change / review if the field is required, searchable etc.

Relationship Behavior

In defining my relationship, in the advanced option, I kept the behavior as referential. (the default). It is important you for to know that other types of behavior exist and you can tailor these as required.

Create Native Many to Many

Creating a native many to many relationship is actually very similar to creating a one to many relationship. Except the many to many relationship does NOT have any cascading rules.

Below you can see I have added a relationship between contact and my custom entity called policy. This would mean that each policy could be associated with many contacts. And each contact could be related to many policies.

Create a customer relationship

As already mentioned the customer relationship is a single lookup between account or contact. To create a customer relationship, navigate to fields and use the add field option.

Next set the data type of your new field to be type customer.

You can see below that it will create two relationships between account and contact. It will default the names for these relationships. Typically I don’t change these names but you could!

I hope this information will be useful to anyone preparing for the MB 200 exam. But as always I should stress that you can’t rely on theory alone to pass the exam. Getting hands on experience is also essential.

In future posts I expand on these concepts by discussing entity hierarchical relationships and connections. 

Overview

The USD Accelerator is a pre-built Unified Service Desk configuration aimed at helping speed your USD project.

This post will highlight the enhancements and bug fixes released in version 3_0_0_0 of The USD Accelerator.

Several of the new features and bug fixes will have been created because of feedback received from people using The USD Accelerator. I’d like to express a big thank you for that feedback, please keep it coming!

Note:
This version of The USD Accelerator supports USD version 4.1.1319, the version which is currently generally available. Other versions of USD “should” work correctly as required!

You can find out more about The USD Accelerator here.

Enhancements

Support for Omnichannel for Customer Service Microsoft’s omnichannel product is supported within The USD Accelerator. After you have installed and configured Omnichannel for Customer service simply select a USD configuration that included omnichannel. Meaning “The USD Accelerator (Omnichannel)” or “The USD Accelerator (Omnichannel and QGate)”. Use the QGate version if you wish to also enable QGate’s Intell-CTi product! Once enabled agents will have access to the omnichannel agent dashboard and will be able to accept chats generated within Omnichannel for Customer Service.

Canvas app added for phone call reminders A canvas app has been created then when loaded will show any due or overdue call backs. Clicking on a phone call will start a session showing the phone call and related entity. Note: Whilst this app works it should be noted that the performance can be slow. I will continue to attempt to improve the performance. Until then this should be considered a POC. Several options control the use of this canvas app …. ReminderCanvasApp …. Set this open to “Y” to enable the reminder canvas app. ReminderCanvasApp_Popup …. Will popup the app each time all sessions are closers. (If any call backs exist). It is recommended that this option be set to “N”. (Until I have improved the app performance!) ReminserCanvasAppID… This is the GUID of the canvas app. Each time a canvas app is imported into an instance it will have a unique app ID. You will need to find and copy your unique ID into this option to make the reminder app load.

Added ability to warn on session close A UII option controls this session close behaviour. It is recommended that the “WarnCloseSession” option be set to “Y”. Set this to “N” to disable the close session prompt.

Updated style of birthday notifications The style of the birthday notification has been improved to better fit with USD / Dynamics 365. The birthday notification feature can be enabled / disabled using the “NotifyBirthday” option.

Updated style for credit hold notifications If an account or contact is opened who is on credit hold a notification can be shown. The style of this notification has been improved to better reflect the latest Dynamics interface. The credit hold notification feature can be enabled / disabled using the “NotifyCreditHold” option.

Added opportunity show regarding option When an opportunity is loaded its regarding contact and account will be automatically loaded. To enable this feature the “ShowOpportunityRegarding” option must be set to “Y”.

Supports USD version 4.1.1.1319 The USD Accelerator now ships with Unified Service Desk v4.1.1.1319, the current version. Note: Later versions (as they become available) are expected to work! But the V3 package deployer will install this version as installing the USD Accelerator. The USD Accelerator v3 has not been tested with earlier versions of USD!

Paribus Support Paribus is a product from QGate. You can use the link below to find out about it; https://www.paribuscloud.com/ Paribus uses a cloud service to provide enhanced searching capabilities, including “fuzzy search” logic. It can also aid duplicate detection. Paribus can now be used to search for contacts, leads and accounts in The USD Accelerator. To use Paribus search, firstly simply install Paribus search from QGate. See, QGate’s website for details and additionally request a free trial! Once Paribus is working within your Dynamics instance you simple use the “QGateParibus” option to enable it.

Rename Case Entity It is already possible to have alternative names for account, contact and lead entities. This functionality has been extended to include cases. Simply use the “NameCase” and “NameCases” options to define the singular and plural names you’d like to use.

Search existing Cases When trying to resolve a case we can already search the knowledge base and even trigger a bing / google search. An additional option has been added to also help you search existing cases. The search capability means that related cases can be opened into another tab. Allowing the agent to continue working on the current case whilst reviewing old cases for tips on how to resolve the current instance of an issue. For this feature to be enabled the “SearchExistingCases” option must be set to “Y”. Once enabled , on the case navigation toolbar a search cases option will appear. Now a case search tab will open in your session, any cases opened from this tab will show in a related cases tab. Meaning the current active case can stay open whilst the agent reviews old related cases for resolution ideas.

View Org Charts in tabs On the account entity we have options to view the hierarchy charts or org charts relating to the account. Previously these would not open in The USD Accelerator! Now selecting these chart options will open the chart in a separate tab.(As shown below)

Multiple Forms Support AN earlier version of USD meant that the multiple forms control was not supported with the Chrome or Edge browsers. At that time multiple form support was removed from The USD Accelerator. Multiple forms now work correctly and are supported on the following tabs; Websites Feedback Competitors Related Cases USD History For these tabs you can open multiple records and quickly swap from page to page. Below you can see an example of this on the websites tab. Opening multiple webpages provides a drop down and the agent can swap from page to page. Additionally an “x” is added to the navigation toolbar. Clicking this will close the current page but leave the others open. (If the last page open is closed the tab will close!)

I am creating a series of blog posts that collectively are designed to help anyone preparing for the Microsoft Dynamics 365 Customer Engagement Core exam. (aka MB-200) In this post I will look at concepts around dashboards.

In the skills measured statement (shown below) under the heading “manage user experience design”, you will see a reference to dashboards.

In this post I will focus on the dashboards available to us in the core Dynamics 365 product. But you will also need to be aware the that we can view Dynamics 365 data on a PowerBI dashboard or include visualizations from PowerBI on a Dynamics 365 dashboard.

There are actually three styles of dashboard in Dynamics 365.

• The classic dashboard
• Interactive experience dashboards
• PowerBI Dashboards

What is a dashboard???…. Dashboards are personalized pages. Just like your car dashboard they provide a snapshot of key information in an easy to access format. Dynamics 365 dashboards typically include charts and list views but you can also add iframes, web resources, Power Bi charts, Social  Insights etc.

In addition to simply viewing data it is also possible to interact with the information presented. For example, you can drill into charts on a dashboard in exactly the same way as you can from list views elsewhere in Dynamics.

As with charts and views there are two types of dashboards. System and personal.

Personal Dashboards

• Users can create personal dashboards.
• Initially only the user creating the dashboard can see it.
• Personal dashboards can be shared with other users and teams.
  • When sharing dashboards, it is important to ensure that all personal charts and views contained in the dashboard are also shared.
  • Sharing does not break any of the security model rules. You are sharing the dashboard not the underlying data!
• Classic dashboards can be personal dashboards.
• Interactive dashboards cannot be personal dashboards.
• PowerBI dashboards can be personal dashboards.

System Dashboards

• Out of the box various system dashboards exist by default.
• System dashboards can be created by developers with the system customizer or system administration roles.
• System dashboards can be made available to all users or have access restricted based on security role.
• Model driven apps may include all or a restricted number of dashboards.
• Classic dashboards can be system dashboards.
• Interactive dashboards can be system dashboards.
• PowerBI dashboards cannot be system dashboards.

As the image below shows, out of the box Dynamics 365 ships with multiple system dashboards. Some have a customer service focus and some concentrate on sales. Others are specific to optional Apps within Dynamics 365, such as Field Service, Project Service and Microsoft Social Engagement. Assuming you are using the new Unified Interface you will find that each app will contain a specific set of dashboards relating to that app. Loading the sales hub, for example, would typically show you the sales activity and sales performance dashboards.

Having clicked on a chart on dashboards three icons become visible. (Two accessible from the “…” option.) These allow the chart to be refreshed, opened using the view records option (showing the related records) and expanded to fill the screen.

Interactive Dashboards

I really like interactive dashboards! When they were first introduced into Dynamics 365 their focus was probably more aimed at service scenarios, as they were initially part of the interactive service hub. These days, they are included in the Unified Interface and can be applied to any part of Dynamics 365.

The concept of an interactive dashboard is that you will have a primary view and filtering date. In a service scenarios this might be used to show things like open cases created this week. With a sales hat on, we might do things like showing open opportunities by their expected close date. (I’ve done exactly that to show as an example below.)

On an interactive dashboard we have a number of charts (visual filters) and then one or more streams (or lists!). The streams / visualizations are interactive. Meaning as I click on a visualization, the other charts and streams will filter to reflect the data selected.

Below you can see that I have clicked on a particular phase and rating. And my dashboard is now showing the data filtered by these elements. Additionally the ribbon bar and other navigation elements. As I can do things like hide / show the visual filters, swap to a tile view (showing totals) or edit the date range used to filter the dashboard.

There are multiple types of interactive dashboards …

1. Multi-stream interactive dashboards
2. Single-stream interactive dashboards
3. Entity-specific interactive dashboards

Multi-stream Interactive Dashboards

Multi-stream dashboards show in the “normal” dashboards option. For example the “Tier 1 Dashboard” found in the Customer Service Hub app is an example of a multi-stream dashboard.

The Tier 1 Dashboard includes details (streams) for case, emails and activities. We could have multiple streams (views) from one entity or several entities in a multi-stream dashboard.

Single-stream Interactive Dashboards

The single-stream dashboard contains the data stream on the left and visual filters and tiles on the right. They are focused on a single stream. Meaning you might use them when the users work needs to be more focused.

For example, in my tier 1 dashboard (multi-stream) I might be interested in all case regardless of status and also any open activities I have. But when using the single stream tier 2 dashboard I would want to focus in on just active cases.

Entity-specific interactive dashboards

We access entity specific dashboards from the “open dashboards” option on a view of the entity. For example, below you can see that I have opened cases and used the “…” option to see the “Open Dashboards” option.

The entity specific dashboards perform like the multi-stream dashboards we find else where in Dynamics 365, except all the streams are from a single entity. Meaning they are focused on a single entity. An example for cases is shown below. I have multiple streams but that all relate to cases. (So, my active cases, resolved cases and active cases.)

Creating Personal Dashboards

Let’s look at how to create a personal dashboard. These can be a classic dashboard or a PowerBI dashboard. I will cover PowerBI in a separate post. Below you can see that selecting new allows to create a “Dynamics 365 Dashboard”. (aka a classic dashboard.)

Whilst creating a new dashboard the user can select one of 6 templates, as shown below.

Once the template has been selected you can add …

• charts
• views
• relationship assistant
• ifames
• web resources
• social insights
• PowerBI tiles

As you select to insert components a dialogs will prompt for the required details. As an example I have shown the dialog for adding a chart below.

Sharing Personal Dashboards

It is possible to share personal dashboards with other users and teams. (Just like charts and views.) Simply select the SHARE DASHBOARD option in the ribbon bar.

The sharing dialog will then appear. It is worth knowing that the process to share views (advanced finds) and charts is pretty much the same. Users and teams can be added and then you select the privileges as required. By default, just the “Read” privilege is given but you can ass additional access permissions as required.

An important tip about sharing is that if you have added any personal charts or views to the dashboard you will need to also share each of those separately.

It is also important to be aware that the Dynamics 365 security roles apply. Sharing does not allow you to circumvent the role based security model. When sharing dashboards, views and charts you are only sharing the view. You are not sharing access to the underlying data.

For example:
If you share a dashboard with a sales person that contains cases and they don’t have access to cases, they would not be able to view that section of the dashboard.

Creating System Dashboards

We create system dashboards in a very similar manner to personal dashboards. Except only developers with system customizer or system administrator roles have access. When customizing the system, we have a dashboards option that gives access to existing system dashboards and allows the creation of new ones.

We currently have two user interfaces for customizing Dynamics 365. The old “classic” method for maintaining solutions (shown below) and the new Unified Interface style which is available at make.powerapps.com.

Tip: The options available in make.powerapps.com are improving all the time. Eventually it will include all of the options available to us in the classic experience. For example, already in Oct 2019 I can maintain all dashboards from make.powerapps.com. I have only found a need to revert to the classic experience when creating new dashboards! And even that I assume will change soon. So I encourage you to try make.powerapps.com first.

I will try to focus on the newer style approach! But it is worth knowing that currently (Oct 2019) I can only create Interactive Dashboards in the classic interface. (Therefore I may reference both interfaces below!)

When creating a system dashboard (in the classic UI), we have two options, dashboard and interactive experience dashboard. The first being the “traditional” dashboard the second being those available in the Interactive Service Hub.

Once you have selected the dashboard layout, from this point on the process is pretty much the same as creating a personal dashboard. (Expect you will need to remember to publish the dashboard once it has been defined!)

As we saw earlier, in my system I can add PowerBI and Microsoft Social Engagement visualizations to my personal dashboards. With system dashboards I cannot add PowerBI Visualizations. Meaning only 5 icons are available to me when building a system dashboard.

One key difference with system and personal dashboards is that their access can be controlled based on user roles. Using the enable security roles option. As shown below we can enable the dashboard for all roles or select specific roles. Below you can see that I have selected a system dashboard and then used the “…” option to access the enable security roles option.

Having selected “enable security roles”, I can pick the role or roles who can access this dashboard. (Or select the “display to everyone” option.)

Adding system Dashboard to Apps

With the Unified Interface we have a concept of apps. An app is essentially as set of entities, forms, views (etc) that makeup a sub-set of functionality a user will access to complete a particular job function. We can opt to include all dashboards or specific dashboards as required.

Within PowerApps we have two types of App. Model-driven apps and canvas apps. In this context we are talking about model-driven apps.

Below you can see that I have selected the model-driven apps in my solution. I can then select an app and use the edit button to access it.

Once the app is loaded I can click on dashboards and decide which ones to include. These maybe classic dashboards or interactive dashboards.

Creating Interactive Dashboards

We currently create interactive system dashboards from the classic customization options.

As a customizer we can created interactive dashboards from two locations. Firstly we have the dashboards option. Below you can see that in the classic experience I have a dashboards option. And from here I can create new interactive experience dashboards using the new option.

For the entity focuses interactive dashboards I navigate to the entity and then select the dashboards option for that entity. (As shown below.) The experience of creating an entity focused interactive dashboard is very similar to that of creating a normal multi-stream dashboard. It is just that you access the creation / maintenance of these dashboards from a different start point.

When creating an interactive stream dashboard your first task (as with other dashboards) is to select the layout. Notice that we can have different layout depending on the type of dashboard being multi-stream or single-stream. (FYI, entity focused dashboards are always multi-stream.)

I have shown an example screen of how this shows below.

Firstly we set a number of mandatory fields

Having set my mandatory fields. I simply cadd a number of visualisations (charts) and streams (views).

You may find the link below useful when learning how to configure interactive experience dashboards!

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/customize/configure-interactive-experience-dashboards

I have covered quite a bit of information around dashboards! I hope this is useful when revising for the MB 200 exam. As part of your exam preparation I suggest you include plenty of hands on time, creating and using both system and personal dashboards. And to also test the classic and interactive styles. Enjoy!

I am creating a series of blog posts that collectively are designed to help anyone preparing for the Microsoft Dynamics 365 Customer Engagement Core exam. (aka MB-200) In this post I will look at concepts around views.

In the skills measured statement (shown below) under the heading “manage user experience design”, you will see a reference to views.

Note: My intention is for these notes to serve as a useful revision aid. But please do focus your preparation on having quality hands-on time with the Dynamics 365 application.

Forms show one record at a time whilst views are used to present lists of records. Views can be included in dashboards or when we simply navigate to an entity within Dynamics 365. Below you can see that I have navigated to accounts and been presented with the “my active accounts view”.

Views can be included on forms as sub grids, for example a list of contacts on an account form. (As shown below.)

We also see views when we search for data in Dynamics 365, for example as we filter results from a lookup field. (As shown below.)

Below I have shown the My Open Opportunities and you can also see the numerous system views available out of the box. It is also possible for end users to create personal views. (Advanced Finds) This can be done from the advanced find icon in the navigation bar or by selecting the “Create View” option in the command bar.

Tip: The list of views will always show system views first, scroll down the list to see your personal views at the end of the list!

Also note that users can also use the “Create view” option to create a personal view based on the filtering they have applied to the current view.

Views can be grouped into three categories.

• System-defined (or Special) views – special views applied to built-in features of Dynamics 365, can be customized but cannot deleted. Such as Advanced Find View, Quick Find View etc
• System views – System views are “public” views available to all users, they can be created and customized. However some can’t be deleted because they have dependencies or are managed as they have specific associated functionality.
• Personal views – personal views are advanced finds that users can create and share.

Beyond the user capabilities of creating (and sharing) personal views, developers can also create system views. You see personal views and system views separately when viewing lists of views. All system views show under a heading of “System Views” and my personal views under a heading of “My Views”.

Tip:
Notice that under the System Views and My Views headings the views are displayed in alphabetical order. This cannot be changed! Each Dynamics 365 app can include all system views or a selection of system views. Everyone with access to the app will see all of the views available in that app. (I’ll cover maintenance of apps in another post!)

System View Types

In addition to personal views, there are actually multiple types of system views which have different purposes. Below I have shown the views available on an account and highlighted some of the different types. Including associated views, advanced find view, public views, quick find views and more.

Tip: As part of your preparation try amending each type of view. What can you change and what effect do your changes have??

• Public View– “General” views that will show when the user selects views on an entity. Such as “Accounts I Follow” or “Active Accounts”. All users with access to the entity will see all the available public views. Meaning there is not a concept of ownership to the views themselves. (Unlike forms which can be role based.)
• Default Public View– This is the “general” / public view that the user will see when they first open an entity. You can only have one default view.
• Advanced Find View– The system view used when looking up records using the advanced find option.
• Associated View– By default this is the view shown when associated records are displayed.
• Lookup View– When we lookup Dynamics 365 records this is the view presented. (Say from an ID field on a CRM Form.)
• Quick Find View – Displayed when trying to find records within Dynamics. Also includes an option to define the search columns.

The quick find view also has an impact on the relevance search and multi-entity search. The find columns defined will be used for these searches and the first three columns selected are the ones you will see returned in the results.

Creating / amending a System View

If you navigate to the required entity in your solution or in the default solution via the customizations option you will be able to select the views option to see and amend existing system views. Or select the “New” option to create a new view.

Tip:
An alternative approach to creating a new view is to open an existing view and use the save as option to create a copy.

As you can see above, having selected “Add view” you must enter a name for your view (which can be changed later) and optionally enter a description. The description serves no functional purpose but does aid later understanding of why this view was created and it is supposed to show.

A
screen similar to the one below will display next. If you are familiar with advanced find this format will already be familiar to you. Options / capabilities include;

Fields– the fields I could include in the view are listed on the left hand side of the screen. These can be dragged into the view as required. The related tab lets me include fields from related entities. For example, I could show the mobile phone number from the contact defined as my primary contact.

Name / Description– I will have entered these earlier and can be changed.

Filter by– I will show this in more detail soon but here we define the required filtering.

You can also change the width and sequence of columns simply by expanding them or dragging them in the view preview.

Tip:
The view maintenance screen I have shown below is found at make.powerapps.com. This is the newest experience for customizing Dynamics 365. You may be familiar with the classic maintenance options! If you haven’t used the new experience I encourage you to try it out.

Below you can see that I have added a filter to my view. In my simple example I have looked for all accounts with a city as London, Kingswinford or Birmingham. I have also included a filter to only return accounts that have a primary contact. You can of course make the filtering more complex by using more and / or groups. And also like advanced find in background the system will be storing the query as fetchXML. (Although I don’t see or need to see this code!)

Keep in mind that the columns you filter on do not have to be present as view columns in your view. For example, here I am only showing open opportunities. So there would be no value in adding the status field as a view column. (As it would always show the same value!)

One of the many nice things about the new view editor is that I can see a preview of records to be returned as I create my view. This helps me tailor it exactly to my needs.

After publishing the change, the new view will then be available. My example view is shown below.

Tip: If the modal driven app you are using is configured to include all views then your view will show. If it only has selected views you may need to adjust the app to grant access to the newly created view.

Tip: After publishing the change you often need to refresh the screen in the browser for the new view to be seen. As the page needs to be reloaded.

Quick Find View

The quick find view is shown when we search for records. Either from the search box within an entity or using the multi entity search.

Note:
The category search and relevance search don’t look like a views! But they are showing the first three columns from the quick find view. (Plus the name field.)

When we open the quick find view we can see an additional option not present on other views.

The “find by” section lets us define which columns will be included in any search. Doing so will add an index to the SQL database to help make the searching fast.

Tip: You might be tempted to select all columns! This might not be a good idea as the results returned could be confusing to users as matches could occur that aren’t expected. You need to make a balance between selecting as many columns as required but not so many that the solution returns confusing results. PLUS, performance would be impacted by having so many indexes. Because of this there is actually a limit of 20 “indexed” columns when adding find columns. Also any fields which are longer than 900 characters will not be indexed.

Editable Grids

Dynamics 365 introduces a new concept of editable grids. These change the nature of views! Previously views were always read-only but now users can edit data directly in the view. To enable editable grids we need to add a control and decide if the editable grid will be available in web client, phone and or tablet.

I have previous blogged about editable grids in some detail. You can view that post here.

You may also wish to review Microsoft’s documentation on editable grids …

https://docs.microsoft.com/en-us/powerapps/maker/model-driven-apps/make-grids-lists-editable-custom-control

Deleting System View

You will be able to delete any public view that you’ve created. Assuming it has no dependencies. By that I mean it isn’t being used as a sub grid on any forms.

You will not be able to delete “special” views. Those being things like “Advanced Find View”, “Quick Find View” etc.

You can also not delete system views automatically created by the system.

Tip:
When you delete a view that delete is not “carried” by a solution. What I mean is that when I import a solution into another Dynamics organization the removal of views (or anything) doesn’t take effect. You need to be mindful of this when removing views in a development environment as the views may also need to be manually removed from production! (I’ll cover solutions in another post!)

I hope this post will have given anyone preparing for the MB 200 exam the basics they need to know about views. As always, I would like to remind you that getting hands on experience as part of your preparation is essential. You can’t rely on theory alone.

I am creating a series of blog posts that collectively are designed to help anyone preparing for the Microsoft Dynamics 365 Customer Engagement Core exam. (aka MB-200) In this post I will look at concepts around Microsoft Flow.

You can see below that we have a section of the exam which covers integration. Within this section needing to know how to create, execute and share flows is mentioned.

What is Microsoft Flow?

Microsoft Flow is a trigger based system for creating automated workflows (aka Flows). Like “traditional” workflows, Flows can be used to automate tasks with Dynamics 365 data. But unlike traditional workflows, Flow can leverage hundreds of other connectors. Off the shelf connectors include Salesforce, SQL Server, Twitter, DocuSign, Slack, Skype, SharePoint and many more. A connector is an API proxy that allows these services to connect to Microsoft Flow. Developers can even create custom connectors if an off the shelf connector doesn’t already exist!

This concept of connectors allows us to use Flow to integrate with multiple data sources. I could for example, create a contact in Dynamics 365 each time someone adds a contact into Salesforce.

Flow is a massive topic and one I’m obviously not going to be able to cover fully in a single post! My focus is here is revision for the MB 200 exam, so I will attempt to cover some of the basics I believe we might need to revise for the exam. But as always I really encourage you to gain as much hands on experience as possible. Flow is a really cool tool so you should have fun with this experimentation!!

In addition to Microsoft Flow we also have “traditional” workflows in Dynamics 365. I will cover those in a separate post. Although you should note that when we create traditional background workflows, Microsoft give us a friendly hint that maybe we should consider using Flow. If you aren’t using Flow yet … maybe now is a good time to start!!

Creating Flows from Templates

In my opinion, one really good way to learn about the capabilities of Flow is to experiment with the many standard templates that are available. Templates allow us to quickly create Flows based on an outline someone else has previously created.

Below you can see that within make.powerapps.com I have selected the “My flows” option. Then when I create a new flow I can use the “Create from template” option.

There are hundreds (maybe thousands) of templates! And more are being added all the time. Below you can see I have searched for the word “Dynamics” ….. loads of templates have been returned.

When you select a template you’ll see an image depicting what the Flow will do and maybe some additional narrative. Additionally you will be warned what connections will be used when creating this Flow. For example, below you can see I have selected a template that will send a survey whenever a case is resolved in Dynamics 365. To make this template work I’m going to need access to Dynamics 365 (or more specifically the Common Data Service related to my Dynamics 365 instance) and access to Microsoft Forms Pro.

To use this template before clicking “Continue” I will need to sign into Forms Pro. Plus when I click continue I’ll select which of my Common Data Service environments I wish to connect with. (Aka my Dynamics 365 instance.)

What I’d like you to start to appreciate is what components make up a typical flow. A flow must include a trigger and at least one action.

All our flows start with a trigger. There are many triggers! But some common ones include users manually clicking a flow button, records being created or records being updated. You can see in our template below that this flow is triggered when a case is updated.

Having defined our trigger we can then define the actions we’d like the flow to conduct. A common type of action is known as a control action. These include conditions and even loops. (Loops might include “Apply to each” or “Do until”.)

There are loads of different actions we could make use of. In our example below other actions include getting a record and triggering the send of a Forms Pro survey.

I’ll mention some more triggers and actions later in this post. For now, I hope you can see the overall structure of a Flow. And you also appreciate that creating a flow from a template will not only be useful but will also allow you to experiment with some of the many capabilities of Flow.

Triggers

All Flows start with a trigger! So let’s have a look at some common triggers. Below you can see that I’m creating a Flow from blank and my first step is to select my trigger. In the screen shot below you can see that I’ve searched for common data service triggers.

Notice that we can trigger a flow when a common data service record is updated, deleted or created. Additionally we can trigger a flow when a record is selected. (I will explain more about the select concept later in this post.)

Whilst the focus of this post is an overview of Flow from a Dynamics 365 point of view, it is important to keep in mind that we can trigger a Flow from many other sources. For example, below I have shown the outlook triggers. Meaning I could trigger a Flow when an email arrives, an event created etc.

Buttons

So we have seen that Flows can be triggered from updates to common data service records. It is also possible to create a flow button to manually trigger a Flow. Below you can see an example Flow … this one includes a button.

Optionally clicking on a button can prompt the user for additional information. I have shown this by prompting the user to enter a “Browser Type”. Obviously they could enter any attribute you like!

We don’t really need to worry about what this example Flow actually does! This is actually a Flow I often use to change the “Browser Type” field held on records in my Unified Service Desk configuration.

What is important here is that I’m just trying to show that I can click a button to trigger my flow!

I find triggering Flows from buttons really useful when using the Mobile Flow application. I end up with buttons in the mobile app that when clicked would do various productivity tasks. You may have noticed that the above flow includes a notification to my mobile device. Meaning I click the button, it updates a load of records and then sends me a notification when its finished. Running Flows like this manually can be a real time saver!

On Demand Flows

You may recall earlier I mentioned the ability to run a flow when a record is selected. This is known as an on demand flow. Anyone already familiar with traditional workflows may be aware of the concept of an On Demand workflow.

Before you can run On Demand flows (or workflows) you may need to check your system settings. As under the customizations tab in system settings we have an option to enable flows in the site map.

Once enabled you will see a Flow option in the command bars in Dynamics 365. This option will let you run any traditional workflows defined as on demand workflows and any flows that will be triggered on select of the common data service records.

Note:
In my testing I found that only flows created under the “My Flows” option showed here! Ones I created within the solution worked but any “on select” Flows didn’t show.

My flow was a really simple example. (Maybe you can create something similar or better.)

My trigger was “when a record is selected” in CDS. And I associated this with the contacts entity. Then I simply updated the contact to have “(Updated)” at the end of their last name. Obviously this isn’t a useful Flow, I created it just to show how we can run flows when a record is selected!

After selecting multiple contacts I can now pick my Flow. A dialog (shown below) will display and if I want to continue I can click “Run Flow”.

After my flow completed, I needed to refresh my view to check the change had taken effect. After my refresh, “(Updated)” has been added to the end of the contact name.

Scheduled Flows

Another useful trigger is to schedule a flow.

Say I want to perform a particular action once per day. Or week etc. Here I can select a recurrence trigger and define the interval / frequency as required.

I have specifically mentioned scheduled Flows as they can be really useful. You may need to know that the ability to schedule “jobs” doesn’t exist with out of the box traditional workflows. So this is something Flow can do that workflows can’t.

Actions

I have already mentioned a few actions in the examples above. As we add our steps into a Flow we add actions. Actions may allow us to update records, send emails, trigger notification etc etc.

Each connector may provide a number of custom actions that can be preformed on the connected data source. To give you just one simple example, the “MSN Weather” connector provides us actions to get the weather forecast for today, tomorrow or now. (As shown below.)

Below you can see another “silly” example! Here once per day I’m getting the forecast using MSN Weather. Then I create a task in Dynamics 365 to tell everyone the weather.

In this example you can see a concept I’ve used but not mentioned yet … “Dynamic Content”! Dynamic Content is essentially the variables returned by other actions that we can then use in our Flows. For example, having run the “Get forecast for today” action I have dynamic content including fields like the weather conditions, chance of rain etc.

Sharing Flows

When I create a flow it is typically “My Flow”. I can however share the flow with other users. (See “Share” option below.)

Below you can see that I’ve shared my flow with another user. This gives them full admin style access to my Flow. Meaning they can make any changes as required.

Additionally I can list users who will be “run only” users. Meaning they can run my flow but not edit it or manage its connections etc.

Sharing might be what you want but other options for distributing Flows exist. One being the “Send a copy” option. Here I can send a copy of m flow to other users in my organisation. Doing so will send them an email. Within the email they will have a button to create a new flow using the copy flow I sent as a template. This is slightly different to sharing as they’d end up with their own copy based on your flow. (Meaning their changes wouldn’t impact your flow!)

Additionally we have export and import options. These allow us to export a copy of the Flow and import it into another instance or tenant. These options are useful for moving a Flow from one environment to another.

And it is also possible to include Flows in Dynamics 365 solutions. Meaning Flows can then makeup part of your Dynamics solution / app. They can be exported from say a development environment and imported into production using this approach. I will cover solutions in more detail in a future post. But below you can see I have a solution that includes several Dynamics 365 entities plus a Microsoft Flow. This allows me to migrate not just my Flow but a whole set of changes from one environment to another.

Note:
If we want a Flow to be part of a solution we must create it from within the solution. We cannot create the Flow under “My Flows” and then add to a solution!

Summary

I have quickly covered loads of “stuff” in this post. My goal here wasn’t to try to teach you everything about Flow but instead to flag the topics I feel you should probably revise for your MB 200 exam. Including;

• What is a Flow – an automated workflow with many types of Triggers and Connectors.
• Flows can be created from templates.
• Triggers include, buttons, selecting records (on demand), updating records or Flows can be run on a scheduled basis.
• Flows can connect to the Common Data Service.
• Many other connectors exist for various external applications.
• Developers can create custom connectors if the required connector doesn’t already exist.
• Flows must include a trigger and at least one action.
• Actions can be things like updating records but they can also be control actions. Including conditions and loops.
• Dynamic content can be used within actions.
• Flows can be shared with other users.
• You can send a copy of a Flow to other users.
• Flows can be exported / imported.
• Flows can be included in solutions.
• Microsoft suggest we use Flows in preference to traditional background workflows.

I am confident there are loads more things for you to learn about Flow but I hope I have covered at least some of the key facts you’ll need to know for your MB 200 exam. I hope you enjoy your revision, get loads of hands on practice!