As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at how to configure auditing.

Auditing is another key area to review as you prepare for the Dynamics 365 Customization and Configuration exam. You will find the auditing option in the settings area of Dynamics 365.

Global Audit Settings

We have an option to define global audit settings for the organization and another option to define entity / field settings. Meaning auditing can be defined at a system / organization level, entity level and field level. (Remember system, entity, field level auditing!)

At a system / global level you can enable auditing and define which areas to audit. You can also log when user log in / out of CRM.

Notice that the global audit settings option accesses the “System Settings” tab dialog that we previously saw when reviewing other system settings.

Auditing can be easily enabled for “common entities”, “Sales Entities”, “Marketing Entities” and “Customer Service Entities”. Hovering the mouse over the name of these entity groups will list the items that will be enabled if this option is selected.

Also notice that we have a hyper link that will show the status of all entities. Clicking this link will actually open your default solution. Alternatively you can click on the “Entity and Field Audit Settings” option we saw on the auditing menu.

Entity and Field Audit Settings

Selecting the Entity and Field Audit Settings option will actually open the default solution. Here you will see a column called audit status which will denote which entities are enabled for auditing. Notice that I have created a custom entity and enabled that for auditing. As auditing can pretty much be applied to any system or custom entity.

I that auditing can “pretty much” be defined on any system or custom entity as some exceptions exist. As shown below. Auditing is not applicable on product relationship, sync error, article template. Product association, feedback, activity or category entities.

FYI:
The activity entity can’t be audited but individual activity types such as phone call, appointment (etc) can be.

Notes:

• Auditing is not supported for read operations
• Auditing is not supported for metadata changes
• Auditing is not supported for text blobs, notes and attachments.

To enable any system or custom entity for auditing you can set the “auditing” option that you will find on the entity properties screen as you create / amend entities.

Additionally we can define which fields within the entity will trigger auditing. You can see below that I have highlighted the audit status on the fields within the account entity.

Audit Summary View

The audit settings also allow you to view and manage the audit logs. Below you can see the audit summary view that allows me to see when auditing has been enabled at an entity level. Plus, once enabled, any updates will start to show in the audit view.

Opening the update event will show us exactly what field(s) have been changed.

You may need to be aware that we can filter the audit summary view to help focus on particular audit records. But we cannot use advanced find to create bespoke system or personal views.

Audit Log Management

My test audit logs are very small but I’m sure you can appreciate that audit logs could quickly grow in size. You will therefore eventually want to recover database space by deleting audit logs.

This is a simple process of selecting a log and using the delete logs option to remove the log. Except you must always select the oldest log! To delete multiple logs you must keep deleting the oldest log until you have deleted enough logs.

Hopefully I have given you a good overview of auditing, including how to enable it and manage your audit logs etc. As part of your revision for MB2-716 you should try enabling auditing on various entities / fields. (Hands on experience is always the best!)

Hello all,

 I have been using the forums for answers for a while however this is one that has stumped me and I don't seem to be able to find an answer.

I would like a list of Accounts which have NOT had an invoice in the last 3 months. I don't seem to be able to work out the criteria required. I can get Accounts where they have invoices over 3 months old, but then I want to exclude any of those who have invoiced in the last 3 months. This seems impossible. I would really like this a an advanced find option as it will be really useful for our sales people. I can easily do it in SQL however it would be far better as an advanced find.

 Any ideas would be greatly appreciated. Did I mention that my boss wants the data today!! Ahhh..

 Thanks in advance

 Dave.

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at Document Management.

The document management options in settings allow you to configure SharePoint and OneDrive for Business integration. The settings available in an on-premise tenant are shown below;

I have shown the document management settings for an online organization below. Notice that we don’t have an option to install the SharePoint list component in an online instance. Also notice we have some additional options including the ability to enable OneNote integration, manage office graph integration and manage document suggestions.

I don’t believe the MB2-716 exam will test on specific SharePoint or OneDrive functionality in detail but you should understand their basic operation and installation.

SharePoint Overview

SharePoint integration supports the storing and management of documents in SharePoint document libraries, allowing them to be “surfaced up” directly in Dynamics 365 in the context of CRM records. This allows users to quickly find documents related to an entity without having to search a potentially massive SharePoint repository.

One advantage of this approach is that access to the SharePoint isn’t limited to Dynamics 365 users. As the documents are available via Dynamics 365 or directly in SharePoint. Meaning, for example, you could have a sales proposal documents held against an opportunity. This proposal documents can be reviewed and amended by anyone with SharePoint access, no Dynamics 365 license is required.

Of course, you could simply attach documents to notes and not use SharePoint integration! But SharePoint offers a number of advantages, including;

• Uploading a document in notes is useful for static documents that never change. But SharePoint integration allows you to leverage standard SharePoint features for collaboration and versioning.
• It is possible to search the SharePoint document library. Whilst searching attachments on notes is not possible.

It is important to remember that SharePoint does not replace the standard notes functionality. Instead SharePoint complements it, often a combination of both approaches will be used. For example, notes might be ideal for short ad-hoc comments, whilst SharePoint might be used for more complex documents. (Such as sales proposals, contracts etc.)

Two architectures exist for SharePoint integration. Client-side integration typically used in an on-premise scenario requiring the installation of a SharePoint list component. Or server based SharePoint integration which doesn’t require the list component. Server-based integration is the recommended approach whenever possible.

It’s worth knowing that SharePoint integration also supports integration with some of the other Office 365 products. Such as OneNote integration.

Client-side (List Component) v Server-based SharePoint Integration

There are two SharePoint architectures, client-side or server-based. (or server-side if you like.)

Client-side uses the list component. Meaning the Dynamics 365 client displayed in a browser “talks” to SharePoint via the list component. The list component provides the grid that displays SharePoint details in CRM.

A server-based architecture does not require the list component. Making it more robust and potentially faster. Future versions may only offer a server-based architecture! With a server-based architecture the “SharePoint grid” in Dynamics 365 is utilizing a native SharePoint component, meaning Dynamics 365 and SharePoint can communicate server to server.

Server-based integration is the recommend configuration for Microsoft Dynamics 365 online. However, currently a client-side architecture remains the recommend approach for Dynamics 365 on premise. As the list component supports both SharePoint Online and SharePoint on-premise (2010 / 2013 versions).

Enable Server-based Integration

Enabling server-based integration is a one-time process. The first step being to select the option to enable server-based integration. Once completed the option to enable server-based integration will no longer show and it will also not be possible to revert back to the list component.

Step one – click next.

Step two, select online or on-premise and click next.

Step three, enter the url for the SharePoint site you wish to integrate with.

After entering the url of the SharePoint site the site will be validated and then an enable option will allow completion of the process.

Enable Client Side Integration

Enabling client side integration differs as first you’ll need to download the list component. (Note: The list component only applies to an on-premise install.)

Once the list component is installed into the SharePoint site collection, in Dynamics 365 under settings in document management run the document management wizard. In which you will enter the site collection to configure.

SharePoint Folders

Enabling client-side or server-based SharePoint integration will have linked Dynamics 365 to the SharePoint site. This can be seen in the SharePoint sites option in Dynamics 365. When documents are added into Dynamics 365, they will be added into a folder at the document location for this site.

Note:
Multiple folder locations can exist for an individual record. And a single location can be shared between two records.

You use the document management settings option to define the folder structure to use and which entities are enabled for document management. Out of the box (by default) Account, Article, Category, Knowledge Article, Lead, Opportunity, Product, Quote and Sale Literature are enabled. But any custom or system entity can be enabled.

There are two folder structures possible. The default will be to create a separate folder in the for each record. An alternative is to make the folder structure entity based. With either Account or Contact as the base entity. For example, making the folder structure based on the account would create a parent folder for the account and then sub folders for each entity related to the account.

Having selected the required document management settings a SharePoint document library will be created.

Working with SharePoint

Once the setup has been completed, on any of the enabled entities a document section will exist in the navigation. From here you can view and associate documents with that entity.

From the associated grid on the entity you can create new documents or upload existing ones. Plus, additional document locations can be added or you can edit the current location.

In the example above you can see the documents associated with an account. As I have optioned for a document structure based on account you can also see documents associated to the account. Notice the folder structure!

It is also possible to use the Open location open to open the SharePoint document location.

