Recently I gave a presentation regarding Omnichannel for Customer Service at 365 Saturday in Paris, afterwards I was asked a question about the files customers might send in webchat conversations. In this scenario a large volume of attachments were expected and these would need to be managed. Therefore they wanted to know where the attachments were stored. In this post I hope to answer that question and more!

After the event my flight back to Birmingham was delayed … meaning, thanks to “flybe” I had some unexpected spare time!

Whilst waiting for my plane I experimented with how attachments are stored. In the end my flight was delayed for longer than I expected …. so I also investigated other data relationships connected with Omnichannel for Customer Service. In this post I will answer the original question and give some additional insight into the entities behind Omnichannel for Customer Service.

So lets start with my original question “How are attachments stored from webchat conversations?“.

Within The Omnichannel Administration app we can define if file attachments are required. And if these can be sent by customers and / or agents.

I think the person speaking to me in Paris was right to ask a question about this! As in some scenarios customers might routinely send multiple pictures of issues. This could quickly consume large amounts of disk, so knowing the location of the attachments would allow us to monitor storage and delete the images after a period of time. (or maybe move them into a cheaper storage location.)

Below you can see a screen shot from my Omnichannel Administration app, this shows how I’ve configured the chat to allow file attachments to be sent by the customers and agents.

The simple answer to the original question is that a note is created regarding the conversation with the customer. This note will have an attachment that contains the file sent by the customer or the agent. I guess it would be a pretty simple task to create a bulk deletion job to remove all notes linked to conversations older than “n” weeks or months.

If you don’t know, within Omnichannel for Customer Service we have an entity called “conversation”. Its schema name has the more catchy name of “msdyn_ocworkitem”. After each chat is completed a conversation record will be created and this will link to other information. For example, the files transferred as part of a conversation.

But I also spotted additional notes being created! So whilst waiting for my delayed plane I started to dig a little deeper. Another entity called transcript is also linked to the conversation entity. Each transcript entity will have a note which contains an attachment called “message.txt”. This txt file contains some JSON which in turn holds the content (transcript) from my conversations. Knowing this exists and that you could therefore access the content of the conversations might be very useful.

Incidentally when I looked at the JSON it also contains the GUID of the note containing the attachment from my conversation. Meaning my transcript and any attachments are indirectly linked via this GUID.

Tip: You might also want to consider when to run a bulk delete against the notes containing conversation transcripts. Do you really want to store all the text from all your webchat conversations indefinitely!

With my delay worsening I bought a notepad and pen from a trusty airport stationery shop. I then completed multiple webchats and started to scribble details for any other entities that had been updated. You can see my carefully crafted and completely illegible notes below!

Obviously these scribbles were hard to understand and I’d quickly forget what they meant! So this morning I created a version of them using Visio, as a result I hope the diagram below will make a little more sense.

In addition to looking at how notes are used in connection with conversations I also investigated ongoing conversations, sessions, sentiment analysis and characteristics (skills).

Importantly: I never set out to document all of the entities / fields connected with omnichannel conversations! But I did end up reviewing more than I expected! So this post shouldn’t be considered a complete picture but will still hopefully give you some useful insights into how omnichannel conversations are stored.

Ongoing Conversations
– the ongoing conversations entity (msdyn_liveconversation) holds details for the current active conversations. Including the status of the conversation, when it started, current active agent and sentiment. I believe knowing this could be really useful if you wanted to report on the number of current conversations or maybe trigger alerts when very negative conversations happen.

Sessions
– Each session is linked to one or more conversations. Often you will have just one session record and one conversation. But if the same conversation is opened and closed multiple sessions will exist. Sessions might be really useful as they link to another entity called session participants. The participants being the agents that were involved in that part of the conversation. Sessions could be complex! For example, Agent one might start the conversation, then consult agent two about the issue and finally transfer to agent three. And whilst this is happening a supervisor might monitor the chat. All of this complex process could be reviewed via the sessions entity.

Sentiment Analysis
– We have a conversation sentiment entity but additionally optionsets on other entities also highlight sentiment information. For example, it might be useful to know that the current sentiment of a live conversation is held in the ongoing conversation entity!

Characteristics (aka skills)
– skills based routing has been recently added to Omnichannel for Customer Service. We can define skills for agents and workstreams. This information is then used to match the best agents to the right incoming conversations. We also have a number of entities that record which sessions and conversations involved what skills. You might find this useful for reporting, as you could ask questions like “which conversations have happened that needed agents with xyz skill”.

Below are my rough notes for each entity; (Again this shouldn’t be considered complete documentation, these notes are just some pointers!)

In the end my flight left Paris and my “work” was cut short. Hence this post only covers a partial picture of the Omnichannel for Customer Service entities. I guess there will be more I could learn by digging even further …. maybe I’ll use Ryanair next time and “pray” for an even longer delay!!

Note: Other unreliable budget airlines are available!!

Until my next delayed flight I hope this information answers the question I was set and offers a few extra pointers!

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 forms.

You can see below that we have a section of the exam which covers managing the user experience and within that the need to know how to create and configure forms is referenced;

Download Skills Measured Statement!

I do often “bang on” about the need to check the detail of the skills measured statement. The reason is that it gives a detailed statement of everything you can expect to be covered in the exam. I strongly encourage you to always check the latest statement and prior to taking the exam ensure you are comfortable with everything mentioned. This is essential as Microsoft do periodically make changes to the exams and revisions could be mentioned!

For example, in November 2018 they revised the MB 200 exam making a number of changes, including the need to know about the app designer and article templates.

You can access the certifications page from the link shown below;

https://docs.microsoft.com/en-us/learn/certifications/exams/mb-200

Within the certifications page you will find a link to download the skills measured statement. Before taking the exam I encourage you to download the latest statement ….

Before we dive into concepts around forms I’m going to make one more comment! Your prep for the MB 200 exam should (or must) include as much hands on time as possible. This statement is very true when we talk about form customization, reading theory is great but it is not a substitute for hands on experience. Having said this let’s look at the exciting topic for form customization ……

Forms

Model driven apps are tightly linked to data. A model driven app is made up of a number of entities, amongst other things each entity has a collection of fields, views and forms.

Forms are the main interface for users as they are how users will interact with Dynamics 365 on a day-to-day basis. I stress this to highlight the importance of good form design as the users are going to need screens that are a pleasure to use. All users have unique requirements and in some circumstances you may need multiple forms (on one entity) to support the specific needs of particular users. User adoption is key to the success of every “CRM” project and I would argue that user adoption is very dependent on them enjoying the experience of working with forms.

Form Types

There are several types of forms in Dynamics 365. The main one include;

• Main Form– the main entity forms typically used in browser. But can also be seen in outlook and CRM mobile clients.
• Quick View Form – These offer a simplified view of parent record information that can be added to child forms. (And also used in hierarchy views.)
• Quick Create Form– Short versions of the form used for record creation, typically used when creating a child record in context of a parent.
• Card Form – These are compact forms used in views for Unified Interface apps.

Each entity can have multiple versions of each of these form types. Sometimes access to alternative forms is control by enabling them for specific security roles and other times the users are left to select the version they feel is most appropriate at any moment in time.

Below you can see that I have opened the account entity in make.powerapps.com, within the forms option we can see the existing forms for this entity and add new ones as required.

Components of a Main Form

Before we start to look at how to customize a Unified Interface form it is important to understand the component parts of a form. To try to explain these I’ve shown the main account form below.

Form Designer

Below you can see what the account form looks like whilst we customize it in the form designer. This interface gives us the ability to drag and drop fields on to appropriate areas of the form, making positioning fields a very simple process.

You really need to “play” with the application at this point! .… Try moving fields around and adding new ones. As well as adding tabs / sections and sub grids.

Below I’ve shown an alternative form designer! Yes we have two!! The form designer shown above is form the newer interface you will find at make.powerapps.com. It has a key advantage that the design screen shown will more closely represent the final result.

Below I’m showing the classic form designer. I suggest you actually experiment with both as part of your revision. You can access the classic form design by using the “Switch to Classic” option in the ribbon bar of the power apps form designer.

Tip:
I often use the newer designer to move fields around my form, add sections etc. But when I need to complete slightly more complicated maintenance then I currently revert to the classic form designer. This is because the classic form design contains features that aren’t yet included in the new experience. BUT, I do strongly recommend that you keep returning to the new experience. Dynamics 365 is evolving quickly and I’m confident that in the fullness of time the new designer will provide a superior form designing experience. This does mean that the following notes will include a mixture of screen shots from the new form designer and the classic one. Sorry!

Notice the field explorer on the right hand side of the form designer, it is from here that I can drag new fields onto the form. (The new form designer has a similar concept but the fields can be found on the left hand panel. Confused yet!!)

Also notice that a useful tick box exists to show all fields or just those not yet included in this form. It is also possible to create new fields directly from the field explorer by clicking the “New Field” button.

As you experiment with the classic form designer, also notice the “INSERT” Tab. From here we can add tabs and sections to the form. We can also insert “special” controls including sub-grids, quick view forms, bing maps, notes and more.

With the new experience we have the “Add component” option which provides similar functionality to that of the insert button on the classic designer. (Although some minor differences exist so I encourage you to gain some hands on experience!)

There are several options available for tabs (and sections). As tabs can have one, two or three columns and sections can have 1,2,3 or 4 columns.

And when more than one column exists on a tab several properties are available for the layout. By default the columns in a tab will be of equal size but you can set properties to define specific widths if required.

Note:
It is not possible to control the widths of columns within a section!

Note: The following details are mainly based on the experience you’ll find from the classic form designer. Some features may not (yet) be available in the newer designer.

From the classic designer “Special” options on the INSERT tab include;

• Sub-Grid, allows me to add a sub grid of records from a related entity. Such as a list of contacts for the account.
• Spacer, simply inserts a gap on the form. Sometimes useful if you want to force a field into a specific position or just create some “white space” on the form.
• Quick View Form, use this option to insert a quick view form for another entity.
• Web Resource, allows the insertion of web resources. (Technically creation of web resources is beyond the scope of the MB2-712 exam but will may need to know this feature exists.)
• IFRAME, iframes are effectively web pages that can be inserted into the form.
• Timeline, add the timeline control to a form.
• Bing maps, supports the addition of the Bing mapping controls.
• Navigation link, when customizing the navigation area this option allows you to add a link to a custom url or web resource.
• Social insights, when using Microsoft social Engagement, you add social insights to forms.
• Timer, a new feature to add timers to forms. Useful when an SLA is being applied to the entity.
• Knowledge Base Search, on entities enabled for knowledge search this option will add the search control to the form. (Note: Can also be added as an option in the social pane.)
• ACI Control, This is an Azure Customer Insights control (aka Microsoft Customer Insights), at the time of creating these notes this feature was in preview and not fully implemented.

Tip:
Sub-grids support using access teams with entities. An access team is a special temporary team that allows us to grant access to individuals on a record by record basis. Below I have shown as example of adding an access team to an opportunity. Notice that the entity is Users and that I have selected the team template to apply. You will find more information on access teams in this post. (In which I describe the security model including access teams.)

The HOME ribbon also contains some important options.

• Business Rules allows business rules to be created straight from the form. I will cover business rules in a separte post.
  
• Preview allows us to get an idea of what the form is going to look like without leaving the form designer.
  
• Enable Security roles allows us to assign this form to all roles or specific roles.
  
• Show dependencies allows us to see any components that depend on this form or are required should the form be added into a solution.
  
• Managed properties lets us define what can be customized should this form be included in a managed solution.
  
• Merge Forms allows us to merge older style forms with the latest layout. Any missing visual elements from the older form will be added to the end of the current form.
  

Am important option to be aware of is the Form Properties option on the HOME ribbon. I am not going to cover this in detail! As JavaScript code is “probably” beyond the scope of the MB-200 certification. But it is here in the form properties option that we can create and link libraries of JavaScript code to form events. Making this an important option as you start to extend Dynamics 365.

Multiple Forms

Below you can see that from within customizations we can have multiple forms of multiple types for each entity. For example, we have multiple quick view forms on the account that would be used in different circumstances. Selecting new will present an option to decide which type of form to create.

In the classic view also notice that the ribbon bar contains an option to enable security roles to forms.

An important concept here is the fall back form. As that will be the form visible to users whose security roles do not have any forms explicitly assigned to them.