Note:
If you are using client-side (list component) that it is possible to view some additional commands. Including Alert me, Download a copy, View short cut and version history. With the server-based approach all of these options are available by opening the document location and accessing them directly from SharePoint.

By selecting the document, it is possible to interact with the document by viewing and setting document properties for example. Or manage versions by checking the document in / out.

It is also possible to delete the document. Doing so removes the document from Dynamics 365 and SharePoint. But if you delete the Dynamics 365 record then the documents would remain in SharePoint.

If two records are merged their document location information is merged. This doesn’t mean the that SharePoint documents are moved or duplicated. Just that the newly merged Dynamics 365 record will point to both SharePoint locations.

Tip:
Edit Properties might be useful to fix a broken link! If someone moves or renames a document directly in SharePoint without considering “CRM” the link between Dynamics 365 and SharePoint can become broken.

SharePoint and CRM Permissions

Firstly, it is important to understand that there is no interaction which pushes permissions from Dynamics 365 to SharePoint. It will be assumed that the user operating Dynamics 365 will already have permission on the SharePoint document library. So a common problem with permissions might be that the users have permissions in Dynamics 365 but also need to be granted access on the SharePoint side.

From a Dynamics 365point of view two entities come into play, one for the SharePoint site and one for the document location settings. As with any entity in Dynamics 365 you can use the security model of Dynamics 365 to grant or restrict access as required.

OneDrive for Business

OneDrive for Business is included with Office 365 subscriptions. It provides a location for storing, synchronizing, and sharing work files.  Files stored in OneDrive for Business are by default private but can be shared with work colleagues.  Unlike SharePoint, where documents are by default shared to work colleagues.

Before configuring OneDrive for Business you will need to ensure your users have an appropriate license in Office 365 admin and OneDrive has been configured! See below that I have opened my user record in office 365 admin and initiated the provisioning of OneDirve.

Tip: Once you have started the provisions users will need to log out and back in for it to take effect!

By default, the storage space for each OneDrive for Business user is 1 TB. If you have one of the following Office 365 plans, you can increase the default storage up to 5 TB:

• Office 365 Enterprise E3, E4 and E5
  
• Office 365 Government E3, E4 and E5
  
• Office 365 Education
  
• OneDrive for Business Plan 2 and SharePoint Online Plan 2
  

OneDrive can be linked to Dynamics 365, meaning users can access files stored in OneDrive for Business within forms in Dynamics 365.

OneDrive for Business works with Dynamics 365 online and Dynamics 365 on premise. All users require an Office 365 license.

As with OneNote, to configure OneDrive for Business CRM must already be configured to use SharePoint using server based integration. (Note: This statement therefore implies the SharePoint list component is not supported.)

OneDrive for Business is enabled from settings / document management in the Dynamics 365web application.

Selecting the enable OneDrive for Business option will present the following dialog. Allowing you to quickly enable OneDrive.

Once you have enabled OneDrive, an additional option will be shown that will allow you to define the folder that will be used for store personal files. The default location will be “CRM”.

Once configured OneDrive for Business can be accessed from the documents option found in the navigation on entities in Dynamics 365. (Just as with SharePoint.) When a file is uploaded you can opt to store the file in SharePoint or OneDrive. It is also possible to create new files and open them directly. (Using Excel Online etc.)

Notice below that I have uploaded two documents against an account. One in SharePoint and the other in OneDrive for Business.

Notice that by selecting the document I have options to check out, check in, edit properties and also open directly in SharePoint or OneDrive.

Tip:
To share a OneDrive document you’d need to open the location of the document and share directly from OneDrive for business.

Also, you might want to consider the implications of changing an owner on a Dynamics 365 record. The ownership of files within OneDrive will not change, as they are personal to the user who created them.

You should also be aware that access to OneDrive for business is controlled by a privilege on Dynamics 365 security roles.

Hopefully this post has given you a good overview of the document management capabilities for Dynamics 365. And an insight into how to configure and use the SharePoint and OneDrive for Business integration. I hope I have included all of the main points which might popup in the MB2-716 certification. But as always getting some hands-on time will be important in your preparation. Good luck.


Hi,

I want to get the list of no. of enquiries with one of the word matching. for example if there are 5 enquiries with the below name

the fame

fame

famenine

tera

beta

the list should display all the first three name. Please help.

Rgds,

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at Data Management settings.

Data management options allow you to define duplicate detection rules, import data, manage bulk deletion jobs etc. In the following notes I will provide a summary of each of these features.

• Duplicate Detections Settings, Duplicate Detection Rules and Duplicate Detection Jobs
• Data Maps
• Templates for Data Import
• Add Ready-to-Use Business Processes
• Export Field Translations and Import Field Translations
• Bulk Record Deletion
• Imports
• Sample Data
• Data Encryption

Duplicate Detections Settings, Duplicate Detection Rules and Duplicate Detection Jobs

These three duplicate detection options let you define rules that are run as records are created in the Dynamics 365 database. These help you spot and resolve duplicates at source. Duplicate detection jobs are an option that uses these rules to review the current data to help identify potential duplicates in the existing data.

We first define the duplicate detect settings. These are global settings to decide when to enable detection. Options include;

• When a record is created or updated
• When Dynamics 365 for Outlook goes from offline to online
• During data imports

By default all of these options are enabled.

Duplicate detection rules allow us to define what constitutes a duplicate. Several rules will exist out of the box and you can create more or amend these as required. You can see a simple example below that will be triggered if two accounts have the same name.

Tip: Each rule will require publishing to make it take effect.

Notice that rules can exclude inactive records as required. And also be case-sensitive.

Once the detect rule has been created, if a user creates a potential duplicate a warning message will be given. Clicking save would continue with the creation of the duplicate, or clicking cancel will allow them to make any required changes.

We can also configure and run duplicate detection jobs to create a list of possible duplicates. Firstly you create a new duplicate detection job and define the records to be checked. Below you can see I have selected all accounts. (In the real work we may, for example, want to run a weekly job check that details for all accounts created in the last week. Etc.)

Having selected the records for our duplicate detection job we can define how it will run. It may be a one off job or we can use the “run this job after every” option to define a frequency. Plus trigger sending an email when the job completes.

Once the duplicate detection job has completed we can use its “view duplicates” option to review any potential issues. Selecting each of the duplicate records we can see a list of potential duplicates. And then take required action. Such as deleting, deactivating or merging the duplicate.

Data Maps

When we import data the details can be stored as a data map. This is a useful option if the import needs to be repeated multiple times, as any mapping of columns can be saved and re-used.

Templates for Data Import

The templates for data import option creates an easy way to generate an Excel template for collecting / importing data. You might, for example, want to create a template for capture of lead data.

Add Ready-to-Use Business Processes

Another option “add ready-to-use business processes” allows the expansion of the number of business processes that are available out of the box. It might be that you create all of your processes from scratch or it might be this option is used to give templates or starting points for business processes with the system. Running this option on my trial Dynamics 365 online environment created the following business processes. Notice that they have all been added in a draft status and would need to be activated before being used.

Export Field Translations and Import Field Translations

These options can be used to export and import localized language translations for field and entity names in Dynamics 365. To use these options you will need to have installed appropriate language packs first.

Note: You can also export / import translations for your product names and properties.

Bulk Record Deletion

Bulk record deletion is an option I use very often in Dynamics 365! Using the web interface you can delete individual records or all those selected in a view. As a view can only contain a maximum of 250 rows then bulk deletion is useful when you need to remove larger data volumes. It is also possible to schedule deletion jobs.

You first define a selection criteria. Below you can see an example, in which I am looking for all emails more than 2 years old. (24 months)

Once you have selected the criteria you can opt to run the job immediately, schedule it and also define a frequency in terms of “n” days.

Imports

A key feature of CRM is the ability to import data from other systems. The import option lest you see the status of current imports and to review an audit of past imports. The data maps option allows you to create data maps to make importing data easier. Or you can use the “Templates for Data Import” option to create a blank template to make the process of create spreadsheets ready to import CRM entities easier.

Sample Data

One useful option in data management is the option to enable and disable sample data. It is really handy when testing or demonstrating a CRM solution to be able to use this option to quickly create a sample dataset to work with.

Data Encryption