The form order can be defined; this is important as should the user’s role give them access to multiple forms then the form order will dictate which is displayed by default. Users can have multiple roles that might therefore give them access to multiple forms. Their default form will be the first one found for a role assigned to them. Each “set” of forms will have its own form order definition.

Using the form order option to move forms up / down in the ordering may therefore effect which form is presented to a user.

Quick View Forms

Quick view forms provide a read-only view of data. A quick view form can be inserted into another form.

The logic is that a quick view form on a child record can show the details of the parent record.

For example, above we saw that an account form may include a quick view form for the primary contact. Meaning we could view details for the account s primary contact on the account form.

You can see the form designer for a quick view form below, firstly notice that all fields on the form have a lock symbol. This is because the form is always read-only. Also notice that only a one column layout is supported and we don’t have any tabs / sections.

We have less options available in the “add components” option of a quick view form. We can only add one column sections and no tabs.

But we can add a subgrid. Meaning I can display a list of record associated to the parent record. For example, on the contact I could show a subgrid of leads linked to this contact. Meaning a user could be looking at an account but also viewing details of leads created for the primary contact on the account. This is a really neat feature that I encourage you to try out!

When we add a quick view form into a main form we define a number of parameters, including the lookup field on the main form to use and the related entity type.

Tip: If you scroll down! … In the additional properties we have an option to control how the quick view form is rendered.

Below you can see that I have changed my contact quick view form to render as a card. I really like this option! As by rendering as a card the entity image also shows and our form has a more modern “feel”.

Quick Create Forms

In many respects the quick create forms share the same layout “restrictions” as quick view forms. In that they contain no tabs and only one column sections. But their use is very different!

Quick create forms are only opened when creating new records, therefore the fields they show are maintainable.

Importantly quick create forms only apply when we are creating a new record. Maintaining an existing record would be done from a main form.

Also, for quick create forms to show the associated entity must be enabled for quick create. (There is a property on the entity!)

Below you can see how the quick create form shown above appears in Dynamics 365.

I have covered a lot information about forms quite quickly! And I recognise that having two designers (currently) may increase the number of combinations you’ll need to test out. But hopefully you have found some useful nuggets of information in this post! I have only briefly touched on some topics so trying some of them out as part of your preparation is essential.

I hope this post has helped people preparing for the MB-200 exam and I hope you now enjoy some hands on time with the product. 

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 the app designer.

You can see below that we have a section of the exam which covers user experience design. Within this section we can see that the site map and app designer are mentioned.

Tip:
Notice that the “implement App Designer” heading is shown in red! This is because in November 2018 the MB 200 exam was revised to explicitly mention the app designer. This perfectly demonstrates why I like to encourage people to always check out the skills measured statement. As things can change!! You can access the skills measured statement for the MB 200 exam using the link shown below.

https://docs.microsoft.com/en-us/learn/certifications/exams/mb-200

Introduction

From Power Apps we can create three types of apps! Canvas Apps, Portals and Model-driven apps. For the purpose of this post my focus is model-driven apps as Dynamics 365 is “mainly” a model-driven app.

Model-driven apps comprise of all the entities, forms, views (and more) that make up you Dynamics 365 application.

The App Designer can be used to create task-based “model-driven” apps. Often users will find the full navigation of Dynamics 365 daunting, Apps can be used to only show just the sections of the Dynamics 365 that are relevant to them. Imagine you have a user who only needs to work with the contact and cases entities, the concept of an app is to give them just the required options and as a result provide them with an easy to navigate application.

An APP is effectively a collection of related entities, dashboards, and business process flows. Which provide the user with a tailored experience.

In previous versions of “CRM” we would have often only controlled what entities would show for a given with security roles. And when more customizations were required we’d directly make changes to the site map. Alterations to the site map required a developer to export a solution, edit the resulting XML and then re-import. This process was time-consuming and not intuitive. The App Designer now provides the ability to quickly edit the site map without this complexity. It contains a rich interface that allows advanced configuration of the site map without the need for any XML knowledge.

Apps can form part of your Dynamics 365 solution and can be enabled / disabled for specific roles.

Users can access apps from the navigation bar or directly as each app will also have its own URL.

Creating a model-driven App

There are many options available to us whilst creating applications, in this simple overview I may not cover every option!

Note: These are revision notes for the MB-200 exam not a full training guide! I therefore encourage you to experiment with creating some applications to learn the full capabilities.

From make.powerapps.com we can create new apps or amend existing ones. This can be achieved from the “Apps” option (shown above) or by opening a suitable solution and accessing the apps within that solution. Personally I would always edit an app in the context of a solution!

Having selected the option to create a new model-driven app, either from the apps option or from your solution …. You will now give the App a name, notice that a unique name will be automatically assigned. (the unique name will be given a prefix from your solution publisher. In my case this meant “neil_”. If you haven’t set a publisher yours might be “new_”.)

I have then given a description. (Notice that this might show under the app image in your app tiles.)

The solution will have a default image but you can change this. You can see that I have uploaded an image as web resource and then used that. (My image is 64×64 png.)

Importantly notice the Unified Interface URL. User will be able to pick the app but they can also navigate directly to it using the url shown.

We also have options to base this new app on an existing app. (Doing that might save you loads of time!)

Now the app designer will load and I can begin the process of building the application. Within the App Designer I am going to define four things;

• Site Map – the site map is the main navigation areas that will be available
• Dashboards – the dashboards to appear in the app
• Business Process Flows – which business process flows will be included
• Entities – what forms, views and charts will be presented

As you use the designer, you will add required components. Then click save. You can now select the validate option to receive any information about incorrectly configured items. And once any issues have been resolved you can use the publish option to make the app live.

Possibly the first thing you will want to create will be the site map. The site map is essentially the areas, groups and sub areas available within the app. The area is the main navigation. (Shown at the bottom of your app in the Unified Interface.) Each area can then have one or more groups. And each group has one or more sub area items. The sub area items can be dashboards, entities, web resources or urls. You can see a simple example below that highlights the various areas of the side map.

The designer screen used to create the above app is shown below. I have selected the sitemap option and then dragging areas, groups and sub areas into my sitemap as required. Each of these will have properties that you define in the properties tab on the right hand side. For a sub area, for example I will select a type of dashboard, entity, web resource or url. And then continue to define which entity etc etc.

As I add entities (etc) into my site map they may be added automatically into the app designer view. Below you can see that the account, case, contact and opportunity entities are showing, this is because I added them into my site map.

Notice that next to each entity I (by default) get all forms, views, charts and dashboards for that entity. You might want to change that!

As you add components, you’ll enter options for each one.  For example, on entities you’ll select the required Forms, Views, Charts and dashboards. To try to illustrate this I have selected my accounts entity. Then by selecting forms I can use the components tab to either include all forms or just specific ones.

Also notice that we can control which dashboards and business process flows are visible in this application. It is a common task (for me) to select just the dashboards the target users would need. Why show them everything when all they want is access to one or two dashboards???

Whilst creating your app you can use the validate option. This may trigger a number of warning or dependencies messages to display.

Say you select a form that has a sub grid from another entity, this will show as a dependency. If you deploy this app into another environment you will need to ensure all of the required dependent components exist or the deployment will fail.

You may also get warnings that you haven’t restricted the forms / views on an entity. As it might be common to want to only present the user with the views and forms they require.

Having validated your app and fixed any errors you can publish it. Obviously you can publish an app with warnings!

Once your app is published, users will be able to access it in the My Apps area of advanced settings, from the side navigation or by direct access using the apps unique url.

Apps can be made available to all roles or specific security roles. Use the manage roles option to access a dialog to control which roles can see this application.

https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/customize/manage-access-apps-security-roles

Below you can see the dialog to manage roles. (Notice that I can amend the app url if required.)

Tip: As I created these notes several “guides” told me to select the “My Apps” option in advanced settings. That has worked for me in the past. But I found the “My Apps” option wasn’t present for me. So, as an alternative …. In make.powerapps.com under apps, select your app. Then click “Share”. Here you will see details on how to share the app. Including a reference to the “my apps” page. Clicking on the “my apps” link will load it. (This solved my problem of it not being in the navigation of my advanced settings!)

https://docs.microsoft.com/en-gb/powerapps/maker/model-driven-apps/share-model-driven-app

I hope I have covered the key points connected with Apps that you will need to be aware of for the MB-200 exam. As already mentioned the App Designer is very powerful, I therefore encourage you to include a significant amount of hands-on practice as part of your exam preparation.

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 discovery, planning and analysis.

There is a section of the MB-200 exam which has a focus on discovery, planning and analysis, the associated skills measure statement is shown below.

Introduction / Overview

I think we can clearly see that with these newer exams Microsoft is trying to measure our real-world skills as well as our technical knowledge. I do like this shift in emphasis as just knowing a bunch of technical facts doesn’t make someone a better functional consultant! This shift in emphasis “feels” more apparent for this section of the exam than any other!

Many of the topics may seem fairly easy for an experienced battle-scarred consultant but newer consultants with less projects under their belt may find this section more of a challenge.

Many of us work for Microsoft Partners, meaning we will be allocated to numerous organisations and participate in many projects. This will result in us being exposed to multiple approaches to running projects. Each approach is typically adapted to meet the scale of the project and size of organisation. Also in my experience, I ‘ve found certain industry sectors may have more or less governance. For example, a customer from the financial sector is likely to be required to comply with a raft of rules that might not be present in “simpler” less regulated environments. This regulation and governance typically results in extra documentation to demonstrate our compliance. (And also additional auditing to check that compliance!)

The overall project management approach could also play a part. For example, with a traditional waterfall project we’d define all the requirements upfront. (Possibly in great detail.) Whilst in an Agile project it could be considered more typical to “allow” the requirements to evolve as the project progresses. But Agile is not an excuse for skipping any documentation or best-practices! Agile would simply mean that requirements would be defined and refined in a more interactive manner, the need to record these requirements and our decisions around their creation would remain.

The commercial basis of the project may also influence the documentation and processes we’ll follow. Say we are working on a fixed price deal …. commonly in this scenario a set of features to be delivered will be agreed between the supplier and the customer then a fixed price agreed. Change in all projects is inevitable but every change in a fixed price deal may have a scope and therefore cost implication. In projects like these maintaining a change log is absolutely essential!

I guess what I am trying to say is that there isn’t a one size fits all when we start to look at how we engage with customers. And therefore the quantity and detail of documentation we might expect can vary drastically. But there will be some common themes and best-practices that we might expect to see in all projects. And even if we don’t always follow these best-practices we should be aware of their existence.

Having said all this, we do still have a few statements that are knowledge based. For example, “select between managed and unmanaged solutions”. In this example we will need to understand the difference between managed and unmanaged solutions and be able to appreciate when each might be used.

In the following sections I will give some narrative on the topics mentioned in the skills measured statement. Then, for some topics I will create additional blog posts to dive deeper.

In the following sections I will attempt to give you an introduction into the concepts connected with each of the following;

• Entity Diagrams
• Mock-ups
• Data Migration / Integration
• Determine OOB Functionality
• Validate Functional Requirements
• POC
• Collaboration Tools
• Perform an Audit
• Change Logs
• Managed and Unmanaged Solutions
• Entity Components

Entity Diagrams

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 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.

A properly drawn ERD 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.

You can read more detail about Entity Relationship Diagrams here.

Mock-ups

Users often find digesting and correctly interpreting sizable requirements documents a challenge. Mock-ups of screen designs can be a great way to help ease this pain. As seeing what the final application will look like really helps them visualise the end result.

In my experience we have at least three variations on the mock-up theme;

1. Sketch / Rough outline– sometimes rather than having a detailed mock-up a simple drawing giving a “representation” of the screens maybe all that is required. If this is done final decisions on who the forms look and feel maybe needed during the build process.
2. Wireframe – the term wireframe normally suggests some level of automation to show how the flow from screen to screen might operate. Potential users would be able to clink on “links” and see how the transition from screen to screen might “feel”. With Dynamics 365 model-driven apps the navigation around the app is generally pretty standard. Hence, in my opinion, the effort of creating a wireframes maybe unnecessary. Although some exceptions may exist! For example, you might be creating a Dynamics 365 Portal when a Wireframe could prove really useful.
3. Detailed Mock-ups– A detailed mock-up would be an accurate representation of the expected form. It would include no logic and wouldn’t function as a form but would give the users a very clear image of the intended screen design.

Mock-ups can be created using tools such as Visio. (Other tools are available!!) Usefully a quick Google search should help you find a number of Visio stencils that include the common controls we find on Dynamics 365 forms. Using these stencils will really speed the production of any mock-ups.

In simpler projects I have often created “mock-ups” by quickly creating a rough version of the actual screen. (Just with no business rules, JavaScript etc.) I do this as the form designer is really easy to use! Although we potentially start to enter a grey area with this approach …. as when would you consider your form mock-ups to actually be a prototype or proof of concept!

Data Migration / Integration

Data migration and integration are very closely related! However data migration would typically be a one-off or infrequent task. Whilst integration suggests a frequent and ongoing requirement.

When moving from a legacy system into Dynamics 365 we may need to migrate data from the old system. Often, Dynamics 365 will then become the master data source. (Meaning this would be a one-off task.)

Data integration, however, suggests an on-going link between two systems. It maybe that an organization already has a number of “satellite” systems these might feed Dynamics 365 with data. Or maybe you need to export data from Dynamics 365 to populate the existing systems. The frequency and complexity of the required integration may suggest a number of different technical approaches being required. For example, in simple scenarios an infrequent manual export / import of data could suffice. But in more complex scenarios an automated near real-time approach may be required. (Which could suggest some significant development effort!)

Below I will try to highlight some common challenges / concerns with data migration and integration;

Tools – it will be important to select the right tool for the job. With Dynamics 365 online we cannot directly write SQL that will access the data therefore any data operations must happen through the SDK. Several options are available;

• Export / Import Utility – Dynamics 365 has an import feature which can be used to import data from various file formats. (Including CSV, txt and xlsx.) Often a spreadsheet might be used allowing the review of data before import. This approach is easy but is probably best suited to simple or infrequent requirements.
• DIY – your developers can create a custom migration / integration package using the Dynamics 365 SDK.
• 3rd party utilities – there are a number of utilities that allow developers to create the ability to handle large datasets. Kingswaysoft and Scribe are just two examples of these.

Data transitions– when moving data from system A to system B we may need to transform the data. The entities or fields held in the source system may not always neatly map to the target system. To give you just one “simple” example, consider a contact’s name. In Dynamics 365 this is typically held as separate first name and a last name fields. But your source system may contain a single name field. If this was the case you might need to decide how to split your names into the separate first name and last name fields. You will need to complete an analysis of the source ERD and Dynamics 365 ERD to decide what transitions are needed. The level of complexity in the expected transitions may influence your choice of the right tool for the data import!

Archive– during a migration process it maybe a fantastic time to consider archiving (or simply deleting) old redundant data. I have often come across legacy systems “stuffed” with data which will never be used. Data storage is not free! And holding really large volumes of data could also have an adverse impact on performance. Therefore taking decisions around what data not to migrate may be essential. Additionally you should consider how to prevent the new system ending up in the same state! So define data retention policies maybe prudent. (Tip: Dynamics 365 does include a bulk delete feature which could be used to frequently delete records of a certain age. For example, you may decide to delete any unqualified leads older than “n” months.)

Cleanse / deduplication– Duplicates can be a common problem in all databases. Plus data quality can be a challenge. During the migration process it is often common to need to decide how to identify and resolve duplicates. Dynamics 365 does include a merge capability to merge duplicates. But if you are migrating large volumes of data an automated approach may need to be considered and built into your migration solution.

Regulatory concerns– regulations change! I have come across legacy systems that contain data which doesn’t comply with the latest privacy regulations. For example, if you are holding leads / contacts for marketing purposes and you don’t have the required consent levels to engage with these people then maybe a migration project might be a good time to purge this data.

Data Governance– data should be tested! In a one off migration this might include a number of automated and manual checks on data volumes and quality. But with data integration you may need to consider on-going checks to ensure data integrity is maintained. Data governance is potentially a technical challenge and also a significant business challenge! When multiple systems and business functions are involved, who controls the master records or who owns the overall responsibility for the data quality can be complex topics.

Configuration Data– most of the above will have been focused on business critical data such as accounts, contacts or orders. But you may need to also consider configuration data. Most systems will include many sets of reference data. Including things like country codes, currencies, product types and much more. It maybe important to move this data not just from one system to another but from multiple instances. By this I mean moving the configuration items from development, to test or production copies of Dynamics 365. As part of the SDK, Microsoft do provide a configuration migration tools for this purpose. You can read about it here.

Hopefully you can see that data migration and integration can be a complex topic. This link from Microsoft docs might help you gain further insights.

Determine OOB Functionality

Dynamics 365 contains loads of out of the box (OOB) functionality, as a general principle I always encourage customers to use OOB features in preference to custom development. A few reasons are;

1. Speed – using an existing feature means potentially complex development efforts can be avoided. It is almost always quicker to use an OOB feature rather than developing a custom one. (faster also equals cheaper!)
2. Simpler future support – if you use OOB entities then other experienced Dynamics 365 consultants should find it easy to understand how these operate. And will therefore be better placed to offer you support / guidance.
3. Future updates – Dynamics 365 is a cloud based service that receives frequent updates. Say you are developing a ticketing system …. you could create a custom entity called ticket or you could use the case entity. If you decide to use case you will not only benefit from all of the existing features but also any future ones! For example, I saw this happen when Microsoft released the enhanced SLA feature with cases. My customer who was already using cases could immediately start to use this new feature with no development effort. If they’d implemented a custom “ticket” entity this wouldn’t have been possible.

Sometimes you might need to be creative in how the Dynamics 365 entities are used. Say the company you work with has a subscription service and they always talk about people who are “members”. When you hear this don’t assume a members entity would be required! You could simple use the existing contacts entity and maybe have a contact type of member. Or maybe you could even rename the contact entity to be called “Member”. Renaming entities is a common way for you to use OOB features but represent them using the terminology the business is familiar with.

When a new requirement is presented also consider if an existing Dynamics 365 feature or app exists that you could now be used. For example, you may receive a requirement for customers to be able to enter self-service support requests. You could develop a custom approach for them to be able to log and view cases on the customer’s website. Or you could simply deploy a standard Dynamics 365 Portal.

The ongoing challenge for all consultants is being aware of potential features. We should avoid re-inventing the wheel simply because we weren’t aware that the required feature already existed. So keeping our knowledge current is essential. Keeping our knowledge current can be a dauting task but Microsoft do publish a product roadmap that should help us. You can view that here.

Validate Functional Requirements

Establishing, documenting and agreeing functional requirements can be a challenging (and fun) task. On countless occasions I’ve worked with users who don’t really know what they want …. they might simply know that they want a system to improve their processes. Users understand the business need to offer better customer service or reduce costs but they may not have a vision of the functionality required to realise these objectives.

As a functional consultant you’ll need to leverage multiple approaches to help identify and agree the features required to deliver the stated business objective. Often this will include running multiple workshops with potential users.

It may even be that the existing processes aren’t well understood. Meaning we may find a need to document the “as is” in addition to the “to be”.

If you’re working in a Agile environment user stories will often be useful to document and validate functional requirements.

A user story is the smallest unit of work in an agile framework. A user story is an end goal expressed from the software user’s perspective. The purpose of a user story is articulate how a piece of work will deliver value back to the customer. User stories are also the building blocks of larger agile frameworks, like epics and initiatives. Epics are large work items broken down into a set of stories, and multiple epics comprise an initiative. Typically each user story will be associated with a number of acceptance criteria. These help the users understand the excepted result of the feature being developed and also importantly act as an invaluable aid for testers to check the developers work. All user stories typically follow a standard format …. “As a [persona], I [want to], [so that].”

Tip:
Don’t discount user stories if you are working on a Waterfall project! A user story is simply a template for defining a requirement and should be a concept that can be applied in any scenario.

One of the challenges we have as functional consultants is ensuring our intended users have understood the feature we are describing. And also that we have correctly interpreted the original requirement. User stories can help but other techniques such as mock-ups or proof of concepts can also help validate our understanding.

POC

Proof of concept (POC) systems are often used to demonstrate that a new feature will work. This might be to prove that a new technical feature is achievable or maybe to test that the business process can actually benefit from the proposed system. I like to think of a POC as a disposable prototype.

A proof of concept system may help validate a ground breaking idea without building the complete solution. Often it is better to build a POC and fail quickly than waste countless development hours on a bad solution.

Often a POC system will be built quickly and might therefore exhibit quality issues. This might be intentionally done to test a theory and succeed or fail as quickly as possible. In this scenario the software developed will often be throwaway. But I have seen POCs developed that will later become part of the production solution. So there isn’t a hard and fast rule here. But generally speaking I would suggest that a POC is not for production use.

If you wish to develop code that will test an idea in a production environment a slightly different concept is often adopted. A Minimum Viable Product (MVP) is a term which originally applied to the “Lean Methodology”. Lean is a way of the optimizing people, resources or effort of an organization. When applied to software development this can involve a concept of developing only the must have requirements for a given solution. By doing this we’d create a working piece of software that might not meet all of the stated needs but as it addresses all of the must haves should therefore be a useable solution. The idea being that you could develop the solution and implement it into a production environment in the shortest possible amount of time. Often an MVP might be considered a version one of a solution. Later versions maybe required to fully realise the intended vision.

Collaboration Tools

On all projects it will be essential for users to collaborate with functional consultants in defining requirements / user stories. Or for developers to work with the stories to develop the actual solution. Testers in turn will need to understand what was required and how they can validate the outputs.

With small local teams collaboration is a simple task. But with large teams working on large projects collaboration won’t “just happen”. Your users, developers and testers may, for example, be located in different countries. With potentially significantly different time zones.

Therefore considering what collaboration tools are available to document user stories, record defects and manage issues should be a high priority. Microsoft provide Team Foundation Server (TFS) which may help. But other tools are available, such as Jira, Confluence and many others.

Plus we can make great use of other Microsoft collaboration products. Such as OneDrive or SharePoint for document sharing. Or Microsoft Teams might be used to create collaborative worksplaces and host meetings.

Perform an Audit

In some organisations I’ve worked at we have referred to the initial system audit as a “Discovery”. The idea is that you may need to document everything about the current architecture. This might include details for the physical architecture and software components. Not forgetting things like the operating system and browser versions.

Having a detailed audit of the existing environment can prove extremely valuable. For example, your proposed design may leverage new features that are only supported for certain browser or operating system versions. If you hit this type of requirement knowing how many outdated desktops exist could be an essential piece of information when planning the effort and costs involved in the upgrade.

You may also wish to record details of the network architecture and any other aspects of the architecture which might impact performance. Information like this might help you make observations / recommendations on expected performance.

Additionally documenting details of all existing software licenses may help you ensure all users have the correct licenses to support any changes you plan to deploy. And if they don’t have the required licenses then any associated costs can be built into the project estimates.

I hope you can see that without an accurate system audit it may prove very difficult to make informed comments on performance, stability and system running costs.

Change Logs

You can read wikipedia’s definition of a change log here.

Maintaining a list of changes maybe essential to retain a list of decisions taken.

Some simple changes may need no authorisation but others may have a significant impact on the projects scope, timescales or cost. When this is the case it is normally important to record the detail of the change, its impact and who requested / approved the change. This can be of particular importance in fixed price contracts when every change could result in an additional cost.

Different organisations may log changes in different ways! Typically a detailed Change Request will initially be created. (Often described as a CR). The project board will typically review CRs and approve or reject them. Any approved CRs will be recorded in the change log.

The level of formality in this process can vary drastically. I have also often been project managers given a certain degree of discretion. They may be allocated a change budget that can be used for small changes. However almost always large changes with commercial impacts will need to have some form of formal authorisation.

You may also hear the phrase Change Advisory Board (or CAB). CAB, is actually a term from ITIL. (ITIL stands for the “Information Technology Infrastructure Library”, a set of best practice standards for delivering IT services.) CAB is part of an ITIL phase known as “Service Transition”. This includes the change management processes required by your IT services team and will have a focus on limiting business risk. They will want to evaluation changes completed in your project prior to allowing deployment into production environments. The CAB will consider if the changes are fit for purpose and of an acceptable level of risk. The CAB risk assessment may involve asking multiple questions about the change. Including, “How are services and service levels impacted?”, “What is the impact on performance?” and “Will the change have any impacts on security or compliance?”.

Managed and Unmanaged Solutions

I will create a separate post specifically covering the technical details of managed and unmanaged solutions!