Microsoft Dynamics 365 uses standard Microsoft SQL Server cell level encryption for a set of default entity attributes that contain sensitive information, such as user names and email passwords. This feature can help organizations meet FIPS 140-2 compliance.

For Microsoft Dynamics 365 (online) and Dynamics 365 (on-premises), all new and upgraded organizations use data encryption by default. Data encryption can’t be turned off.

I have covered quite a few features in this post, all at a high level! You learning and prep for MB2-716 will be greatly aided by experimenting with these features. Enjoy.

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification (Microsoft Dynamics 365 customization and Configuration). This time I will look at collaboration. I have already covered SharePoint and OneDrive when I reviewed document management but you will notice that OneNote and Office 365 Groups are also specifically mentioned in the skills measured statement. So in this post I will expand on those.

OneNote

Let’s first review the subject of OneNote integration.

I guess your first question might be, what is OneNote? OneNote, as the name suggests is a product for taking notes. Notes can be simple items of text but could also involve screen shots, audio or even video that relate to whatever subject is being covered. Meaning that OneNote offers a much richer interface than that available with standard note taking. OneNote also supports co-authoring, allowing multiple people to collaborate on a single “document”. OneNote has a variety of clients you can install locally, run on-line and even as apps on mobile devices.

OneNote uses a concept of notebooks, each notebook can have sections and pages, Just like a real notebook!

Note:
OneNote also has a concept of section groups but this is currently not supported by the CRM integration. Meaning you should just use sections and pages when integrating with CRM.

From the social pane in CRM it is possible to open OneNote notebooks in the context of the currently selected record. You can then create and collaborate on OneNote documents using any of the supported clients.

OneNote integration uses SharePoint to store the notebooks. Because of this OneNote integration options can be found in the document management area of settings in CRM.

Important:
Don’t forget OneNotes uses SharePoint, so you need to enable that before using OneNote. This is because your OneNote notebooks will reside in SharePoint to make them accessible to all users.

Prior to enabling OneNote integration each entity requiring the OneNote functionality must also already be enabled for SharePoint. You then simply use the OneNote Integration option to select the required entities.

An alternative approach to enable OneNote integration is to navigate to the entity in customizations and enable in the communication & collaboration section.

Initially when you open an account (or any entity) that hasn’t had any custom notes created you will see a view something like the one shown below. Clicking on the “Untitled” option will open a OneNote and allow you to begin editing.

As sections are added into the OneNote notebook they will show in the navigation within the social pane in CRM.

Note: The level shown in the social pane is section. Within that section multiple pages may exist, to view the pages you’d need to open the section in OneNote.

Clicking on the section headings will open that section in OneNote Online. (As shown below.)

One “strange” thing to be aware of is the way section names do (and don’t) change. When a new notebook is opened it will contain one section with the name set top “untitled”. Clicking on this heading will load the notebook. If you rename the untitled section in OneNote online this change is not reflected back in the CRM social pane. To rename sections it is best to open them using the full OneNote desktop application. However adding new sections in OneNote online does correctly create the sections in the social pane.

If you remove a CRM record the associated OneNote notebook will not be removed from SharePoint. If this needs to be removed it will need to be manually deleted from SharePoint.

By default, CRM will create a separate document location and a separate OneNote notebook for each record viewed.

As with SharePoint integration you need to be aware that CRM access and SharePoint access (and therefore OneNote) are not directly linked. Permissions will need to be granted in the CRM security model and SharePoint independently. You need to ensure users have access to both CRM and SharePoint.

It is also worth understanding that SharePoint and OneNote configuration does not form part of the CRM solution. When moving from development to production environments any configuration will need to be repeated in both environments.

Office 365 Groups

The next piece in the collaboration jigsaw is Office 365 Groups.

With Office 365 Groups, you can collaborate with people across your company … even if they aren’t Dynamics CRM users. Office 365 Groups provide a single location to share documents, conversations, meetings, and more. They offer shared workspaces for email, conversations, files and even calendar events.

Enabling Office 365 Groups

Before installing Office 365 Groups you will need; an Office 365 subscription that includes Exchange Online and SharePoint Online.

Then Office 365 Groups can be installed as a managed solution, with CRM online this is available in the administration center for CRM

Having clicked the install button and accepted the license agreement you will need to wait whilst the install happens. It doesn’t take long!

After the install process has completed you will find a new option for Office 365 Groups in the settings area of Dynamics 365.

Before looking at how to configure Office 365 Groups, a word about security. You will need to ensure that all users needing this feature have a role with the ISV Extensions option enabled. You can see below that this is found in the customization tab of each security role.

Once installed Office 365 Groups can be configured from the settings area of CRM.

The list of possible entities for Office 365 Groups is limited to a defined set of system entities. Including account, contact, lead, case etc. Plus, any custom entities you create.

Notice that I also have an auto create option available, but selecting that may result in a warning that auto create is not recommended!

Having selected the entities, you wish to enable Office 365 Groups for the “Publish All” button is used to enable them for groups.

Note, this is the same as doing a publish all from the customizations area of CRM. Meaning that any unpublished customizations would be made live at the same time. (So watch for that!)

Using Office 365 Groups

Once Office 365 Groups has been enabled you can navigate to the Office 365 Groups option on the entity and from there start a group. Or connect to an existing one. Below you can see that I have opened an opportunity. I have then navigated to the Office 365 Groups option.

As I have yet to define any Office 365 Groups, I selected the create option. This results in the message shown below.

After a short pause a group will be created. You are now able to manage a group calendar, engage in conversations, share documents and access a OneNote notebook directly from this page.

Also this group can be accessed directly from Outlook online. Meaning all of this information can be shared with user who do not have access to CRM. This is very important from a collaboration point of view.

Below you can see that I have shown an Office 365 Group I have created on one of my opportunities. Here you can see that we can view a group calendar, conversation history, OneNote notebook, documents etc. (Directly in Dynamics 365.)

Any groups created can be seen and administered in the admin center of Office 365. It is important to be aware that additional groups could exist here that are not related to CRM.

If the group is removed in Office 365, CRM would not be aware of that change and would continue to search for the old location. Also, as with SharePoint and OneNote removing a CRM record will not remove the Office 365 Group.

Tip:
Office 365 Groups can do more! Opening the group directly in Office 365 Groups gives additional functionality such as Planner and Connectors. (Connectors allows us to connect this group to other services such as Twitter, Trello etc.) I suggest you experiment with Office 365 Groups to gain a wider understanding of its capabilities. In this post I have only scratched the surface as for the MB2-716 exam your focus would be in integration with Dynamics 365.

I hope this post has been useful for your prep for MB2-716. As always I strongly suggest you don’t rely on theory, the more hands on time you have with the product the better.

This is the next post in a series covering my revision for the MB2-716 certification. (Microsoft Dynamics 365 Customization and Configuration) In this post I will introduce the Dynamics 365 security model. Including an overview of business units, users and teams.

If you are an experience Dynamics 365 user, hopefully the concepts here are very common to you. But a quick bit of revision never hurt anyone! 

The security area of settings in Microsoft Dynamics 365 gives you access to most of the options needed to manage users, roles, field security etc. Use these options to configure how users interact with Dynamics 365 and allow or deny them access to data.

The options are as follows;

• Users, allows you to manage users and associate them with business units / teams / roles and assign licenses.
• 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.
• Hierarchy 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 option to consider is business units, this allows 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. (I wish!) Notice that most of the fields about address (etc) have been left blank. These extra fields are not essential and are really just for reference in the application, meaning they have no function with the security model.

Some points about business units you will 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.
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 organisational structure but this is not essential. Ideally the business unit structure should mirror whatever is needed to support the security requirements of an organisation.
8. Child business units can be renamed.
9. Child business units can be disabled.
10. Child business units can be delete 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: In past exams I have often seen questions around what can and can’t be done with root and child business units. Make sure you know this stuff!

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 uses heavily in the security model to drive which users get access to what records. I have created a very simple organisational structure below. With sales and service being split. Plus service being further split into UK and US teams.

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

Users

Firstly users will need to be created an authenticated. In an on premise architecture this will mean the user must exist within Active Directory and with online they must exist as a user with Office 365.

Note: If you sync your local active directory with your Azure active directory, it is possible to sign into CRM online using a local AD account.

Once the user is signed in, either via Office 365 or AD, then the Dynamics 365 security model is used to control what they can access.