A solution is a Dynamics 365 construct which allows us to “wrap” all of the technical assets in a Dynamics 365 project into a solution. A solution will include entities, forms, views, dashboards, web resources and much more that make up your final application. A solution can be version controlled and exported / imported. This allows us to migrate changes from our Dynamics 365 development environment into our test or production instances in a controlled manner.

All solutions start off as unmanaged, your development environment will therefore include the unmanaged solution(s) that make up your system. This development solution can then be exported in either a managed or unmanaged state. The solution in a managed state is typically imported into your production and test instances.

This process gives several advantages. As unmanaged solutions can be changed whilst managed solutions can have restrictions which prevent anyone making customizations outside of your controlled development environment. When we delete an unmanaged solution just the solution definition is removed. But when we remove a managed solution the assets held within the solution are also removed. This process gives us the potential to rollback changes!

Solutions can also be used by ISVs (Independent Software Vendors) to ship their packages in a format that is easy to deploy by customers. This would generally be done as a managed solution, as this would restrict the customers from amending the application provided and also make it easy for the customer to remove the solution if no longer needed.

As mentioned above I will expand on the technical details of solutions in a future post …. For now the important takeaway is that we have a mechanism in Dynamics 365 to migrate changes from development environments to production ones in a controlled manner.

Entity Components

The entities which may exist within your solutions will be made up of multiple components.

The components of an entity include;

• Fields– these are the attributes that make up an entity.
• Relationships– the links between this entity and others.
• Business Rules – processes containing conditions and actions that can automate various behaviours on the entity. (Such as hiding / showing fields and much more.)
• Views– lists of data. Each entity can have multiple views of data that may include different columns and filtering for various purposes.
• Forms– each entity can include multiple forms. Forms can have multiple types / purposes, include main forms, quick view forms, quick create forms and cards.
• Dashboards – Some dashboards can be entity specific and would be an entity component.
• Charts– Each entity can have a number of charts that when combined with views will render graphical aggregations of the data.
• Keys– all entities have a primary field and unique ID field. The keys option extends this to define additional / alternate keys. These might include things like an account reference number which uniquely identifies an account. (Possibly provided via an integration with a third party system.)

Many of the other posts I’ve created for this revision guide will have expanded on the entity component concepts mentioned above!

I have covered quite a lot of ground in one post! You may need to research some of the topics above in greater detail but I hope this post has given you some important pointers for your MB-200 revision.

I have recently been experimenting with both Omnichannel for Customer Service and Power Virtual Agents, as now the two can be a combined their integration seemed like an obvious thing for me to review. In this post I will document how I created my first “omnichannel virtual agent” and make a few observations along the way.

A good starting point might be for me to describe the use case for Power Virtual Agents that can hand off to a human agent. BOTs are great at answering commonly occurring questions as it is pretty easy to train them with suitable topics and responses. However real agents will always remain the best people to answer unusual questions or give responses when a judgement call is needed. In fact I personally consider a human hand off option as an almost essential feature! Without it your BOTs offer an intelligent conversation capability but when they “run out of steam” your potential customers are left in a frustrating dead end. Implementing an escalation from the BOT to a human avoids customers reaching this frustrating state.

Integrating Power Virtual Agents with Omnichannel for Customer Service allows us to define multiple queues and transfer customers from our AI friends to humans in an almost seamless manner.

In the video below I have given a demonstration of how Power Virtual Agents operate, how to create the virtual agent and how to configure Omnichannel for Customer Service to use your BOT.

Conclusion / Limitations

Overall I’m very happy and excited about the integration of Omnichannel for Customer Service and Power Virtual Agents. I’m already thinking about using this with one of my customers!

I am very happy with the virtual agent handoff, so I don’t want to be overly critical but I have seen a couple of limitations (with possible workarounds);

One “limitation” I’ve observed is that the Power Virtual Agent’s transfer option doesn’t link to opening hours…. I’ve often seen a BOT enabled out of hours, designed to help customers whilst the agents aren’t working. During these “quiet” hours we wouldn’t want the BOT to attempt to transfer to the absent agents. Out of the box I haven’t seen a no code approach to this scenario. I guess it would be possible to create two virtual agents, one that will transfer to a human and another that doesn’t. You’d then need a small piece of code in your website to decide which BOT should be active at any point. This approach would be pretty simple to implement but I’m looking for my implementation to be no code, hence why I see this as a limitation!

BOTs do not support skills based routing. But what if we want to apply skills based routing when transferring to our human agents? In my video demo I showed that we can use the “va_Scope” context variable to allow us to know when to route to a queue of humans. I guess we can simply ensure that the humans in that queue have the skills to handle any query from that Virtual Agent. But I would have liked to have seen skills based routing, maybe with the transfer request being associated with multiple Omnichannel for Customer Service skills. We might not have skills based routing from BOTs to humans but all is not lost! As the tile used in my virtual agent does include the ability to define a private message to the human agent, that might prove really useful! It wouldn’t take much effort to route particular chats to various queues based on the private message from the BOT. We’d use the context variable “va_AgentMessage”, which I believe would include the private message from the BOT.

Knowing what the possible context variables are might be useful! So below you can see a summary of all of the context variables available.

I hope this post and video will have been useful to anyone considering using Power Virtual Agents integrated with Omnichannel for Customer Service …. 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 field security.

There is a section of the MB-200 exam which has a focus on implementing security, you can see below that managing field security profiles is mentioned in the configure security settings section.

Field-level security can be applied to system and custom fields across the system. And by default is disabled for all fields. To enable field security on any field you open it in customizations and change the “Field Security” option to enabled.

Note: I have shown setting this field in the classic version of field customizations because at the time of creating this post the field security property could not be set in the newer customization interface.

Having created my field I added it to a form and published my change. Once published a key will show next to the field to highlight that it is subject to field security. (As shown below.) At this point only the system administrator can see and maintain the details in this field.

If any user, other than the system administrator, looks at the form they will see “******” in place of the data. (As shown below.)

Note: Below I have logged in as a user that has full organization level access on the entity but it not a system administrator.

It is important to realize that field-level security does not apply to just Dynamics 365 forms but everywhere you might see or maintain data. For example, below I have shown a view containing my “Secure Field”. Notice that it is blank, this isn’t because the field contains no data! It is because the current user does not have read privilege on this field.

Below you can see that field security even applies on editable grids ….

To grant access to fields which are enabled for field-level security you need to create a field security profile. This is done from the “Field Security Profiles” option which can be found in the security area of advanced settings.

When creating a field security profile you first give the profile a name and optionally a description.

Once you have saved the profile you can use the “Field Permissions” option to add whatever level of access is required. You can see below that I have granted read access on my field. But I haven’t granted update or create access.

Tip: Having just create access might be useful if you want someone to set-up a field when a record is created but then not change it afterwards.

Having created the desired field permissions, you can then assign users or teams to the profile. Below you can see I have assigned this profile to one user.

Tip: A real world scenario assigning teams to the profile might be the best option. As user teams helps to keep administration to a minimum.

Below you can see that after granting read only access the content of the secure field is now visible but the lock icon next to the signifies that it cannot be changed.

As always, I suggest your exam preparation involves plenty of hands-on time. So try creating some field security profiles to see how they operate. Doing so will also give you a chance to practice creating fields and maintaining forms. So a fun exercise!!

I hope this post has given anyone preparing for the MB-200 exam the basic information they will need to understand on field-level security.

The USD Accelerator (in my opinion) is a fantastic tool but what is it and why would you use it??

What is Unified Service Desk?

You may not be aware of Unified Service Desk (USD) and the many advantages it can deliver. USD is designed to work with Dynamics 365, it is a configuration-based framework aimed at building applications which can benefit contact centre agents.

Features such as agent scripting, session management and knowledge base integration all provide a user-friendly interface that can deliver significant business benefits in contact centres. A well implemented USD solution can help drive down your Average Handling Time (AHT) and improve customer satisfaction ratings.

I have repeatedly found that USD can provide significant business benefits to contact centre’s using Dynamics 365.

Unified Service Desk Challenges

Initially USD can be a bit of a mountain to climb!

Being a configuration-based framework means developers can quickly create tailored solutions. But being framework brings some challenges;

• USD is effectively a blank canvas, meaning an interface needs to be created from scratch.
• The flexibility of USD means the configuration can be complex, especially to developers new to the required concepts.

The means learning how to configure USD can take developers a considerable amount of time. A challenge which is made harder as being a blank canvas means they have to create everything from scratch.

This makes USD projects look like a difficult / lengthy technical challenge.

Introducing “The USD Accelerator”

Over the last few years I have conducted many demos of Unified Service Desk and completed multiple proof of concept (POC) projects. Not to mention that I have successfully implemented USD in production environments several times. Each time I’ve needed to repeatedly build similar functionality! I have used these experiences to build The USD Accelerator.

I have created a USD configuration that can be applied to many situations. Think of The USD Accelerator as a template solution, meaning a large percentage of the application can be delivered in a very short timescale. You can then focus on “just” building your bespoke elements.

It works with many of the out of the box system entities found in Dynamics 365, including leads, contacts, accounts, cases and opportunities.

It also integrates with many standard features / add-ins such as Field Service, Gamification, Web chat (using CaféX’s Live Assist) and much more.

The design concept includes many options that allow features to be quickly enabled / disabled. The initial configuration can take less than one day. Allowing companies to quickly configure “their template” and then customize as required.

I know this as I’ve completed multiple demonstrations and even production builds using The USD Accelerator.

What Benefits Can I Expect?

The USD Accelerator is designed to help improve the return on investment for your Dynamics 365 project. This is achieved by;

• Starting from a template rather than a blank canvas will help deliver your demo, POC or production system quicker.
• Having a template to learn from will help speed the learning curve of your developers.
• Additionally, the interface has been created from my considerable experience in contact centres meaning you should expect improved user adoption.

How Much Will The USD Accelerator Cost?

Nothing! I am making The USD Accelerator available as a free download. You can download and use it in your projects for free.

All I ask is you give me feedback on how The USD Accelerator helped you. Plus given me your ideas on enhancements so I can try to improve it for others.

However if your developers need training or your project needs support I will be more than happy to discuss ….. neil.parkhurst@npdynamics.com

What next?

Below you will find links to detailed installation instructions and technical details. Follow the links below and you’ll hopefully be up and running in no time at all ….

Download The USD Accelerator

Technical Manual

What If You Need Help?

Implementing solutions in contact centres, even with The USD Accelerator can be a challenging undertaking. I would be happy to discuss your requirements in detail.

If you would like to discuss your specific project please email me at neil.parkhurst@npdynamics.com.

Overview

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

I am excited to announce release 3.1. This new release has a focus on the agent experience. Therefore it contains loads of bug fixes and performance enhancements. And additionally many agent focused usability changes.

This post will highlight the enhancements and bug fixes released in version 3_1_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.

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 Dynamics 365 security.

You can see below that security roles, users, teams and hierarchy security are mentioned in the implement security section of the exam.

To understand security roles you will need to appreciate several related concepts including business units, users and teams. So I will cover all of these in this post!

Security roles govern what actions a user can complete on a record. You’ll need to appreciate what actions we can control, such as create, delete, assign and share. Plus you’ll need to know what a business unit is and how the units can relate to each other.

Additionally we have multiple approaches to security. For example, access to each record is generally based on an ownership model. For example, I can only read (see) accounts I own. But other options such as hierarchal security exist. Something that maybe useful when you want to grant a sales manager permission to see amend all of the record owned by her team.

Other security requirements might include requirements to restrict access to a single fields or maybe we need to grant access to specific records. (Known as access teams.)

Therefore, I will devote the rest of this post to attempting to give you an overview of the security model. Armed with that knowledge I encourage you to then spend time reviewing how the out of the box security roles are implemented.

Tip: As part of your revision the best way to understand security roles might be to open up some of the out of the box roles and review what actions each would enable.

The options / entities related to security are as follows;

• Users, allows you to manage users and associate them with business units / teams and roles.
• Teams, this option lets you define teams and also associate with security roles.
• Security Roles,
  security roles let you define what access will be provided to teams and users. Roles are created and then one or more are associated with each user / team.
• Business Units are a fundamental building block in the Dynamics security model. They define the structure of the organization.
• Field Security
  Profiles are used when you need to define specific access rights on individual fields.
• Hierarchical Security supports a security model based on someone’s hierarchy. Which can either relate to the manager they have defined in their user or positions.
• Positions define organizational positions which support the hierarchy security model.
• Access Team Templates support dynamic record sharing. With the members of an access team being given privileges on specific records based on the access team template.

Business Units

The first construct to consider are business units, these allow you to define the structure of your organization. Users, teams and security roles will be linked to business units making them a fundamental building block in the security model.

Below you can see that I have created an example business unit. All of my international sales team will be linked to this business unit. Notice that most of the fields about address (etc) have been left blank. These extra fields are not essential but might be really useful for reference purposes. (However they have no functional use within the security model!)

Business units can have a hierarchy. This might reflect the organizations actual hierarchy but that isn’t always the case. In actual fact the hierarchy is designed to “drive” which users get access to what records. I have created a very simple organizational structure below. With sales and service being split. Plus, sales being further split into UK and US teams.

In Dynamics 365 the above business unit hierarchy looked like this;

Some points about business units you might need to know;

1. The root business can be renamed.
2. The root business unit cannot be deleted or disabled.
3. The root business unit cannot be moved to have a parent business unit.
4. The name of the root business unit will default to the organization name when the system is first deployed. (But you can change it.)
5. All child business units have a parent which will either be another child or the root business unit. Meaning the root business unit is always the top of the business unit hierarchy.
6. The parent business unit on a new business unit will always default to the root but can be changed.
7. The definition of business units often follows the companies organizational structure but this is not essential. Ideally the business unit structure should mirror whatever is needed to support the security requirements of the organization.
8. Child business units can be renamed.
9. Child business units can be disabled.
10. Child business units can be deleted but only after being disabled.
11. Any users in a business unit will lose access to the application if the business unit they are assigned to is disabled.
12. Child business units can be moved under a new parent – If you move the business unit users will move with the business unit.

Tip: The root business unit can be renamed! But historically I have found that the parent business unit field is mandatory. Which makes it impossible to save the change of name. (As the root does not and cannot have a parent business unit.) To resolve this you need to remove business required status on the parent business unit!

Users

Firstly, users will need to be created. This means they must exist as a user within Office 365. Additionally, they must be assigned a Dynamics 365 license.

Once the user signs into Dynamics 365 the security model is used to control what they can access. This is achieved using the manage roles option on the user.

Tip:
As you will soon see the combination of the user’s business unit and security role(s) will govern what access they have.

When creating users, the business unit is a mandatory field and will default to the root business unit. To access Dynamics 365 a user must also be given at least one security role. (Or be assigned to a team that has a security role!)

If you need to change a user’s business unit use the “change business unit” option. If the user owns a large volume of record in Dynamics 365 this process can take a long time! If you move a user from one business unit to another their security roles will be removed. Meaning, having completed a change of business unit, new security roles will need to be added before the user can log into Dynamics 365 again.

Security Roles

Each role is linked to a business unit. The roles then contain many options that govern the access to entities / features for the combination of business unit and user.

Often roles will be inherited from a parent business unit. Meaning when I use the manage roles on a user linked to a child business unit, I still see the roles from the parent business unit. This happens even though I haven’t created any roles specific for the child unit!

Each user can have multiple roles. The Dynamics 365 security model works on a least restrictive security model. Meaning a “sum” of all the roles assigned to the user would be applied.

Each role is made up of several options (actions) for each entity / feature in Dynamics 365. Entities typically have multiple actions covering functions including, create, read, write, delete, append, append to, assign and share.

Each entity can have eight different types of action. (Some are obvious in terms of what they do, some might need a little more thought!)

• Create
• Read
• Write
• Delete
• Append – attach this entity to other entities. (Notes for example would need append enabled.)
• Append To – attach other records to this entity. (Account for example would need “append to” so Notes can be added.)
• Assign – gives the ability to change the owner of the record, to another team or user.
• Share – allows someone to share the record out with other users. (This does not change the owner!)

Note: When you share a record you cannot / do not give any more access than you currently have.

The options govern the level of access. (As shown in the key below.) Not selected means the user will not have any access. User access would signify they can only work with records they own. We then have an increasing level of access that gives a greater and greater amount access based on the business unit hierarchy.

Tip:
When we create entities in Dynamics 365 they can be user / team owned or organization wide entities. Organization wide entities only have two access options. (None and organization!)

A detailed definition of these options is given below…

Teams

Teams have several uses in Dynamics 365. Teams are essentially listing or groups of users and can be used to help manage security. Teams may also be useful when creating reports. Additionally, teams can be useful when you wish to share “assets” with a group of users. (Assets could include views, charts, dashboards or records.)

You will find the option to maintain teams in the security area of Dynamics 365 advanced settings.

Business Units and Teams

Each business has a default team. This is a “special” team that cannot be removed. Users are automatically added as they are assigned to the business unit. Below you can see the default team for my International Sales Department. Notice the description highlights the fact that this is a default team.

Team Types

Owner teams are the original / traditional type of team found in Dynamics 365. Owner teams have members and the team can own records. (Assuming they have a security role that grants sufficient permission!) For example, an account might be owned by the “International Sales Team” rather than by an individual user.

Access teams are a special type of team giving record sharing capabilities.

It is important to understand that owner teams can have a security role. Members of the team will inherit the permissions granted by the team’s security role(s). Should you wish records to be owned by the team it must have a role which grants access to whatever entity is to be owned.

Owner Teams

The membership to owner teams can change but tends to be static. Someone joins the team and remains part of that team for all “activities” conducted by the team. An owner team has a finite number of members at any point in time.

Owner teams are useful when reporting on the team as a whole is required. For example, the team could have a goal and be measured as a group against that target.

Owner teams are associated with a business unit. As they will need to be assigned a security role from that business unit. But the members of the team do not have to belong to the same business unit. This is useful when a group of people need to collaborate across business units.

Note:
Also notice that the team has a default queue. (As does a user!) You should probably make yourself aware of them! Queues are a useful construct for managing lists of outstanding work items. You could for example create a queue containing service cases that need attention. And give everyone in the service team access to that queue.

Access Teams – User-Created

User created access teams are used to easily share records with a group of users. They are in many ways very similar to owner teams! As they have members in a very similar way.

Except, user-created access teams do not have roles and cannot own records. Although records can be shared with them without the need to the team owning the record.

Below you can see that I have shared an account record with the access team I created above. And that the team members have been granted read access on the account.

Access Teams – Auto-Created

Auto-Created Access teams are used to share individual records. These access teams do not own records and cannot have roles. They are by implication very fluid / dynamic teams and will be formed or dissolved almost at will.

The number of members, who those members are or even if the team will exist is not a given. Consider an access team used on opportunity to reflect the sales team. It might be the opportunity is very small and an access team is never required for that sale. Or it might be a large potential that needs multiple people involved.

On my opportunity form I’ve added a sub grid in which I list the access team members for the opportunity. Any users added will be part of the access team for that specific opportunity. Giving them all rights to maintain that opportunity. (Based on an access team template.)

Before you can use an access teams on an entity it must be enabled for access teams. To do this you will need to use the customizations option. And under Communication & Collaboration enable the entity for access teams.

Once enabled you CAN disable access teams if required.

Having enabled the entity for access teams you will need to create an access team template. Access team templates are defined in security settings in Dynamics 365.

Below you can see an example of an access team template for the opportunity entity. This is used to grant members of the access team privileges on individual opportunities.

Note: You are limited to 2 team templates per entity.

A sub grid for the team members will need to be added to the entity. Below I have shown the access team I added to my opportunity form. (Again using the Dynamics 365 customizations options.)  Notice that in the data source the records field is set to All Record Types, I have then selected Users as the entity. And I have set the default view to Associated Record Team Members. Then finally I have selected the required access team template opportunity.

If the access team template is changed, the revised permissions will not affect any existing access teams. Only as new records are created will the revised permissions take effect.

If an access team member has the share privileges. When they share the record their access team privileges will be shared. Meaning if someone has share ability but cannot delete a record. The people they share the record with will also not be able to delete it.

Hierarchy Security

The standard security model will fit most situations but we have a further option that might occasionally provide benefit. The concept of hierarchy security is to grant permissions based on someone’s “hierarchal position” in the organization. This could be defined in one of two ways, hierarchy based on reporting lines or positions. You will find the hierarchy and positions options in the advanced settings area.

Hierarchy security leverages settings on the system user entity in Dynamics 365. Each user can have a manager defined. It might be that the manager needs to have access to all the records of their team.

Another concept would be to define positions. Users can then be assigned to those permissions. It might be that anyone who is classed as having the position of “Board Member” would have read access to any data for people in positions “below” them.

Note: It should be understood that hierarchy security is not designed to replace the standard approach. It is supposed to be used in conjunction with the existing security model to give greater flexibility.

The hierarchy structure can span the business units again helping to provide an additional dimension to the security model.

A further concept is depth …. If your hierarchy has many levels, you can define how many layers to go down in the structure. It might be that the National Sales Manager can read and edit any opportunities for his direct reports. But if one of those reports is an area manager, then the National Sales Manager can still read records for the direct reports of the Area Manager. (But can’t change them.)

Note: To be clear, with non-direct reports the manager would only have read access. For direct reports that manager will have read, write, update, append and append to access. Also for the manager to have any access to the records for direct or non-direct reports they must have at least read privilege on the required entity.

These concepts can create a very granular approach. Let’s look at them in more detail. When you first set-up hierarchy security it must be enabled. This is done in the Hierarchy Security option found in the security area of settings.

Once enabled you opt to use this approach based on the manager hierarchy (as defined on system user records) or based on custom positions. I will describe how to create a custom hierarchy in a second! You must use one or the other approach a mixture is not possible.

Next you define how deep the hierarchy should go. A manager will have Create, Read, Update and Delete access to their direct reports. But then this depth option is used to decide how many layers below that they can see. (Note: See as they only have read access as they go deeper in the hierarchy.)

Finally, we select which entities this should apply to. By default, the hierarchy security model applies to all entities. But you can opt to exclude entities. In the example below I have elected to exclude everything except Account, Contact and Opportunity.

To define a custom position hierarchy, you use the positions option that can be found in the security area of CRM under settings. Below you can see I have created a hierarchy of positions as a simple example of how they might be defined.

Hopefully this post has given you a good introduction into the Dynamics 365 security model.

As always, I encourage you to experiment with security roles hands-on. As part of your MB 200 revision I suggest you try creating multiple users and grant them different permissions. Then login as each user to see how this effects what records they can access and what functions they can perform on those records.

Hi,

I have written a Custom USD Control that doesn't do a whole lot, really it's a proof of concept.

I have a menu with a drop down with some items in it.

What I want to be able to do is to call an Action on these menu items to open up my Custom USD Controls and have them shown in the MainPanel.

I don't want the control to be marked as global because users can show and hide them at will.

I've looked around and haven't found any particular information on how to do this (although I know I am missing something simple).

Any suggestions would be great.

Thank you.

Greg

We can now intergate Dynamics 365 with Facebook messenger using the Omnichannel for Customer Service app.

I have been experimenting with this cool new feature and below you will find a video explaining how it works and how you can configure it ….

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 365 admin roles.

You can see below that we have a section of the exam which covers security. Within this section needing to know about the Dynamics 365 admin roles is highlighted

.

We have seen in other posts that Dynamics users are created in the 365 admin center then assigned a role in Dynamics 365. Assigning this role governs what features of Dynamics 365 will be available and what access they receive to what records. But within Office 365 we also have a number of administration roles which allow the management of users, subscriptions and services available to the organization as a whole.

You will find the 365 at https://admin.microsoft.com/

I guess one of the most import 365 admin roles of the Global Admin as they have complete access to everything!

Global Administration Role

When creating users they will typically just have a “user” role, meaning they have no access to the admin center. But we can grant one (or more) admin roles. One of the available roles is “Global Admin”.

Global Administrators can perform any management activities in the Office 365 admin center. They are your “top level” administrators. Your global administrators will, by default, also have systems administration privileges in Dynamics 365.

You can see my roles below, notice that I am a global admin.

Tip:
Also below notice that a user can’t change their own roles. (Not even global admins!)

Note:
Global administrators are automatically assigned a systems admin role in Dynamics 365. Importantly this means they can access Dynamics 365 without being assigned a license. BUT, they cannot see any records without a license! Therefore typically they will need a license that will grant them full read-write access in Dynamics 365. If a Global Admin is created without a license their access type in Dynamics 365 would be administrative rather than “read-write”.

Other Administrator Roles