When creating a user in CRM (on premise) we use the “Users” option found in the security area. The user name is the domain name and user name from active directory.

With Office365 the process is a little different. As you will need to assign a Dynamics 365 license in the Office 365 admin area. Below you can see that I have created a user called “Jasper Cat” and assigned a Dynamics license in Office 365. Following this process in Office 365 will create the user record in Dynamics 365 but I will then need to use manage roles in Dynamics before Jasper would be granted access.

Tip:
Notice that I have also assigned an Office 365 Enterprise E5 license. You may find you also need to assign additional licenses to grant access to any integrated extensions. (Such as OneDrive, Office 365 Groups etc.)

Note:
With online, when we create a user and assign a license in Office 365 the user is created in Dynamics 365. However at this point the user cannot login into Dynamcis 365 as they must also have a role assigned. The exception to this is when a license is assigned to a Global Admin in Office 365. As they will be automatically given System Administration access in Dynamics 365.

When creating users, the business unit is a mandatory field and will default to the root business unit. To access CRM a user must also be given at least one security role.

With online … You should also keep in mind that some information such as job title and phone numbers will be read only, as these fields are maintained directly in Office 365 admin not Dynamics 365.

With on premise an option exists to add multiple users. Having selected the option “NEW MULTIPLE USERS” you will be prompted for a business unit and the role(s) to assign. As all the new users will need to be added to the same business unit and have the same roles. You will then be asked to confirm some details such a license type.

Finally, you can select the users you wish to add from Active Directory. This approach is very useful when adding a large number of new users, you just need to keep in mind that all the users created will have the same business unit and role(s). So you may need to run the option multiple times if a structure of business units exists.

You cannot delete users. You can however disable them. With on premise you can simply disable the user within the Users area of CRM. With online you need to open the user in Office 365 admin and remove their license.

If you change a user’s business unit that can be done with the change business unit option. If the user owns a lot of record in CRM this process can take a long time! If you move a user from one business unit to another their security roles will be removed. So having completed the move new security roles will need to be added before they can access CRM again.

Roles

I will discuss more detail on how to create roles and how they operate in a future post. At this point it will enough to understand that each user can have one or more roles. And that you use the MANAGER ROLES option on the user’s record in Dynamics 365 to do this.

As I have said I will cover roles in greater detail later. But one concept worth mentioning here is that some roles will be inherited from the parent business unit. So even though I haven’t created any roles specific to the International Sales Department I still see all of the out of the box roles defined on its parent. (In this case the root business unit.)

Teams

Teams have several uses in Dynamics 365. Teams are essentially lists 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 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 “CRM”. Owner teams have members and the team can own records. (Assuming granted permissions to do so with a security role!) 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.

I will cover security roles in more detail in a future post but 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). Also, should you wish records to be owned by the team it will require 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!) Queues are explicitly mentioned in the skills measured for the MB2-716 exam, so I won’t expand on them here. But you should probably still 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 / dynamics 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 deal is very small and an access team is never required for that opportunity. Or it might be a large deal that needs multiple people from sales 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.)

NOTE: When users are added to the sub grid in background an access team for this specific record is automatically created. By default you aren’t going to see this team in the security settings area of CRM. But you can do an advanced find on teams to view it if required.

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 in CRM. 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 record 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.

I hope this post will have helped you revision for MB2-716. We have covered quite a bit! In trying to explain the basics of the Dynamics security model we have reviewed business units, user management, owner teams and access teams. As always experiment with these concepts hands-on. Next time I will dive deeper into the security model looking at security roles in more detail and other concepts such as hierarchical security.

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look a little deeper into the Dynamics 365 security model.

I have already given an overview of security, when I explained the concepts behind business units, users and teams, in this post I will build on this information giving more details about the security model, including roles and hierarchy security.

Introduction

Security is a very significant part of configuring your Dynamics system, as ensuring the users can see the information they need is essential. And possibly even more fundamental is restricting access to sensitive information! But security does more than just manage data access, the interface is often enhanced for users by restricting access to entities they don’t use. By offering less options and therefore creating a cleaner UI.

Business units provide the foundation for the security model, roles are then defined that sit within the business units. Each user or owner team will be assigned a business unit and one or more roles. This combination of entities provides the basis for the Microsoft Dynamics 365 security model.

However, beyond this “basic” structure of roles we have other options such as Access Teams, Hierarchy security, field security and role based forms. I have already described how access teams can be used to control access in a fluid manner to individual records. Later in this post I will describe how hierarchy security can grant permissions based on someone’s position in the organization. (A sales manager for example, might be given access to all the opportunities created by his sales team.)

Security Model

The security model does more than provide access to a record, as you can control what actions a user can take. Including creating new record, updating existing ones, deleting data, sharing and even if we can append (or append to) data.

The security model is also used to control access to parts of the user interface, including forms (role based forms), fields (field security), dashboards and business process flows. (Dashboards and business process flows can be enabled for all or nominated security roles.)

It is also possible to allow or deny access to various features of the software. Such as bulk edit, merge, sync to outlook, export to excel, print etc etc. I have, for example, worked in a company that wanted to protect its lead data. So the field sales team could not export data to Excel but this capability was given to sales managers.

For example, below we can see that in the business management tab of a security role we can control many options relating to privacy and many more miscellaneous options. Privacy options doing things like restrict users from being able to export data to excel. In miscellaneous we have many diverse options including restricting using from using the bulk edit feature or merging records.

It should be noted that the security model will apply to all system AND custom entities. Plus, as already mentioned, all users must be assigned at least one role. If they aren’t they will not be able to access Dynamics 365.

Tip:
Roles can be assigned to owner teams or users. When a user is part of an owner team they inherit the permissions granted by the role on the team. Consider this, as adding a user to a team effectively gives them a role.

Security Roles

Security roles define the privileges which will be granted to users or owner teams. Each can have more than one role, with the security model working on a heritance model. Meaning the user will get the sum of the privileges granted in all the roles.

Roles are created at a business unit level. If a role exists on a parent business unit all of its child business units inherit that role. It is quite common to keep security roles simple be defining one set of roles that exist on the root business unit, they then take effect in all business units. But when you need a more granular approach to grant “special” access to a specific group within the organization this structure will allow it. Below I have shown that if you open an inherited role you cannot change it, as any alterations must be done in the parent business unit.

Note, you can copy the out of the box roles to create a new one if changes are required.

User can be added to roles by using the MANAGE ROLES option from the user record.

Note:
When changing the business unit of a user the associated security roles are removed. The user will not have access to Dynamics until a new role is assigned. Meaning they can also not log into Dynamics 365 until a new role is assigned.

A set of default roles ship with Dynamics 365. You can use these out of the box, alter them as required or copy them to create your own roles. Personally I like to leave the out the box roles unchanged, I then copy them as required. Effectively using them as a template for my bespoke security model.

Out of the box roles include sales manager, salesperson, marketing manager, scheduler etc.

When we look at a role we can see LOADS of privileges that can be set. These are grouped into tabs that follow the functional areas of CRM, such as marketing, sales etc. We also have a tab called “Core Records”, here you will find the most significant entities that are common to all areas of CRM.

We also have a tab called “Custom Entities”, this is where all of your custom entities will be shown. Some of these will be created by you as a developer but others may relate to third party solutions you have imported.

Each entity can have eight different types of privilege. (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, assign gives the ability to change the owner of the record, to another team or user.
• Share, 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.

Under each of these headings you will see a circle. This defines the scope of the access level being granted. A red circle means no access; a solid green circle means total organization level access. In-between we have several options which grant access to just records owned by the user, records within their business unit or records in their business unit and its children. (A detailed definition of these options is given below.)

NOTE:
Entities which can be user owned support all of these variations but organization owned entities will either be a red circle or sold green dot. Simply as the other options don’t apply to them. (You either have access to an organization owned entity or you don’t!)

Teams & Security Roles

Some things to note about teams and security roles include;

• Roles can be assigned to owner teams. (Roles can’t be assigned to access teams.)
• A security role MUST be assigned to an owner team for it to own records.
• A team always links to one business unit.
• Team members can belong to any business unit.
• Heritance of security permissions works across users and teams. Meaning the privileges from roles assigned to the user are combined with roles assigned to teams the user is a member of. (Granting them the least restrictive access level.)
• It is possible to have two security roles with the same name. Each role could be linked to a different business unit and could give users in each business unit differing levels of access. You need to be aware of this as it could appear confusing!
• Just like with users, if you change the business unit on a team the security roles associated with the team are removed.

Tip:
On teams (or users) you can select multiple teams in the list view of teams. Then the MANAGE ROLES option can be used to add roles to multiple records at the same time. You should however be aware that it is not possible to remove teams (or users) from roles in this manner.

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, the first uses settings on the system user entity in CRM. Each user can have a manager defined. It might be that the manager needs to have access to all the records of their reports.

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. You will find the Positions option in Security area of settings in Dynamics 365.

Note: It should be understood that hierarchy security is not designed to replace that 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 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 the CRM users) or based on custom position hierarchy. 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.