It is also possible to allocate one or more specific admin features to a user. This is useful when you need to grant limited admin capabilities to a user, without having to give them the full power of the global administrator.

There are a number of common admin roles which are always shown whilst maintaining roles. But clicking the “show all by category” option will expand the list revealing numerous other roles.

Learning the key capabilities many of the roles might be a useful part of your revision! Take time to study each role and consider what capabilities and limitations each one would have.

Below you can see a summary of the major admin roles listed above.

In addition to the roles above many others exist! I will not attempt to cover all of them here, but a few warrant mention ….

Best Practice

There are some best practice guidelines for handling admin roles within 365 admin that you should be aware of;

Limit the number of global admins– Microsoft recommend having 2 to 4 global admins. You will want more than one global admin but as they have unlimited access they represent a security threat. Therefore having the minimum number possible is a good practice.

Always assign the last permissions possible– admins who need to complete a particular task should be given the ability to do just that task. For example, if you need someone to reset passwords don’t give them the global admin role instead grant them the password admin or helpdesk admin roles.

Require multi-factor authentication– you should ideally configure multi-factor authentication (MFA) for all of your uses. But admins should defeinitely be required to use MFA. This is because even if their passwords are compromised it is useless without the second form of authentication.

Security Groups

When a user is assigned a Dynamics 365 license they then have rights to access all instances (CDS databases) within the tenant.

Note: They do still need to be granted a security role within the instance to access Dynamics 365 records.

It might be that you need to restrict which instances a user can work with. Security groups can be defined in 365 admin and leveraged for this purpose.

First you create a security group in 365 admin and add users. You do this using the “add a group” option in the 365 admin center, shown below;

Now set the group type to be security …..

And give it a name and description as required.

Once your group has been created you can add members (users) into the security group.

Now your security group is created you can open your Dynamics 365 instance in the power platform Dynamics 365 admin center and associate the security group with your instance. Doing this will mean that only users included in the security group can access that CDS database.

A few things to note about security groups:

• When a security group is associated with an existing environment, all users in the environment that are not members of the group will be disabled.
  
• If an environment does not have an associated security group, all users with a license will be created as users and enabled in the environment.
  
• If a security group is associated with an environment, only users with licenses that are members of the environment security group will be created as users in the Common Data Service environment.
  
• When you assign a security group to an environment, that environment will not show up in home.dynamics.com for users not in the group. (Meaning they won’t even see the environment!)
  
• If you do not assign a security group to an environment, the environment will show up in home.dynamics.com for all users even for those who have not been assigned a security role.
  
• If you do not specify a security group, all users who have a license, will be added to the new environment.
  

Hopefully this post has given you a good overview of the admin roles in Office 365 and explained the key points you’ll need to revise for your 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 searching.

In the skills measured statement (shown below) under the heading “Perform solutions deployment and testing”, you will see a reference to both the relevance and categorization search features.

We actually have several types of search available to us, including;

• The “default” search
  
• Category Search
  
• Relevance Search
  
• Advanced Find
  

Note: The Dynamics 365 /CDS security model will be applied consistently across all search modes. Meaning you can only view records that your security role(s) grant access to.

“Default” Search

By default, on views within the system I can perform simple searching and filtering of records within the view. These searches act on which ever entity you are currently viewing. Multiple columns are searched and all records matching the search are returned in the view.

Multiple fields are searched, exactly which fields are controlled by system administrators. As administrators can edit which columns are “find columns” by customizing the “Quick Find View”.

Next, we have the filter option which is activated by clicking on the funnel icon. The filter allows users to create ad-hoc filters on one or more columns within the view.

Both the default search approach and filtering cannot be considered a “global” search! As they will only search one entity at a time. To search multiple entities simultaneously we would use the category or relevance search options.

Category Search

You access the category (and relevance) search options by clicking the search icon found in the top level navigation bar. (shown below)

Note: If you have the relevance and category search enabled then you may also need to pick the correct search type.

Below you can see that I have used the category search to look for matches for the word “neil”. In my example this has returned matching accounts, contacts, leads, opportunities and more. In fact I may have several pages of entities I could review. (Notice the scroll option at the footer of the screen!)

The columns searched by each entity (as with the default search) can be controlled by a system administrator by making changes to the find columns in the “Quick Find View”. Additionally for each record returned we see three fields, these are the first three columns the administrator included in the quick find view.

Further to this the administrator can control which entities are included in the results returned.

Also notice that the “filter with” option will allow you to focus on a single entity as required.

I hope you can see that the category search is a powerful multiple entity search capability. But it does not apply any “fuzzy” logic when searching. For that we’d need the relevance search.

Relevance Search

If you need this greater flexibility, then the relevance search might be the answer. Once your administrator has configured the relevance search you can access it from the same search icon as the category search. See below that I can swap to the relevance search.

Immediately I hope you notice that results are now displayed as a single list in order of relevance. And on the left-hand side we have several filters. Initially these include record type, owner, modified on date and date created.

By default, the relevance search allows filtering by record type, owner, modified on and created on. But if you select a specific record type additional filtering options (facets) may become available. See below how I have focused on one record type of opportunity and additional facets becomes available, including potential customer, estimated revenue and estimated close date.

Also, notice that I no longer need to add a wild card. Plus, I can search using multiple key words. In my example (below), the categorized search would look for all entities with “datum example” in a single field, which more than likely would return no results. But the relevance search will look for each keyword in any field. Meaning it is a multi-entity, multi-field search. (Notice how the words used to match the records are shown in bold.)

To demonstrate how this differs from the category search I performed the same search using that. My category search returned no results! As none of my entities contains the phrase “datum example” in one field.

The relevance search makes use of Azure Search functions. This provides some additional query characters;

+ … Will search for results that contain both works. Such as Datum+Corporation. Note, the words do not have to be together, but proximity will score higher on relevance.

| … Will search for results that contain either word. Such as Seattle|Remond.

” ” … Used to search for a phrase, so “Datum Corporation” would look for the entire company name.

() … Using the term training+(health|safety) will search for matching records that contain the training and either health or safety, or both.

As with many features I doubt you need to understand the detail of how the relevance search actually works! (Unless you are a developer!) But it maybe important to understand what the relevance search is doing. Relevance search is making use of Azure search functions, meaning your data needs to be synchronised with Azure. This process happens seamlessly in background, but it is worth knowing that changes can take 15 minutes to be reflected in the search results. Also, when you initially enable the relevance search there could be a considerable delay for the initial synchronization with Azure.

As the relevance search uses Azure search capabilities results are scored based on their relevance and this in turn drives the sequence of the results returned.

Plus, using the Azure search means Microsoft Natural Language Analyzer comes into play. Meaning “Lemmetization” (great word!) is used to break words down into their linguistic forms. This sounds complicated, but it simply means that a search for “Run” would also match with words like “Ran”, “Running” and “Runner”.

Setup / Configure Relevance Search

The relevance search is not enabled by default. An administrator must manually enable it. The relevance search needs to be enabled in system settings. (As shown below.)

The relevance search uses Azure, therefore you may need to accept the warning message that your data will be shared externally.

Having enabled the relevance search you can select which entities will be supported by the relevance search. Below you can see that several entities are listed by default but the selected entities can be changed as required. (Don’t forget that if you add a new entity it will take time for the initial data synchronization with Azure Search.)

Facets & Personal Options

As already mentioned you can filter the results of each entity by a number of facets. It is possible for each user to control which facets an entity is filtered by. (This does assume the administrator has already added the fields as columns in the quick find view!)

Within personal options on the general tab the user can pick which search experience they would like to use as their default and also define the facets / filters for each entity.

Below you can see that I have selected my opportunity entity. Notice that the user has the purchase process and purchase timeframe available to them. These are only available as I have added them as columns in the quick find view on the opportunity entity. As five fields are available the user can now select which four they would like to use when filtering opportunities. (There is a limit of four fields!)

As part of your revision for the MB-200 exam I suggest you experiment with the various search options and consider the differences between each option. One good exercise might be to add some columns to a quick find view and see how these effect the category and relevance search options. Enjoy.

I use the following condition to check a,b values before save.And I call this function form's onsave Event.

if the field values a == b means i need to save the record.Else I need to show the alert.

if a!= b condition the infinite loop will occur which means the alert message shows continuously .My problem is i need to prevent save record if(a!=b) . I used eventArgs.preventDefault(); but its not working.

Am working in CRM 2016. 

function onsavecall()
{
if(a != b)
{
alert("alert a is not equal to b .so please change value B");
}
else
{
Xrm.Page.data.save.then(function(){
Xrm.Page.data.refresh();
});
}
}

Thanks in Advance

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 subjects.

You can see below that we have a section of the exam which covers system administration. Within this section configuring subjects is mentioned.

Subjects are a tree of categorisations used to record the subject for cases, knowledge articles and products. Below you can see that I have opened a case and on my case form I can enter a subject. This is done using a picklist that offers me a tree like structure of subjects.

Security Roles

The subject entity is shown under “Core Records”, most security roles will grant read and append to access to the subject entity. You might also need to know that the subject entity is not user owned. Meaning access is either granted or denied at an organisational level.

To maintain the subject tree you will need the correct role. Out of the box the “Customer Service Manager”, “System Administrator” and “System Customizer” security roles will grant the required permissions.

Tip: In my instance “Customer Service Manager” role is called “CSR Manager”. That might be the case for you!

Below you can see the role for my CSR manager, notice they would have full organisational access to the subject entity.

Maintaining the Subject Tree

You can maintain the subject tree from the “Customer Service Hub” application.

Open the customer service hub app and then navigate to the “Service Management” section of the sitemap.

Within the service management area, under the heading of case settings you will find the subjects option.

To add a subject select “Add subject”, a quick create form will open. Simply give your subject a name and select the parent subject. (Or select the box to signify this subject is a root subject and has no parent.)

To edit a subject simply select your subject, click “Edit Subject” and a similar dialog will be shown.

There is also a “Remove Subject” option. Using this will give you a warning that the change cannot be undone. You might need to be aware that you cannot remove a subject that is already associated to a case, product or knowledge article. Effectively meaning that you cannot remove a subject once it has been used.

Alternative Maintenance Approach

We can also maintain the subjects from the advanced settings option. If you load advanced settings and navigate to the “Service Management” option you will find a subjects option. As shown below.

This subjects option presents the same data but using the old style classic web interface. (Rather than the newer Unified Interface introduced at version 9.1 of Dynamics 365.)

Tip:
Being the older style maintenance I assume that in the fullness of time this option might be completely replaced with the newer experience shown earlier. But it exists now (Feb 2020), so I have referenced it in this post!!

Hopefully you agree that subjects is a simple subject but it is one referenced in the skills measured statement of MB 200, so don’t forget to include subjects in your revision!

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 solutions.

You can see below that we have a section of the exam which covers discovery, planning and analysis, within this section needing to know how to select between managed and unmanaged solutions is mentioned. This statement actually implies quite a large amount of knowledge! As to select between solution types you’d need to appreciate what solutions are, how they are used and all of the differences between their managed and unmanaged versions.

Overview

Solutions in Dynamics 365 are used to package and deploy customizations. Changes are grouped together as a solution, they can then be exported and transported from one environment to another.

The solution will include entities and their assets. The assets include Forms, Views, Charts, Fields, Keys, Relationships (1:N, N:1 and N:N), Messages, Business Rules, Hierarchy Settings and Dashboards. But solutions contain much more than “just” entities. Other options include Web Resources, Workflows, System Dashboards, Connection Roles, Security Roles, SLAs, Apps etc etc. I will discuss more on what can be included later. But for now, it is enough to understand that solutions can include A LOT of different types of components.

Components within a solution can include;

• Schema components, including entities, fields, relationships and global optionsets.
• User Interface components, including forms, view charts, dashboards, site map, web resources and ribbons.
• Analytics, includes dashboards, reports and other visualizations.
• Process / Code, include processes (e.g. workflows) plus plug-in assemblies.
• Templates, including email templates, contract templates, KB article templates.
• Security, including security roles and field security profiles.

Solutions can be unmanaged or managed. Often unmanaged solutions are used in development but as they are deployed (or re-deployed) to production environments managed solutions are used. Managed solutions can be created in-house but they may also be used when adding functionality into the system provided by Microsoft (e.g. Unified Service Desk) or as ISV products. I will explain the differences in a second.

It is best practice to always make changes using solutions as this keeps changes together and makes it possible to track who did what.

Publishers

When you create a solution it will always have a publisher, so let’s look at those before considering how to create a new solution. When we create a solution it must be given a name and you select to either create a new publisher or select an existing one.

Why do we want a publisher? Well having a publisher(s) makes it easy to see which changes have been created by whom. As entities and fields are created their names will be prefixed to show who made the change.

A publisher might be an ISV, a Microsoft Partner or might be an internal team.

You will always have a default publisher; this could be used for internal development. Although personally, I like to avoid using the default publisher! I always create a publisher that reflects the project or organization making the change. Out of the box the default publisher will prefix all newly created fields / entities with new_.

Below you can see I have created a new publisher called “Neil Parkhurst”. The publisher name has been automatically derived from the display name.

Notice that I have set the prefix to np. Below this we can see an example of what a new entity name might look like with this prefix. (np_entity). Also notice that the Option Value Prefix is set to 77,828. Each text item in the optionset has a numeric value. The options value prefix option can be used to decide the values in optionsets for this publisher. (The option value prefix must ne in the range of 10,000 and 99,999)

If you scroll down the publisher form you will see fields to enter contact details of the publisher. These are for reference only but quite useful when the publisher is a 3^rd party.

Creating a Solution

In my introduction, I mentioned a concept of the default solution. The default solution effectively an unmanaged solution containing the entire system.

Should you make changes directly in the default solution then the default publisher will be selected. Meaning any new created components will be named using new_. (At least they will be if you don’t change the out of the box prefix.)

I must admit that when I first started using “CRM” I used to make all of my changes directly in the default solution. (Shocking I know!!) These days I don’t consider that good practice nor should you.

Right from the outset I create a solution and then as I create or edit components I add them to my solution. I do this for several reasons. One being that if I try to create a solution after the change is completed I sometimes find it hard to remember all of the assets I’ve touched. But most importantly by creating your changes within the scope of a solution, all of your changes will be prefixed appropriately. (Based on your publisher.)

Below you can see that within make.powerapps.com I have opened the solutions option. Within this I have filtered to show only my unmanaged solution. It is here that we can see the “Default Solution”, along with any other unmanaged solutions.

To create a new unmanaged solution, select the “New Solution” option which is found in top ribbon bar.

As I have already suggested, when I start a new “project” I like to create my solution as the FIRST thing I do before I start making any changes. Below you can see an example solution I have created called “Neil’s Demo Solution”.

Notice the Display Name and Name are mandatory fields. The Name field will default to the display name, with spaces and punctuation removed. When you are creating a new solution you can change the name field. But once created the name field becomes read only.

I have already described the concept of publisher. When creating a solution the publisher is mandatory but will be initially populated with the details of the default publisher. You can see below how I have changed my publisher to “Neil Parkhurst”.

The configuration page is an optional field. This is a link to a web resource that will be a component of the project. This can (optionally) be used to create a html page describing the content of the solution or maybe its release history. (Or anything you feel is important.) For small projects I tend not to create a configuration page and simply type this type of information into the description field. But on larger projects when I might require more information or expect to edit it overtime I always create a configuration page.

Version, this is a mandatory field. I have simply entered 1.0.0.0. The version may auto-increment as you export changes. Plus if you import a solution and a copy ready exists you will get a message warning message which will quote this version number.

The version number can be upto four numbers separated by decimals. (e.g. 2.1.0.440) Generally this is used to reflect a major.minor.build.revision format. But alternatively you could adopt other standards such as year.month.day.revision. You also see the version number appended to the zip file name when you export the solution.

Having created a solution, you will want to start adding components. Those components can be existing or new. And can be of “any” component type. Including entities, option sets, site map, web resources, processes etc etc.

If you add a new entity you will be prompted for its name and such like. But if you add an existing entity you will get a different dialog to allow the selection of all or specific assets. Below you can see I am adding the account entity into my solution. At this point I want to select what components to add into my solution. I always suggest that it is bad practice to simply add all the assets of an existing entity into your solution, as I much prefer to only add the components that will be changed by this solution.

Tip: If you really want to add all components for an entity there is an add all components option. I just don’t use it!!

As explained, when I add a system entity I like to select the specific views, charts or forms (etc) that need to be changed. One advantage of this is that it reduces the chance of any conflicts with changes others may make.

Below you can see I have selected just the main account form.

Exporting a Solution

Once you have finished your changes you will want to be able to export the solution. (For example, So that it can be moved from your development instance into production.)

Exporting a solution is easy, simply select the solution and click the Export button.

When you do this you will asked to publish the customizations. It is important to note that only published customizations will be exported.

We also have a check for issues option. You aren’t forced to check solutions for issues but using the solution checker should be considered a good practice as it will help highlight any potential issues in your changes.

Next you will enter a version number for your solution. (This will auto increment but can be changed manually as required.)

It is here that you will select to export your unmanaged solution as either unmanaged ore managed. Notice that managed is the recommended option, this is because typically outside of your development environment the solutions would be imported in a managed state. (I will cover more about the reasons for this later in this post!)

After a pause your solution will be saved. A solution file is simply a zip file that you can then move to another environment. The fact the solution is a zip file is useful as the files created are generally pretty small and therefore easy to ship around. Also these files can be stored meaning you have a reference of what was exported when.

Importing a Solution

Having looked at how to export a solution the next logical step is to consider how it will be imported. As part of my exam revision I have actually created two trials. (You might want to do the same.) This means I can create solutions in one trial and them import them into another trial. I’ve found this approach really useful when experimenting with how solutions work.

Once you have logged into your target environment, simply select the import option.

Now browse for a solutions file.

Notice the naming convention on my solution file. As by looking at the name we can tell the solution version and also if is a managed or unmanaged solution.

Sometimes you might be prompted at this point! Say you are importing a new version of an existing solution you will get a prompt warning that you are going to replace version “1.0.0.0” (say) with version “1.0.0.1”. Check this information and click next to continue, assuming you are happy.

IF the solution new or unmanaged, you will simply progress to starting the import at this stage. Although you will get a friendly warning when importing an unmanaged solution as the changes cannot be uninstalled.

Before actually starting the Import you can select the “View solution package details” option, this will show you the components included in the solution and give you details of the publisher.

If the solution your importing is a upgrade to a managed solution you may have a decision to make!

Firstly you will decide how to import the solution. The options being upgrade, stage for upgrade and update.

Upgrade Option

With the upgrade option any existing patches are rolled up and the orginal solution will be removed after the upgrade. This process is recommended as the result should be that the resulting solution will accurately match the solution being imported. (As removing the original version will delete any components no longer in the new solution.)

The upgrade option is the recommend approach and the approach you should therefore most often use!

When we look at the solution history (shown below) we can actually see that the new solution is imported as an upgrade and then the old solution removed. This is a two step process but both steps are automatically completed by the upgrade option.

Stage for Upgrade

The stage for upgrade option effectively lets you complete the two step process of the upgrade as separate steps. Initially your new solution is imported by the old one is not removed. After the import is completed you will see both solutions. Below you can see that I have imported version “3” of my solution but version “2” is also still present.

Once I am happy the import has worked as expected I can go to the original solution and apply the upgrade. This will then remove the original solution and roll up any patches. Finally resulting in the imported solution accurately matching the exported one.

After the process has completed the solution history will show both steps. Meaning this was a manual two-step process but the end result was the same as using the upgrade process.

Update

Our final option is update. This isn’t the recommended approach!

An update simply replaces the current version of the solution with your new version. This does mean any components no longer in the new solution will not be deleted. Therefore you could end up with some inconsistencies!

Overwrite / Maintain

Below you can see that scrolling the screen down will uncover options to “Maintain Customizations” or “Overwrite”. Maintain is the recommended option, so let’s consider that first. It is possible that someone else has made unmanaged changes in the environment you are about to alter. The maintain option will try to retain any existing unmanaged changes. If there is a conflicts an existing change it will be retained and the imported one not applied.

Overwrite however would do the reverse, it effectively forces an overwrite of the new solution.

When we are thinking about a production environment, if managed correctly this type of issue should never apply. As nobody would ever make uncontrolled changes direct on a live server. But unfortunately, that is just a theory! In the real world I have often found that support guys have “fixed” a few bugs direct on the live server outside of any reasonable controls.

You will see a progress bar displayed as the solution imports. The time this takes will vary depending on the size of the solution. But typically the process only takes a few minutes.

Once completed you will get a message telling you if the import was successful. (or not!)

Tip: If you do happen to get any errors with the import the download log file option might be very useful to help you diagnose the issue.

After my solution import is completed my changes will have applied and I can also open the solution as required. If my solution was imported in an unmanaged state I could open the solution and continue to make changes. If in a managed state I will see a message that I cannot directly edit the components with the solution.

Solution History

You may find the solution history option useful. In the ribbon bar of the solutions area you will find the “see history” option.

The solution history option lets you see which solutions have been imported and if the import was successful or not. Usefully we can see details of solution upgrades that will have been completed automatically as well as manually imported solutions. If something unexpectedly changes in your environment this view is really useful to see who has applied what changes!

Managed v Unmanaged Solutions

Some points about differences between managed and unmanaged solutions;

• The default solution is always an unmanaged solution. But other solutions can be managed to unmanaged.
• Unmanaged solutions can be changed.
• Unmanaged solutions cannot be removed. (Meaning if we delete an unmanaged solution just the solution is removed all of the assets contained in the solution would remain.)
• Unmanaged solutions can be exported as managed solutions.
• Deleting an unmanaged solution has no effect on the components it contains, the delete simply removes the solution.
• Managed solutions can be removed, a process that removes the solution and its components.
• Managed solutions cannot be exported.
• When importing a managed solution, you can opt to maintain or overwrite any unmanaged changes.
• Importing an unmanaged solution always overwrites.

You always work with unmanaged solutions in development environments. But as you progress into controlled environments for user acceptance testing and production then managed solutions are often the recommended approach.

Patch Management

Patch management helps make applying revisions to existing solutions easier. One or more patches to a solution can be created from a solution and later rolled up (merged) back into the main solution.

Patches can be created from unmanaged solutions and applied to managed or unmanaged solutions. But unmanaged patches should not be used for production purposes.

Patches are only created from the parent solution. A parent solution can have multiple patches but a patch cannot have a patch. Each patch can only have one parent.

Because patches are dependent on the parent solution you can only import a patch if the parent is already present.

A patch version must always have the same major/minor version number as the parent solution. But the build / revision number must be higher. (e.g. A patch for a solution with a version set to 1.0 would be 1.0.1.0) If more than one patch is created subsequent patches will have a higher version. (So in the example just given a second patch to the parent solution 1.0 would become 1.0.2.0)

To create a patch, you select the parent solution and select the “Clone As Patch” option.

A dialog is then given to confirm the version number. Notice how automatically the build number of my “major.minor.build.revision” version number is incremented.

Exporting a patch is pretty much the same process as exporting a solution. As is importing them, expect they need to be imported in order. As it is not possible to import a patch with a lower version number than currently deployed.

At some point you will want to roll the patches up to me able to create a new major / minor version of a project. To do this you use the “Clone Solution” option. You can see below that I have selected the “Clone Solution” option from my patched solution.

It will allow the creation of a new solution with an incremented major/minor version number. (Notice below now the version number updates.) When this new solution is created the patches will no longer be seen in the list of solutions. The new solution with the incremented version can then be exported.

After I import the new solution as an upgrade the previous patch versions will all be rolled up and I will be left with one final solution.

This might sound complicated but if you test patches you will find the process is actually pretty straight forward. I do recommend that part of your revision include creating solutions and repeatedly applying upgrades and patches to observe the behavior.

It is possible to delete and uninstall a managed parent solution. Doing so will uninstall the patches to the parent solution in reverse order. It is also possible to delete / uninstall an individual managed patch.

It is also possible to delete an unmanaged patch. But this will be simply removing the patch not the underlying changes to components.

To repeat:
It is not advised that unmanaged patches be applied to or removed from a production environment.

Solution Layers

A note about solution layering may be useful! Because if we import multiple managed and unmanaged solutions we may need to understand what the final import on the user experience will be.

Managed and unmanaged solutions can “interact” with the underlying system solution. As these are imported layers of solutions will be created. Meaning you may need to understand how one solution “interacts” with another to create the final application behavior that will be observed by your end users.

The diagram below depicts this concept!

The system solution (shown in red) this represents the default application behavior.