As always please experiment with all of these options as port of your preparation. Hands-on usage of the system is by far your best preparation! Do not rely on theory alone.

Hopefully this post will have been useful for anyone preparing for the MB2-716 certification. You may have noticed that I didn’t describe field security, role based forms or enabling roles on business processes & dashboards! This is simply because I haven’t covered how to create and customize entities, I will explain additional security options when I do that….. 

I'm using the Dynamics CRM 2016 Workflow Tools Solution to automatically update a rollup field on a parent record when child records are added.  This seems to work fine, but when I'm working in the child subgrid from the parent form, the new rollup value doesn't show up until I manually reload the page.

When I tried this out a while ago on CRM 2015, I was able to put in some JS to refresh the page - something like this:

http://andreaswijayablog.blogspot.ca/2011/08/refresh-form-after-subgrid-changes-or.html

However, this and other variations I've found and tried no longer seem to work on 2016.  I've tried what seem to be the updated functions/methods:

function Form_onLoad() {
    setTimeout("SubGridRefresh();", 2500);
}

function SubGridRefresh() {
    var grid = Xrm.Page.getControl("MySubGrid");
    if (grid) {
        grid.addOnLoad(ReloadForm);
    }
}

function ReloadForm() {
    Xrm.Page.data.refresh(true);
}

And no luck.  It gets to the ReloadForm function, but the rollup field still doesn't refresh til I reload manually.  Also tried this code for the reload:

    var id = Xrm.Page.data.entity.getId();
    Xrm.Page.data.save();
    Xrm.Utility.openEntityForm("myEntity", id);

This does reload the page, but it does it even if I try to go to the second page of the subgrid, which makes it not useful at all.

Any thoughts on how I can accomplish this?  (Specifically, the reload when subgrid data is updated.)

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at Themes.

Themes are a simple topic! But they are specifically mentioned in the skills measured statement, so don’t forget to revise them!!

Themes allow you to create a custom look to your Dynamics 365 solution. I often find that changing the colours to fit in with an organizations corporate branding and adding the company logo creates an interface users find inviting.

The themes option is available in the customization area of settings.

When you first load the themes option you will see that you only have a default option. You could change this! But leaving it unaltered and using the clone option to create a copy is probably a better option. That way we can revert back to the default if required.

Clicking clone with a theme selected will create a copy.

You can now open the copy and amend it.

Tip: With CRM2016 we could change the colour of the business process flow in themes. This feature is not available in Dynamics 365.

Name

You don’t have to change the name but it probably makes sense to give your theme a new name.

Logo

The logo field will initially be blank. Leaving this field blank will continue to show the default Microsoft Dynamics CRM logo. If you wish to change the logo you will need an image file that is 400 x 50 pixels.

By way of a demo I have quickly created a truly scary looking logo. I have simply created an image using “Paint” and then loaded it as a web resource.

Back in themes I selected my web resource as the logo. Then I saved my theme and selected the publish theme option. You always need to publish the themes to make them take effect. Finally, below you can see my updated theme with a “lovely” new logo.

Tip:
A theme doesn’t take effect until it is published. You can only have one default theme. And the default theme is the currently published theme. Meaning several themes can be defined but only one is active at any moment in time.

Tip: Themes cannot be included in your solution. Meaning they are not portable between organizations.

Logo Tooltip

Logo Tooltip lets you change the logo tooltip.

Navigation Bar Colour

Changes the navigation bar colour. Note, with all the colours you enter the hex colour code value. So orange is #EE7600.

Warning:
Changing the theme doesn’t always give pleasing results!!!!

Navigation Bar Shelf Colour

The “Shelf” is shown in yellow below.

Header Colour

The header colour is the colour of heading text in CRM. See below that mine is pink! (This colour is also used for tab names on Dynamics 365 forms.)

Global Link Colour

Changing my global link colour to pink effects all hyperlinks in the system.

Selected Link Effect

This colour is used when selecting links, say in a sub grid. As shown with my pink bar below.

Hover Link Effect

As you hover over links in CRM their colour changes. Below you can see that just hovering over an account in this list has turned it yellow.

Accent Color for Mobile Client

A new feature in Dynamics 365 is the ability to set the accent colour in the mobile client. This has replaced the older setting to change the colour of the business process flow bar.

Note:
Unfortunately I couldn’t identify any effect of changing this value! I did however observe that the header colour and default entity colours take effect in the mobile client.

Default Entity Colour

This option changes the default entity icons in the navigation. See how mine are pink!

Default Custom Entity Colour

Changes the colour of custom entities.

Control Shade and Control Border

These two options work together!

See below how the shading and border around the currently selected field have changed to yellow and pink.

Themes are a pretty simple concept, but even so, as you revise you’re the MB2-716 exam don’t forget to get some hands-on experience of them.


As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at Email Services.

Before revising a topic I often like to being by reviewing the skills measured statement, this time the statement that refers to email services is shown below;

• Configure email services
  
  • Identify integration options, configure email server profiles and default organization email settings, enable server-side email synchronization, enable folder tracking, map exchange folders, set up and configure the CRM App for Outlook
    

This statement on email actually covers quite a lot of features, we therefore have quite a bit to cover. So let’s get started!

There are many combinations of email / CRM server architecture that are supported, email may reside in a local Exchange server and be connected to an on premise instance of Dynamics 365. Or maybe Dynamics 365 is online and making use of Office 365. Email integration enables users (and queues) to send and receive email in and out of the Dynamics 365 application, plus integrating with exchange allows appointments, contacts and tasks to be synchronized. It is important to be aware that not all features are mandatory, you could for example only configure outgoing email and opt not to synchronize.

Some common uses of email integration include;

• Outbound emails from Dynamics 365. Either sent directly from Dynamics 365 users to contacts, accounts (etc) or automatically via workflow.
• Updating contacts, appointments and tasks between Dynamics 365 and Outlook.
• Inbound emails into Dynamics 365, including automatically taking emails into queues. (e.g. support emails into a support queue.)
• Record creation rules to convert inbound emails into Dynamics 365 entities. Such as creating a case from an inbound email.
• Tracking of emails from Outlook into Dynamics 365. (For example sales “conversations” tracked against an opportunity.)
• Support for mobile devices.

Email Synchronization Options

There are several options for integrating email with Dynamics 365 including;

• Dynamics 365 for Outlook
• Server-side synchronization (The recommended approach)
• Email router (Important Note: Deprecated from December 2016 Update onwards.)

For Dynamics 365 on-line / office 365, Server-side synchronization is the recommended approach. It allows Dynamics 365 and Exchange to communicate with no additional client software or server processes.Server-side synchronization is a required component if you wish to enable the email folder tracking feature.

If you use Dynamics 365 for Outlook for email integration users are required to be logged into Outlook for sending / receiving emails. However, server-side sync does not require this. As the name suggests, all of the processing is done on the server meaning the user does not have to be connected to a client.

Note:
Even when using server-side sync you can still opt to use the Dynamics 365 for Outlook client as it provides access to all Dynamics 365 data within Outlook.

Note: The email router has been deprecated from December 2016. Therefore you should migrate away from this option!

Server-side Synchronization

Server-side synchronization is specifically mentioned in the skills measured statement and is the recommended approach, so let’s look at that in a little more detail.

To track emails AND synchronize appointments five configurations are supported for server-side sync. Those being;

• Connect Dynamics 365 (online) to Exchange Online
• Connect Dynamics 365 (online) to Exchange Server (on-premises)
• Connect Dynamics 365 (on-premises) to Exchange Server (on-premises)
• Connect Dynamics 365 (on-premises) to Exchange Online
• Connect Dynamics 365 to POP3/SMTP servers