Managed solutions are installed on top of the system solution. They can modify components found in the system solution or can include new components. Managed solutions can be layered on top of each other, as long as the managed solution enabled customization of its components.

Unmanaged solutions sit above managed solutions. (Don’t forget you create a managed solution by exporting an unmanaged solution.)

I suggest you study the diagram above in detail to appreciate the relationships between these layers of managed and unmanaged solutions. The top level (in yellow) represents the components the users will actually observe. I hope you can see that when a component is in all layers the one to be seen by a user will be from the top level.

 As always please include plenty of hands-on time in your preparation! I suggest you create various combinations of unmanaged and manages solutions. And don’t forget to try upgrading them. Hopefully this post has given you multiple pointers for the MB 200 certification.  

We are all being adversely effected by the Coronavirus, unfortunately many people may find themselves out of work or with theirs jobs at risk. As normality returns significant numbers of people could need to seek new jobs. For someone, unfortunately, returning to their old careers may be difficult.

But whilst this is happening the IT industry continues to have a major skills shortage.

With this landscape in mind now might be an excellent opportunity for you to consider learning a new skill. I’m a Dynamics 365 consultant with many years’ experience and I can honestly say it is a fascinating product to work with. Being a low code / no code environment you can learn everything needed without being a technical geek.

I am considering how I might play my small part to help with this Coronavirus emergency …. I’m a Microsoft MVP and Microsoft Certified Trainer. I’m not a key worker who can offer essential immediate help. But just maybe I can help you learn a new skill that when normality returns could prove useful. And if you are stuck at home learning a new skill might be a positive distraction!

I plan to organise free online training to help people learn Dynamics 365. As a Microsoft Certified Trainer my intention will be to present a training course for the MB-200 exam. It will then be up to you if you want to progress to the exam or not! MB-200 is the core exam for anyone wanting to learn about Dynamics 365 and a great starting point for your Dynamics 365 career.

I am looking for a small group of people who might benefit from learning this new skill.

I’m based in the UK so you would need to be able to attend online training in the UK time zone. (The training will be in English!)

The full course normally takes around 5 days when given a class room. As face to face learning isn’t an option I plan to run this as an online course. I do have a day job! But I can free up one day per week for the next five weeks. Meaning I can present parts of the MB-200 course each Friday for the next 5 weeks.

If you know someone who would benefit please forward my details to them or if you feel this might something you’ll benefit from please reach out. Please send me your name and email address plus a few details about yourself. Numbers will be limited! I may therefore need to select people who will find this training the most transformational. My email address is neil.parkhurst@npdynamics.com

Assuming I receive a positive and quick response, the first session will be Friday 27^th March.

FYI:

I am looking for people who want to start a new career in Dynamics 365! If you are already a Dynamics consultant looking to update your existing certifications then this might not be for you. (Sorry!) But if you have suddenly found yourself out of work or are just worried about your current position, then this free training might be perfect for you.

Additional call to action:

I am reasonably well followed on LinkedIn and Twitter but I assume most of my followers are already working with Microsoft technologies. If you read this and know someone who might benefit please forward my details!

neil.parkhurst@npdynamics.com

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

There is a section of the MB-200 skills measured statement which references languages. It is under the heading “Perform system administration” and is within the “Perform solutions deployment and testing” sections of the exam.

The Power Platform and Dynamics 365 supports many languages. Including English, Arabic, Chinese, Dutch, French, German, Spanish and many more. Each instance has a base language. Additionally we can enable multiple other languages in one instance.

Base Language

Each Dynamics 365 organisation will have a base language, just like it has a base currency. The base language is defined when you first enable an instance / environment and cannot be changed.

I assume you will often be testing Dynamics 365 using a trial instance! Below you can see that whilst creating a trial it prompts me to confirm my currency. I also have an option to select my language. (These will have been defaulted for me but you can override these settings.)

By clicking the “Change currency” option you can influence your base currency and region settings. Below you can see that before starting my setup I have changed my region to Netherlands.

After my Dynamics 365 instance was ready, as you can see below, it was in the Dutch language. Meaning my base language was now fixed to Dutch. (Not much use for me as I speak very little Dutch. But still testing out the process of creating an instance with an alternative language is a useful learning experience!)

We can also create a Power Platform instance without Dynamics 365. Below you can see that in the Power Platform admin center I am creating a new environment. Having clicked the new button I give my instance a name, select a region and define the type of instance. (Possible types are sandbox, trial or production.)

Having clicked next, I can select the default language and currency for this environment. You can see that I have again selected Dutch as my language.

TIP:
As part of your revision I suggest creating a trial or environment with a different base language. Even if (like me) you don’t speak another language! As you the point here is to understand the process or creating an instance with a different language.

Enable Additional Languages

You may have a requirement to operate a single system in multiple languages. This is also possible. First create your instance with a suitable base language. Then you can enable multiple other languages in the power platform admin center.

Below you can see that I have selected my instance and then I can use the settings option to access many system settings. Including an option to enable additional languages.

Within settings under the heading of “Product” you will find the languages option.

Within the language settings option you can select one or more additional languages. Having selected a new language you simply click the apply button and wait a few minutes for the language to be enabled.

Changing Language

Once multiple languages have been enabled your users can decide which language suits them best. This is done within their personal options.

The personalization settings option can be found from the “cog” icon within an application.

Below you can see that within the languages tab a user can select any of the enabled languages.

Notice that they can opt for different languages for the help pages and user interface. Also notice that the base language is shown but greyed out. As it can’t be changed.

Translations

Whilst enabling several languages will have created a system that can operate in multiple languages doing “just” that will probably not be enough! As whenever you create a custom entity / field any field names will only be in the local language. Therefore to fully support an alternative languages you may need to provide translations for all your custom fields labels.

To do this we need to export the text, edit the translations and import the text back into the system.

As an example, I decided to complete a quick test of this process! Below you can see that I have added several custom fields to the contact entity in my system. In my system it was useful to flag which of my contacts were MVPs or speakers at certain types of events etc. But as you can see despite my system having the Dutch language enabled these fields remain in English.

To resolve this issue we first export the translations. To do this open a solution containing the entities in question and use the export translations option. Below you can see that I have opened a solution in make.powerapps.com. I called my test solution “Language Demo” and just included my contact entity.

Once exported you will have a zip file that includes a file called “CrmTranslations.xml”. This file will need to be changed. To do this extract the contents of the zip file and open the file in a suitable editor. (I just used Excel!)

I have shown a copy of the file opened in Excel below. Notice that on the localized labels tab I can see all of the text values from my contact entity. A column is created for language 1033. (1033 being the code for the UK, which is my base currency.)

I then have two other columns for languages 1036 and 1043. These are French and Dutch as I have these languages enabled in my instance. Now I “simply” need to find any rows without an entry in these columns and enter the required translation.

Once you have completed all of your changes create a new zip file.

Having created a new zip file, I used the import translations option to apply my changes. Not forgetting to use the publish all customizations option after the import completed.

Below you can see that I entered the correct Dutch phrases for “Professional” and “Saturday”. Being just a test (and because I am lazy) I only changed these fields!

Assuming you try this you should find this process is quite simple. BUT you may need to consider that on a heavily customized system entering all of the translations for multiple languages could be a significant undertaking.

Hopefully I have given you a good introduction into language settings for the Power Platform / Dynamics 365. As always, I encourage you to get some hands on experience as part of your exam revision. I suggest you try enabling multiple languages and translating some custom fields. Enjoy!

I have recently been experimenting with both Omnichannel for Customer Service and Power Virtual Agents, as now the two can be a combined their integration seemed like an obvious thing for me to review. In this post I will document how I created my first “omnichannel virtual agent” and make a few observations along the way.

A good starting point might be for me to describe the use case for Power Virtual Agents that can hand off to a human agent. BOTs are great at answering commonly occurring questions as it is pretty easy to train them with suitable topics and responses. However real agents will always remain the best people to answer unusual questions or give responses when a judgement call is needed. In fact I personally consider a human hand off option as an almost essential feature! Without it your BOTs offer an intelligent conversation capability but when they “run out of steam” your potential customers are left in a frustrating dead end. Implementing an escalation from the BOT to a human avoids customers reaching this frustrating state.

Integrating Power Virtual Agents with Omnichannel for Customer Service allows us to define multiple queues and transfer customers from our AI friends to humans in an almost seamless manner.

In the video below I have given a demonstration of how Power Virtual Agents operate, how to create the virtual agent and how to configure Omnichannel for Customer Service to use your BOT.

Conclusion / Limitations

Overall I’m very happy and excited about the integration of Omnichannel for Customer Service and Power Virtual Agents. I’m already thinking about using this with one of my customers!

I am very happy with the virtual agent handoff, so I don’t want to be overly critical but I have seen a couple of limitations (with possible workarounds);

One “limitation” I’ve observed is that the Power Virtual Agent’s transfer option doesn’t link to opening hours…. I’ve often seen a BOT enabled out of hours, designed to help customers whilst the agents aren’t working. During these “quiet” hours we wouldn’t want the BOT to attempt to transfer to the absent agents. Out of the box I haven’t seen a no code approach to this scenario. I guess it would be possible to create two virtual agents, one that will transfer to a human and another that doesn’t. You’d then need a small piece of code in your website to decide which BOT should be active at any point. This approach would be pretty simple to implement but I’m looking for my implementation to be no code, hence why I see this as a limitation!

BOTs do not support skills based routing. But what if we want to apply skills based routing when transferring to our human agents? In my video demo I showed that we can use the “va_Scope” context variable to allow us to know when to route to a queue of humans. I guess we can simply ensure that the humans in that queue have the skills to handle any query from that Virtual Agent. But I would have liked to have seen skills based routing, maybe with the transfer request being associated with multiple Omnichannel for Customer Service skills. We might not have skills based routing from BOTs to humans but all is not lost! As the tile used in my virtual agent does include the ability to define a private message to the human agent, that might prove really useful! It wouldn’t take much effort to route particular chats to various queues based on the private message from the BOT. We’d use the context variable “va_AgentMessage”, which I believe would include the private message from the BOT.

Knowing what the possible context variables are might be useful! So below you can see a summary of all of the context variables available.

I hope this post and video will have been useful to anyone considering using Power Virtual Agents integrated with Omnichannel for Customer Service …. 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 field security.

There is a section of the MB-200 exam which has a focus on implementing security, you can see below that managing field security profiles is mentioned in the configure security settings section.

Field-level security can be applied to system and custom fields across the system. And by default is disabled for all fields. To enable field security on any field you open it in customizations and change the “Field Security” option to enabled.

Note: I have shown setting this field in the classic version of field customizations because at the time of creating this post the field security property could not be set in the newer customization interface.

Having created my field I added it to a form and published my change. Once published a key will show next to the field to highlight that it is subject to field security. (As shown below.) At this point only the system administrator can see and maintain the details in this field.

If any user, other than the system administrator, looks at the form they will see “******” in place of the data. (As shown below.)

Note: Below I have logged in as a user that has full organization level access on the entity but it not a system administrator.

It is important to realize that field-level security does not apply to just Dynamics 365 forms but everywhere you might see or maintain data. For example, below I have shown a view containing my “Secure Field”. Notice that it is blank, this isn’t because the field contains no data! It is because the current user does not have read privilege on this field.

Below you can see that field security even applies on editable grids ….

To grant access to fields which are enabled for field-level security you need to create a field security profile. This is done from the “Field Security Profiles” option which can be found in the security area of advanced settings.

When creating a field security profile you first give the profile a name and optionally a description.

Once you have saved the profile you can use the “Field Permissions” option to add whatever level of access is required. You can see below that I have granted read access on my field. But I haven’t granted update or create access.

Tip: Having just create access might be useful if you want someone to set-up a field when a record is created but then not change it afterwards.

Having created the desired field permissions, you can then assign users or teams to the profile. Below you can see I have assigned this profile to one user.

Tip: A real world scenario assigning teams to the profile might be the best option. As user teams helps to keep administration to a minimum.

Below you can see that after granting read only access the content of the secure field is now visible but the lock icon next to the signifies that it cannot be changed.

As always, I suggest your exam preparation involves plenty of hands-on time. So try creating some field security profiles to see how they operate. Doing so will also give you a chance to practice creating fields and maintaining forms. So a fun exercise!!

I hope this post has given anyone preparing for the MB-200 exam the basic information they will need to understand on field-level security.