The table below gives additional detail on the supported combinations of email synchronization and synchronization of appointments, contacts and tasks.

FYI:
The above table has been copied from a TechNet article on supported emails configurations. You can view it here.

Configuring Server-side Sync

Three steps are involved in configuring server-side synchronization;

1. Configure system settings.
2. Configure the server profile.
3. Define and configure mailboxes for users / queues.

Options for all of these steps can be found in the email configuration options in the settings area of CRM.

The email configuration settings option lets you define the configuration of email you wish to deploy. Including server-side sync, email router and outlook. As part of your preparation it is worth going over this screen to be aware of the key options available.

Note: Notice the warning that if you change from email router to server-side sync the router will be blocked for email processing.

Tip: Notice the “Configure default synchronization method” section in system settings. It maybe common that most users have the same settings, so defining the defaults here will help make the process of creating new users easier. It is also possible to open an existing mailbox and use the apply default settings option.

Also notice that you can configure server-side sync and email router to only process emails for approved users and queues. This is the default and the reason why all mailboxes (by default) must be approved before being tested/enabled.

The next step is to create an email server profile. A step which is done automatically if you are using CRM online and Exchange online. It is possible to have multiple email server profiles, in that scenario mailboxes will be linked to an appropriate server profile. This might be useful when migrating from one configuration to another. Or possibly simply done to create logical groupings, maybe all the user in the south are on one profile and the north on another. This logical grouping might be useful as error messages from all the mailboxes associated with each profile are rolled up.

Mailbox records get created when users or queues are created. These can be amended to govern what type of email synchronization is required for each individual mailbox.

Mailboxes must be approved and tested / enabled for them to operate. FYI, occasionally an email may force a permanent error and then the mail box would need to be re-approved / re-tested.

Also notice that a mailbox can be a forwarding mailbox.

Notice that the synchronization method on the mailbox can be set for “incoming email”, “outgoing email” and “appointments, contacts and tasks”. For example, incoming email might be handled by the email router, whilst appointments remain on Microsoft Dynamics for Outlook.

Also, importantly the method can be set to none. Say you wanted to block all outgoing mail from a particular mailbox that could be done.

Forward Mailboxes

Often each user will have dedicated mailboxes, so that each user has an individual email address. (and mailbox configuration.)

With a forwarding mailbox large numbers of users can be configured to link to one forwarding mailbox. One mailbox is configured as a forward mailbox; then multiple users forward their mail to that forwarding box for tracking in Dynamics 365.

The advantage being there is only a need to configure one mailbox but the disadvantage being you sacrifice the ability for users to individually send emails from Dynamics 365.

In a call center you could configure everyone to use a forwarding mailbox. This would work because in this scenario synchronization of individual appointments, contacts and tasks is not essential. But in a sales environment, each field sales person would need a personalized view of their contacts and appointments. Meaning a forwarding mailbox would not be appropriate for them.

Note:
Don’t forget that a mixed deployment is possible. With some users working with a forwarding mailbox and others having individual mail accounts.

Server-side sync monitoring / performance

Monitoring email usage will be an important administration task to ensure smooth running. Whenever an error occurs an alert event is triggered and can be seen at an email box or server profile level. These can be for information, warning or errors. There is also a server-side sync dashboard available, this gives details of how many boxes are healthy and how many have continuous or warning errors. Plus, it contains charts to help see the current and historic performance for email synchronization.

Sometimes it may also be useful to go to the mailbox and select “Download Mail Details”, this will give full details of the configuration of that mailbox.

Having configured Email and mailboxes your MB2-716 revision will probably next focus on email client options. I will cover email clients in my next post.

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for their MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at Email clients and folder tracking.

I covered email setup and synchronization options in a previous post, so this post will concentrate on email clients.

The email client options you’ll need to be aware of include;

• Dynamics 365 for Outlook Client– an add-in for Microsoft Outlook (Allows off line capability)
• CRM App for Outlook (Dynamics 365 App for Outlook)– supports tracking of emails from browser online version of Outlook and full Outlook client.
• Folder tracking– supports tracking of email folders via server-side sync and isn’t tied to any particular email client.

Before I continue to expand on these options lets refresh our minds again about the skills measured statement. I wish to flag this for a reason! Notice that the Outlook client is not actually mentioned. I will however briefly describe it, so that you are aware of this option.

Note: You may notice that in the skills measured the statement is “CRM App for Outlook”. CRM being a term that Microsoft doesn’t typically use to reference Dynamics 365! Therefore we should assume the term “CRM App for Outlook” and “Dynamics 365 APP for Outlook” are interchangeable. Either phrase means the same thing!

Dynamics 365 for Outlook Client

For many versions of “CRM” we have had the Outlook client. This can be downloaded and installed as an add-in with Dynamics 365. It gives imersive access to all your CRM data. But does have the “downside” of requiring a client-side install.

Users maybe prompted to download apps within the web interface. A system administrator can control this message from system settings. As shown below;

As mentioned users maybe prompted to download Dynamics 365 apps, alternatively they can download themselves from their settings “cog”. This will take users to an option to download the Dynamics Outlook client.

Notice the Dynamcis 365 App and Dynamics for Outlook client are both mentioned in the app options. Clicking the blue button will install the full Outlook client.

Some key features of the Outlook client include;

• Client side add-in for Microsoft Outlook potentially provides most immersive experience of any email client.
• Supports tracking of emails.
• Synchronizes appointments, contacts and tasks.
• Allows access to CRM data directly from Outlook.
• Off line capability,
  • takes subset of data off line based on off line filters you define.
  • Synchronizes data back to CRM when you next go online.
  • Several features aren’t available off line, including assigning records, converting orders to invoices, sharing records, running workflows etc.
  • Duplicate checking is disabled when off line.  But synchronization settings do allow duplicate checking to take form during offline to online synchronization.
  • If an off line change is set to trigger a workflow the workflow will be run when you go back online.
  • Security permissions remain the same in off line and on line modes.
  • Articles, sales literature and mail templates can be viewed off line but can’t be altered.

See more details on how to setup the Outlook client here.

See more details about configuring Outlook’s offline mode here.

CRM App for Outlook – Setup

Unlike the older Dynamics 365 Outlook client the “CRM App for Outlook” is specifically mentioned in the skills measured statement, so let’s look at that in more detail.

The following table shows the supported configurations, you should note that to use the Outlook App on premise Internet Facing Deployment (IFD) will need to be enabled.

You can see and which users are enabled to use the app from within the Dynamics 365 App for Outlook settings option. Note, each user will need a correct defined mailbox and for that mailbox to have been approved, tested & enabled.

Below you can see the results I receive when the Dynamics 365 App for Outlook option is selected. Notice that two of my users have a status of pending. This is because they have also recently been enabled and it can take up to 15 minutes for the app to become available.

You may also want to take not of the fact that the Outlook App makes use of the relevance search capability. (FYI: Relevance search is not enabled by default meaning a system admin will need to enable in system settings.)

CRM App for Outlook – Online

Once the Outlook App has been enabled you will see the Dynamics symbol appear in Outlook web access and be able to track emails (etc) directly from the online Outlook app.

Dynamics App for Outlook – Outlook

What I describe here is the result of enabling the Dynamics 365 App not the Outlook client! (You should probably try both as part of your revision to be able to compare them. But I am mindful that the app is the one mentioned in the skills measured!)

The Dynamics App for Outlook is “lightweight” meaning it will have less impact on your local system resources than the full Outlook client.

Below you can see that the Dynamics 365 icon has become visible in Outlook. I have shown this on an appointment but obviously you will also see it on emails etc. Clicking the icon opens a side panel that allows me to track untracked items. Or for tracked items view a summary of the associated CRM data. And by clicking on the names of the contacts / accounts (etc) I can open them directly in Dynamics 365.

Folder Tracking

• Became available as new feature in CRM 2015 Update 1.
• Requires Server-side Sync.
• Does not require the installation of a CRM specific email app or client.
• Allows users to simply move email into a folder to commence tracking.
• Each folder is mapped to define how to set the regarding field on the emails.

The steps involved in configuring folder tracking are;

1. Setup server-side sync. (As required for folder tracking)
2. Enable folder tracking in the system settings.
3. The users will then create folders under their inbox.
4. Then in the user settings folder tracking rules can be configured to map those folders to Dynamics 365 entities.

Folder tracking is enabled from system settings in the email tab.

Then in the user options in the email tab users can configure folder tracking rules.

A common approach will be to create a folder for each one of the key clients someone owns. As emails are received from these account simply dragging them into the folder for that account would make the email available in Dynamics 365.

Below you can see that I have mapped a folder within my inbox called “Messages from John” to my CRM record for John. One thing to notice if the last synchronized date / time. As after the folder is created in your inbox it will not be available in these personal options until a sync has been completed. (Typically every 15 mins.) This also highlights the fact that folder sync is not real-time. There will be a delay from moving emails into a folder in Exchange and it arriving in Dynamics 365.

Note : You can only track folders or subfolders inside your Exchange Inbox. Only the folder you select will be tracked. For example, if you select a folder that includes subfolders, the subfolders aren’t tracked unless you specifically select them in this dialog box. The maximum number of folders you can track is 25.

Also, within the email client you could define rules to move emails automatically into folders based on various criteria. Assuming that folder is tracked into Dynamics 365 this gives an easy method to automatically track selected emails.

View this link for more details on folder tracking;

https://www.microsoft.com/en-us/dynamics/crm-customer-center/track-outlook-email-by-moving-it-to-a-tracked-exchange-folder.aspx

If you aren’t really familiar with the Outlook client and Dynamics 365 Outlook App I suggest you send quite a bit of time experimenting with these options are part of your revision for MB2-716. Enjoy.

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at entities.

It is very important to realize that customizing entities will be very much at the heart of the customization and configuration exam. So spending a good amount of time actually creating and customizing entities is very important. Please only use these notes as revision pointers! You should (and must) become very familiar with actually customizing entities. Just knowing the theory won’t be enough!

Entities are at the center of anything and everything we do concerned with customizing Dynamics 365, obviously it ships with many out of the box entities such as contact, case and phone call. Beyond this you can create your own custom entities to extend the capabilities of the base product. One important concern here is knowing when to use an existing system entity and when to create your own from scratch.

Entity Types

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

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

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

Entity Assets

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

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

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

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

Entity Ownership

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

Note:
system activity entities or custom activities are always user or team owned.

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

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

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

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

Entity Properties

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

For the MB2-716 exam it will be important that you become familiar with all of the main properties on an entity and appreciate which can and can’t be disabled. It will be productive preparation exercise to create some entities and experiment with what happens when you try to enable / disable various properties. Below you can see I have highlighted a number of entity properties that cannot be changed after the entity is created.

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

• The entity name cannot be changed, and will be prefixed with the publisher prefix.
• Display name and plural name can be changed.
• Ownership can be “User or Team” or Organization. Once set it cannot be changed.
• You can optionally enable entities for the interactive service hub and you can disable this option if required. By default an custom entities are not enabled for the interactive service hub.
• Each entity can be given a colour; all custom entities will default to green. But this can be changed.
• All entities will have a primary field, called “name” by default but this can be changed. The primary field can only have a type of “Single Line of Text”. It will default to a length of 100 but this can be changed. (Note: The primary field is not the database primary key; it does not have to include a unique value. Behind the scenes each record has a GUID which is an automatically created primary key.)
• On creation entities can be defined as being an activity entity. Custom activity entities can optionally be displayed in the activity menus. All activity entities will be by implication User or Team owned. All activities share a common set of privileges.
• Having saved an entity, the following properties are read-only, meaning they can only be defined as you create an entity,
  • Name
  • Ownership
  • Define as an activity entity
    • Display in activity menus
• Once enabled on an entity the following properties cannot be disabled;
  • Business process flows
  • Feedback
  • Notes
  • Activities
  • Connections
  • Sending email
  • Queues
• Notes, activities and connections are enabled by default when a custom entity is created. But they can be disabled on create.
• An entity can be shown in none, one or multiple areas in CRM. Out of the box the areas include sales, service, marketing, settings and help center. You can only change this option for custom entities it is not possible to change the display area for system entities.
• Document management, access teams, allowing quick create are all examples of properties that can be turned on and off.
• Enable for mobile, allows you enable the entity for mobile and if you require mobile offline. Plus you can configure download filters to drive how much data will be available offline.
• Properties are grouped under several headings; these include;
  • Process– allows enabling an entity for business processes.
  • Communication & Collaboration– Collaboration options include sending emails, access teams, queues etc.
  • Data Services– data featuring include auditing and duplicate detection etc.
  • Outlook & Mobile– Allows an entity to be enabled for mobile and phone access.
  • Help

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

Managed Properties

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

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

Update ICONS

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

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

Note:
Icons will need to exist as web resources.

System v Custom Entities

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

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

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

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

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

You do need to be aware that there are some limitations on customizing system entities. Such as you can’t change their icons or their display area.

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

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

Entity Controls

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

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

Deleting Entities

You may need know the following things about deleting entities;

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

Hopefully this post has given you a good overview of the items you’ll need to revise around entities. If you have previously studies for the MB2-712 exam you will find much commonality with the MB2-716 exam! But still make sure you fully understand some of the new features such as editable grids.

The next meeting of D365UG/CRMUG Birmingham will be held on 7^th June at 6:30pm.

Why attend? Here are some great reasons;

• Meet some fantastic people who are passionate about Microsoft Dynamics 365 / CRM.
• Discuss your burning issues with the assembled experts.
• See some exciting presentation. (more details below)
• Attendance and parking is free.
• Open to all. (CRMUG members and Non-members.)
• Get a free buffet!

Last time our buffer went down a storm (reason enough to attend!) ….

Location: 75 Harborne Road, Edgbaston, Birmingham B15 3DH.

Download a map.

You can register now onMEETUP.COMorCRMUG.COM

Our Presentations will be very exciting an topical.

The first presentation will be focused on data quality. I know data doesn’t sound interesting!! But data is at the heart of everything we do with CRM, poor quality data results in low standards of customer service or ineffective marketing campaigns. Almost every CRM project struggles to resolve data issues. In particular duplication of leads, accounts and contacts. Rowland Dexter will explain how Paribus Discovery and Paribus Interactive and be both the prevention and cure for this “illness”.

Secondly I will be present a wonderful new product from CafeX. 71% of customers visiting your website expect to receive help within 5 minutes. 31% actually expect that help to be immediate! How can companies exceed or even meet these customer expectations??? One way is to implement sophisticated web-chat capabilities. I will show how with Live Assist we can implement web-chat (and much more) with minimal effort.

Duplicate Data – Prevention and Cure

Rowland Dexter is the Managing Director and joint founder of QGate. He supports QGates’ vision of ‘Creating a world in which data works’. Rowland will explain how Paribus Discovery can aid data deduplication and how Paribus Interactive will prevent duplications.

Quickly identify duplicate problems and cleanse your CRM systems

Paribus Discovery is a data deduplication solution that enables you to Identify, Resolve and Cure the duplicate data plaguing your CRM system.

Empowering Every User in the Prevention of Duplicate Data

Paribus Interactive brings sophisticated data matching to CRM in a way that enables each and every user to be aware of potential duplicate data across Accounts, Contacts and Leads.  It provides immediate identification of potential duplicate records as well as enhanced lookup and search capabilities.  Which means that users will find existing records easily and therefore not add duplicate data.

Increasing User Adoption and Customer Satisfaction via better data quality with Paribus Interactive.

You can register now onMEETUP.COMorCRMUG.COM

Live Assist from CafeX

I’m a Dynamics consultant working for PowerObjects, for many years I’ve been passionate about contact centre applications. Meaning I’m very excited to present Live Assist from CafeX.

With growing customer demand even the smallest contact centres need to offer omni-channel support. Working in a contact centre is no longer about answering the phone! Web-chat plays an increasingly important role in our digital communication strategies. Live Assist adds web-chat capabilities into Dynamics 365. And much more … including content driven campaigns, co-browse features and more.

You can get a flavour for Live Assist by watching this informative video.

You can register now onMEETUP.COMorCRMUG.COM

I have recently been working to integrate Live Assist from CafeX into my Unified Service Desk environment running on Microsoft Dynamics 365. You can see my demo video here.

If you have any requirements for live chat capabilities I really recommend you check this out. …..

This post is one of a series I am creating aimed at helping people prepare for the MB2-716 certification. (Microsoft Dynamics 365 Customization and Configuration)

In this post I am going to look at fields. A subject which hopefully follows on nicely from my last post about entities. As, after you have created an entity logically the next thing you’d want to do is create the fields which makeup the entity.

Fields Overview

Fields are sometimes described as attributes, the two terms are interchangeable.

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

As mentioned in my post on entities, we have system and custom entities. The system entities will comprise of many out of the box fields but we can add more custom fields as required. Although it is always a good idea to check a suitable system field doesn’t already exist before creating a custom one.

When a custom entity is first created some fields will get created by default. Including things like the primary field, created on, created by, owner and many more. I doubt you will need to know exactly what these fields are but even so it is worth creating a custom entity and before adding your own custom fields have a look. Below you can see that I have done just that. With a “basic” user / team owned entity I have 19 fields before I start adding any custom ones. Notice that only two are prefixed new_. I have used the default publisher which adds new_ to all custom fields. The two fields that are created are name (the primary field for this entity) and id. (Which holds the GUID which is the primary key.)

Field Types

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

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

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

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

Creating / Maintaining Fields

When we create a field the screen looks like this;

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

I have covered a lot of detail in these revision notes! Taking time to get some hands on experience of creating fields is really important.

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

I hope this post will have helped anyone preparing for the MB2-716 certification.

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at calculated fields.

In previous posts I’ve covered entities and fields. This post will build on that knowledge by looking at calculated fields.

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

The best way to learn about calculated fields might be to look at an example.

Say I have an entity which contains someone’s salary pretax and in another field I hold the tax amount. I might want to calculate their total salary after deducting tax. Below you can see that I have started off by creating a new field called “Salary (After Tax)”. The field has been set as a currency data type and the field type has been set as calculated. Notice that as soon as the field type is changed to calculated the field requirement option set becomes readonly. This is because calculated fields are not directly entered by the user and therefore have no requirement level.

Next notice that an “Edit” button has appeared next to the field type.

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

It might be important to know that once you click edit the field is actually created. And that the field type becomes read-only. Because the field type cannot be changed it is therefore not possible to convert simple fields to calculated. (If you wish to do this you’d need to create a new field!) However the formula behind the calculated fikedl can be changed at any point.

I can now use the edit option to define how the field should be calculated. Notice that calculated fields can have conditions but for now I have left these fields blank. I have simply entered the calculation I required. Which is salary – tax. Notice that as I enter my formula I get to pick the field / functions I require from a drop down.

After I accept my calculation not formatting changes to give a clear description of the calculation.

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

Once I have saved and published my change I can test it. See below that I have entered a salary of £50,000 and a tax amount of £5,000. The system has then calculated the post-tax salary of £45,000. (Don’t you wish tax values were really this low???)

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

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

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

Date Fields

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

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

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

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

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

String Calculations

Calculations are also possible with strings.

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

Including Fields from the Parent

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

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

On my Dynamics 365 form you can see the result below.

Note:
Changes to the details on the account record do mean this calculated field on the child entity are updated. Meaning this information will stay in step.

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

Hopefully this post has given you the information you need to understand calculated fields in preparation for your MB2-716 certification.

I am using Dynamic 365 Editable SubGrids on the form. However, I have to prevent user from editing some of the fields.

 Is there any out of the box configuration that allows to lock the field in Editable SubGrid like CreatedOn which is by default locked?

Thank You.

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at rollup fields.

In earlier posts I have looked at entities, fields and calculated fields. This post will continue that theme by reviewing the concepts connected with rollup fields.

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

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

Next on my account I create a new field that will hold the total policy value. Notice that I have set the field type to “Rollup”. Having saved the field I can then select the edit button to define the logic to rollup the policy value.

The details for rollup field looked like this.

Notice that I have selected my policies entity as the related entity. I then said I want a sum of policy value. (Other options available to me are count, max, min and average.) This is important to remember as roll up fields only work with numeric values. Whereas we saw that calculated values could also work with strings.

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

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

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

Tip:Also notice that you can  use the entity hierarchy when creating rollup fields. I explain this here.

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

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

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

Notice the fields were initially blank. But clicking the refresh icon forces a fresh and they changed to reflect the values shown below.

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

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

Rollup fields are calculated on demand like this using the refresh button.

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

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

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

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

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

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

Some considerations to be aware of are listed below;

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

I hope this post has fully explained roll up fields and covered all of the points you need to learn for the MB2-716 exam.


As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at alternate keys.

In this next section I will describe alternate keys and how they might be used. Before we consider alternate keys we need to understand the existing primary key on the Dynamics 365 entity.

Primary Field (Not a key)

You may have noticed that when you create a CRM entity a primary field is defined. All CRM entities have a primary field and it is often called “name”, although that is just the default setting and can be changed. The important thing to remember here is that the primary field is not a key field! It is simply a field that is mandatory on all records.

It is quite common to hold an account number or policy number in this field. But that still doesn’t make it a key field! As to be a key field implies uniqueness across the database. It is perfectly reasonable to have two accounts with the same name.

Primary Key

So if the primary field isn’t the primary key what is? The answer to this question is a field called GUID. All Dynamics 365 entities have a special field that is “hidden” on forms that is the id field for that entity. This id field holds the GUID value for the record.

Note:
GUID stands for Globally Unique Identified. It is a value held in the database for all records in CRM that uniquely identifies the record. The GUID unique not just within the entity but across the entire database.

As a user you don’t routinely see the GUID on a Dynamics 365 entity but as a developer its presence is very important.

One place you can see it is from an Excel export. Whenever we export data in a static worksheet there are some hidden columns. The first of which contains the GUID. Unhide column A and you can see the GUID. (In the case of an Excel export this is present to support being able to update the correct records should this data be altered and re-imported.)

You can also commonly see the GUIDs in the URLs used to access forms in Dynamics 365. Below I have shown the url used to open one of my account records. Notice that the GUID is highlighted in red.

Alternate Keys

Often just having the hidden primary key of the GUID will be enough and no further keys are required. Although if you wish to have a user readable key field or need to integrate into other systems using a predefined unique key the 36 character GUID is not a very “friendly” field. In these circumstances we might want to define one or more alternate keys. And those keys might comprise of one or more fields from the entity.

Let’s look at an example …..

I have used a custom entity of “Policy” as an example previously and I will stick with that theme in this one. Imagine on my entity I have a policy number and a code that represents the type of policy. The combination of these two fields might provide a unique key to identify the policy.

This might then be used on documentation to the customer or to integrate CRM with other systems. Such as a third party account package.

Below you can see I have added “Policy Number” and “Policy Type Code” to my policy entity.

I have already defined these fields a key with Dynamics 365. (We will look at how in a second.) It is important to understand that the system is going to enforce uniqueness on the combination of these two fields. So if I try to save a record with a type of CAR and policy number of 12345 a duplicate error will be shown.

Create Keys
When we customize the entity there is a section for keys. You can see this on my policy entity shown below. Plus you can see that I have added a key field called “Policy Key”.

Note: You can have up to 5 alternate keys per entity.

Tip:
Notice that the status is initially pending. The status changes to active once Dynamics 365 has been able to create any required unique indexes. This points to another benefit of alternate keys as their presence can improve record lookup times.

When I open the policy key you can see that I have selected “Policy Type Code” and “Policy Number” as the attributes to make up this key. (I maybe could have just selected policy number but I wanted to show that a key can be made up from multiple fields.)

Like the GUID, this key field doesn’t show on Dynamics 365 forms etc. But it does exist in background and can be used when integrating in with other systems.

Summary

• All Dynamics 365 records have a primary field; this is the name for the entity but isn’t the primary key.
• The primary key is a field known as the GUID. (Global Unique Identifier)
• The GUID is unique across the entire Dynamics 365 database.
• All entries in the Dynamics 365 database have a GUID. (Including meta data, so every entity, form, view, dashboard (etc. etc.) has a GUID.)
• Alternate keys can be defined using one or more Dynamics 365 fields.
• You can have maximum of 5 alternate keys per entity.
• Dynamics 365 enforce uniqueness on alternate keys and will give duplicate errors if any are created.

Hopefully this post has given you the details needed to understand keys for the MB2-716 exam.
