Recently I bumped into the below error while executing a custom plug-in in Microsoft Dynamics 365. This plug-in was using a NetworkCredential class to authenticate a SOAP request.

On scrutinizing the problem, it was realized that the error was thrown due to the plug-in being registered in the Sandbox environment of Dynamics 365. When registering the same plug-in outside the Sandbox environment, the error was prevailed.

So, if you happen to register the plug-in in the Sandbox instance, you wouldn’t be able to access IP addresses, registry, file system, system event logs and certain network protocols. However, Azure Cloud Services can be accessed by these Sandbox plug-ins.

The thing to be jotted down here is that the Sandbox instances exist for the security reasons. Microsoft Dynamics 365 online supports only sandboxed plugins and thus, be mindful of this restriction when developing systems or migrating CRM to online.

When utilising web services in Microsoft Dynamics 365, you may need to serialize some data to a JSON string. The most convenient way of doing this is to use a .NET library called System.Web, specifically System.Web.Script.Serialization. However, in a sandboxed plugin, access to the System.Web family of libraries is forbidden, throwing an error similar to:

“access security critical method 'System.Web.Script.Serialization.JavaScriptSerializer..ctor()' failed”

This makes serializing a class into JSON a touch more difficult. However, it is still possible to use built in .NET functionality to accomplish this.

This is accomplished by using a built in Runtime serialization class called ‘DataContractJsonSerializer’. This class serializes objects based on tags in the objects structure, and converts this data into JSON format. Thus, in the construction of the class, it is necessary to include these tags to inform the class which attributes to include. This is essentially forming a contract between the serializer and the target class for consumption, so that the serializer can consistently serialize and deserialize these objects.

The information can then be passed into the serializer to encode. In order to do this, you must initialise an instance of the DataContractJsonSerializer with the Type of the target class as a parameter:

 
In order to actually serialize the object, the serializer must write the object to a memory stream, which can then be read into a string object. The serialization can be performed as follows:

Once in JSON format, the object can then be converted back to the source object by writing the JSON object to a memory stream, then reading the object off the stream using the serializer.

If you are serializing/deserializing multiple different objects however, it may make sense to abstract this functionality and make it more generic, thus being able to be used for multiple different objects. These objects are still required to use the DataContract tags, so make sure you include those when constructing the objects!

Team Foundation Server (TFS) is a Microsoft product which provides source code management, project management, reporting, release management and testing. TFS has a lot of inbuilt reporting and dashboard services available. By connecting TFS to Microsoft Excel, we can use different functionalities of Excel to extend reporting capabilities and be more flexible with creating test execution reports. It is also excellent for users that are more comfortable and familiar with Excel.

The first step to this is setting up queries in TFS. Queries are the basic building blocks for managing work items. For testers generating custom test execution reports, we would be more concerned with TFS Bugs. Queries allow us to filter work items in TFS to be transported to Excel for data sorting, visualization, etc. It is also easier to update queries when work items also change. For example, a bug changes its state depending on the test lifecycle. This could mean that the bug gets removed from an Active Bugs query and gets added to a Closed Bugs query. Queries can simply be refreshed in TFS, which gets updated dynamically in our Excel spreadsheet when clicking the Refresh button under the TEAM tab.

How a user would log and label bugs (using TFS field Title) and group these bugs (using TFS fields e.g. Tag, State, Severity, Assigned To) would determine how bugs are sorted into different queries configured by the user. In this example below, I’ve grouped all my Active Bugs in TFS via the State.

The bugs that are logged for this subcomponent in a TFS Team Project must obviously contain these filter criteria to appear under the query. This is entirely up to how the user would set up the query. Below is an example on how I labelled the bug in TFS such that it meets the conditions of the example query. This is done by including a Tag called ‘CRM’ and prefixing the Work Item Title with ‘[Magnetism Sub Group]’.

You can be creative in what Work Item fields you are using to differentiate different queries. This added flexibility in TFS allows the user to further modularise different queries. Once I run the example query, this work item gets brought under the query results.

Once we can effectively separate and group each different bug accordingly in TFS, we need to establish a connection between the source TFS to the destination Excel spreadsheet. The TEAM tab in Excel allows us to connect TFS with Excel such that we can create a custom report in Excel.  This automatically shows up when Team Explorer or Visual Studio is installed. If it does not show up, the TEAM tab needs to be enabled using the following steps:

1. Go to File > Options to open Excel Options.
2. Navigate to the Customize Ribbon.
3. Click the TEAM checkbox. Click OK.
   

Once the TEAM tab is enabled in Excel, we can connect to a Team Project such that we can transport work item lists into Excel. Excel gives an option of creating two types of work item lists: query or input flat lists.

Using our earlier example query “Active Bugs – Magnetism Sub Group Changes – CRM” and its work item components, it gets transmitted to Excel once we choose the query list. This is shown below. Note that the Refresh button highlighted gets activated once we have connected through our query list and loaded our work components.

All done! Part 2 of this blog will cover how we can use Excel to pull in our data from TFS such that we can construct our test execution report and data visualisations.

So I’m sure that you’ve all come across a situation in Microsoft Dynamics 365 before where you’ve created a Multi-line text object on a form, given it lots of space, and then been annoyed when the edit box doesn’t use up the entire space. Once the text length has passed the limits of the allocated space, it scrolls. This can be quite an annoying aesthetic issue for Microsoft Dynamics 365 user. Be warned that approaches made in this blog are not supported.

It is possible however, to edit the styles of the text box, so that the field takes up as much room as it needs, with an optional hard limit. Doing this allows for more responsive form design, but is also unsupported in Microsoft Dynamics 365.
Doing so, however, allows you to have a situation like below.

However, it’s usually more sensible to impose a hard limit of how much the content is allowed to expand. (~400px usually looks quite nice).

The code for achieving this is very simple – a small piece of JavaScript.

 
This piece of code is run using the field name of an attribute in Dynamics 365, for example “mag_description”, which is the name of the field that this example is run on.

Setting the maxHeight value to a static value will keep standard Dynamics 365 behaviour, and allow you to scroll to view text that is past the max height. Using this functionality will also expand the edit box to match the height of the label (the text that is displayed when not selected).

There are lots of other CSS values that you can play around with, which sometimes produce rather interesting results. This one however, is probably one of the more useful that I’ve found.

In my previous blog, I’ve gone over setting up Team Foundation Server (TFS) such that we can use queries. TFS queries allow us to group and filter out work activities in TFS (primarily bugs). By setting up our queries to modularise our data and connecting TFS into Microsoft Excel, we can now extract our data such that we can construct our test execution report.

A good way to organize this is having the individual TFS queries in separate individual sheets within the same Excel file (for example, the TFS query shown above called “Active Bugs – Magnetism Sub Group Changes – CRM”). Then have a main report sheet used to store summary tables and charts (for example, Excel sheet shown below called “Test Execution Report Main Page”). This way, we can have a centralized location to summarize bugs in our project via tables and charts. A viewer who wants a brief overview of the test execution report can view this main report page. At the same time, having the separate individual sheets within the same Excel file offers the option of viewing the individual bugs under a query if needed.

The wonderful thing about Excel is that it gives you the capability to pull in data from different sheets in the same Excel file. For example, I used the COUNTA function to pull in the total number of Active Bugs from another sheet called ‘Active Bugs’ in my example spreadsheet.

The COUNTIF function is also used to count the total number of cells given a certain criterion. This can be useful for getting a count of different conditional types, e.g. bug severity types. I used the following COUNTIF cell notation to pull in the total number of Critical Bugs from sheet ‘All Bugs’. It counts all cells in the Severity column in the sheet ‘All Bugs’ given the condition cell contains the word ‘Critical’ (‘contains’ notation denoted by asterisk *).

 
The wonders of the TEAM connector in Excel is the minimal effort of updating the data once everything has been setup correctly. The user only needs to click the Refresh button on each sheet every time we would want to update our test execution report. The way the functions are built in Excel means that our data and total tables are updated automatically.

From here, the fun part begins! It’s all up to you to make use of the varied visualisation features Excel has to offer. Simply use the data tables we have used to draw in data from TFS to construct Excel-lent visuals! Visualisation charts and graphs of the test execution report gives the user a more effective, efficient and appealing way to present and summarize data.

Excel is a powerful tool to use for generating test execution reports and beyond. Once we are able to connect TFS with Excel with the correct intended queries from TFS, we are free to use Excel’s provided tools and functionalities. Excel provides us with tools to filter data via formulas, visual representation, and data analysis. Organized correctly, we can centralize our test execution data to provide viewers simplicity with summary tables and charts. Have fun configuring your reports!

Zapier is a service that allows for integrations and task automations across multiple web applications. In my previous blog posts, I went over setting up the Facebook Lead Ad Trigger and the Microsoft Dynamics 365 Action in your Zaps. This blog post will go over configuring the Birthdate field mappings in Zapier for the Microsoft Dynamics 365 Action step.

The most common fields that are retrieved in Facebook Lead Ad Forms are covered. These are: Full Name, Email, Phone Number and Birthdate. Email and Phone Number are simple with direct mapping, where we can just select them in our Zapier dropdown. Birthdate was a little tricky based on my experience configuring the mapping through trial and error. When I initially attempted direct value mapping of the Facebook ‘Date of Birth’ to ‘Birthdate’ in Dynamics 365, I got the following error:

The initial attempts to solving this problem is with the suspicion that the date being passed in CRM is in an incorrect format. Facebook passes the dates from Date of Birth in the format MM/DD/YYYY (using Zapier date format notation). What ended up working for me is testing the mapping by passing in the Created Time value from the Facebook Lead Ad into the Dynamics 365 Birthdate field. The values that are passed from Facebook need a Time and Time Offset value for UTC standard (screenshot below).

With this knowledge, we can simply use the Zapier Formatter to convert the value coming in Facebook Lead Date of Birth MM/DD/YYYY to the format YYYY-MM-DD.

Then, in the Microsoft Dynamics CRM Action, we can concatenate time and time zone values from our reformatted Date. In the CRM field Birthdate, we concatenate the ‘T’ notation (indicates time), the Time in HH:mm:SS format, and the ‘Z’ token (indicates time zone). The Z token in Zapier returns a time zone output. In this case, it will give the default output for the Z token, which is +0000.

Recently I’ve been working on a system where I’ve had to recreate a fair few entities, and have needed them to work with an existing code base. The issue I came across was that in the original versions of the entities, the status reasons on different entities had been made with inconsistent values. When remaking these, in order to have the reference in the code remain correct, I needed to remake the entities keeping the value of each of the status reasons the same. This was an issue, because in the web client it is not possible to manually edit the value of a status reason option.

My solution was to create the options in Dynamics 365 programmatically from a console app.

How can we achieve this?

As it turns out, it’s rather simple to create a status reason option programmatically. It simply requires executing a SDK message with the appropriate inputs. The basic code required is given below, but it’s a good idea to add some console output to ensure that the code is working as expected.

Using the above code in a console application can allow you to populate status reason options quickly, and allows greater flexibility than creating the values in Dynamics 365. In the below example, I add a status reason option to a custom ‘mag_event’ entity.

The above code creates a new status reason option called “Registrations Closed”, with a value of 12. This is just an arbitrary value, and can be set to any whole number. This is very useful when needing to recreate status reasons, or in the instance you accidentally delete a status reason, and you need to recreate it with the same value in Dynamics 365.

Using this approach with a console app, error handling is advised, as the code will throw an error if you attempt to create a status reason with a value that is already being used by something on the same entity (ie. Creating a status reason with a value of 1 while the default ‘Active’ status reason still exists).

When needing to update large amounts of records, you may find it easier to update these records in an external file with Excel, rather than edit them all individually in Dynamics 365. If you want to do this, here are some things to keep in mind.

Export Using Advanced Find

It’s a good idea to export your records using advanced find, with only the columns selected that you want to update in Dynamics 365. This allows you a greater degree of flexibility around which records you export due to Advanced Find’s filtering capabilities. It also helps to lessen the risk of something going wrong by only making available the columns you want to edit. This can happen with some auto-populated fields such as ‘createdon’ and ‘createdby’, which can throw validation errors when being imported back into Dynamics 365. This is due to the fact that these normally cannot be edited, and so when importing data containing these fields to update, Dynamics 365 will throw a mapping error.

Use the Original File

When wanting to reimport records back into Dynamics 365 to update existing records, it is important to update the records in the original file that you downloaded from Dynamics 365. This is because this file contains metadata that Dynamics 365 uses to identify the original records and fields that have not been updated, preventing Dynamics 365 from either creating duplicate records or updating fields that don’t need to be updated.

If you copy the data into another file, or export to another format (.csv, .txt etc.), Dynamics 365 will not recognise the entities as the same, and will create duplicates in the system. This may be caught by Duplication Detection rules, but will not update the existing entities.

Take Note of the Tooltips

When editing a selection of records in Excel, if you hover over a cell, you will get a tooltip which gives you information about the corresponding field in Dynamics 365, letting you know max field lengths, field types, and some other handy things to make sure you don’t put the wrong data type in the wrong box.

Import Using the Import Wizard

The import wizard can be found by navigating to Data Management, which is in the Settings tab, then selecting Imports. When there, click the Import Data button in the ribbon and select the data that you wish to import. As you haven’t made any format changes to the original document, you shouldn’t need to do any mapping, Dynamics 365 will handle this for you. Navigate through the wizard, and you should be good to go!

Microsoft Dynamics CRM 2016 on premise has an interesting issue where Two Options fields are automatically set to the default value, without a user updating them. The change appears in the Audit History and can occur when no plugins, workflows, JavaScript, or Business Rules are configured on an entity.

The example below shows the Audit History for an Email. There is a field called “Direction” which is a Two Options field with the values “Outgoing” and “Incoming”. A user tried to send an email from Dynamics CRM 2016 and noticed that the “Direction” had automatically been changed to “Incoming”. This meant that the email could not be sent.

Sometimes the Audit History would show that the “Direction” had changed from “Incoming” to “Incoming”, which left a lot of users scratching their heads.

We could reproduce the issue on demand by opening a record, and quickly navigating to one of the related records via the navigation bar at the top of the screen. The form would crash and get stuck on the “Loading” screen. In the background, data is submitted back to the Dynamics CRM 2016 database setting Two Options fields back to their default values. Turning on CRM tracing confirmed that an “update” command was executed in SQL.

How to fix this?

Microsoft released an update named “Microsoft Dynamics CRM 2016 Service Pack 1.1” which can be downloaded here. Microsoft stated they released a fix for: “When you switch between the main form and the related records in CRM, occasionally the Boolean fields (two options) are reset to the default value and will be submitted to the CRM database.”

In short, Microsoft is aware of this error and released a fix for all. Please refer to the Microsoft document and get this fixed so that all data is preserved.

The new Microsoft Dynamics 365 July 2017 Update introduces multiple features and UI enhancements, including the highly requested multi-select option set field. It provides the user a pick-list of options, with the ability to select multiple option set values which you could not do with an option set.

The field control itself already has a lot of interesting abilities. If you have a long list of values, and scrolling up and down is a hassle, the user can search for option values through text search on the field control. Adding and deleting pick-list option values for the field are also intuitive within a container for selected values, and the pick-list of option values.

Customisations for Multi-Select Option Set

This feature gives Dynamics 365 designers and customizers the ability to define selectable defined values (as such with an option set), but with the freedom of selecting and storing multiple values. By simply selecting ‘MultiSelect Option Set’ as the data type when defining your fields, the field will render on the form as a multi-select control.

Multi-Select Option Set for Views and Advanced Find

For views on the landing side, there are also custom controls for filtering multi-select option set fields. This is so that you can filter data on views on whether they contain specific option values. The filtering control looks similar to how the selectable field appears on the form, where it is a tick-untick pick-list control.

In Advanced Find, the multi-select option set field has custom operators for view filtering. Most notable of this is the ‘Contain Values’ operator which selects records which contain the values specified. This gives the option of a broad match to filter down records. Exact matches are of course available with the ‘Equals’ operator.

One thing to note about multi-select option sets in views and Advanced Find is that you cannot use the multi-select option set field for sorting. This would make sense considering the data type, and the potentially vast number of combinations the field could have in terms of selected option values. The order of appearance of the option set values on the field depends entirely on what order you select the values. The screenshot below shows how the field and field values for multi-select option sets would appear in a view in Advanced Find. The option ‘Milk’ was selected first by the user, and thus appears first in the field, followed by the option ‘Eggs’ and so on.

The screenshot below shows how the multi-select option set values would appear if you use the Export to Excel functionality for this view:

Can we use Global Option Sets for Multi-Select Option Set Fields?

Global option sets are a list of defined options which can be reused in any entity and in any option set type field.  This functionality would depend on how we define our field settings. To demonstrate this example, I’ve defined a multi-select option set called ‘Connection Category’ on the same Contact form, and selected ‘Use Existing Option Set’ = Yes. This will allow the use of global option sets for multi-select option set fields. I’ve then selected the out-of-the-box global option set ‘Category’ for the Connection entity. The screenshot below shows this field configuration, as well as the available option set values for the Category global option set.

There would be no difference in how the data is stored and presented when comparing local and global option sets for multi-select option set fields. Again, do note that the order of appearance of the option set values on the field depends entirely on what order you select the values.

Multi-Select Option Sets for Charts

When making charts for multi-select option sets, there are limited available aggregates when having the field in Legend Entries. It is not available as a Horizontal (Category) Axis Label.

It is not possible to drilldown charts for multi-select option set fields.

Afterthought

It will be interesting to see the possible ways developers can configure business requirements with what the multi-select option set can offer in the upcoming future. How the option set values can be selected and de-selected according to business logic, and how you can filter option set values accordingly can further increase the potential application of this feature. Important to also tie in with the new multi-select option set feature are the changes to the client-side APIs (notably Xrm.Page and Xrm.Utility) with the replacement client-side APIs. Developers will need to adjust accordingly to the new developer tools Microsoft has released for the July 2017 update, especially since client-side scripting is important with manipulating option set fields and option set values.

Multi-select option set fields is an exciting feature that Microsoft has introduced, and is one of the few exciting features in the Dynamics 365 July 2017 Update. I hope this blog gives you a helpful introduction to multi-select option set fields, its current functionality, and food-for-thought on its potential application in the future with building smarter CRM applications.

Zapier is a web-based service that allows end users to integrate multiple web applications. By establishing connections called Zaps, users can connect various applications, as well as automate various tasks across 750+ apps. It draws in comparison to Microsoft Flow – another workflow automation tool – both of which differ primarily on the triggers and actions that are available. This blog series will cover how to establish a simple connection from Facebook Lead Ads into Microsoft Dynamics 365 using Zapier, as well as tips including configuring the mappings for a working connection.

Currently, Zapier only offers new Facebook Leads as a Trigger for Facebook Lead Ads. The Microsoft Dynamics CRM Zapier app connection accepts Triggers when a new Account, Contact, Opportunity or Lead record gets created, and Actions to create a Contact, Account or a Lead CRM record. Zapier also has Search actions available to find an existing Contact or Lead in Microsoft Dynamics CRM. When creating a Zap for Facebook Lead Ads, the main Trigger for this blog will be when a Facebook Lead gets created, and the main Action of creating a Lead record into Microsoft Dynamics 365.

What are Facebook Lead Ad Forms?

Facebook Lead Ads allow lead generation through campaigns in Facebook and Instagram. It lets people show their interest in a product or service by filling out a form in the ad with their contact details, and allowing a business to follow up with them. The Facebook Lead Ad Form is the form that is shown when a user would click an ad from Facebook and send through their details. Facebook Lead Ad Forms allow for customization, offering many fields to add in your form.

Setting up the Facebook Lead Ads Trigger

After selecting a ‘New Lead’ as the Facebook Lead Ads Trigger, Zapier will need an established connection with the Facebook account. Once you are logged into this account through Zapier, the linked Facebook Pages and Lead Ad Forms will be loaded into the dropdowns automatically for selection.

The Trigger step then needs to be tested. Zapier uses a Facebook Lead to test the Trigger, and the values being passed in to be used by your other connections. When configuring your Zap, always check the values being passed in from the Facebook Lead Ads Trigger. This is to determine what values are being set, the value types, and in what format. This will be important when setting the field mappings in CRM.

Setting up the Microsoft Dynamics CRM Action

Once the Facebook Lead Ad Trigger has been tested and passed, we need to setup the Action of creating a Lead record in Microsoft Dynamics 365. When adding the Action and selecting ‘Create Lead’, Zapier will require a connected account. It will require the CRM domain as well as the CRM user credentials. Note the format of the CRM domain instance when clicking ‘Connect an Account’. Zapier will not accept the CRM connection when inputting the CRM domain instance that do not follow the format below.

When setting up the Action in Zapier, we can configure our mappings to take in dynamic and static values. Zapier populates the dropdown of any values that are available to use such that we can set the fields in the Lead record. In the screenshot above, when setting the value for the CRM field First Name, we have the Facebook Lead that we have setup earlier and the values it brings loaded into the field dropdown.

I’ve also added in a custom option set field in the CRM Lead entity called Enquiry Source. In Zapier, I’ve statically set its value to an option set value with the option set label ‘Facebook’. When the Zap gets triggered and a new Facebook Lead gets created, it will set the field accordingly. This can be very useful for reporting purposes, giving us the capability to view and filter Lead records in CRM that came from Facebook. The most obvious application to this is using Advanced Find, filtering using field Enquiry Source = Facebook.

What’s next?

Hopefully this blog post will give you a good introduction on Facebook Lead Ads and using Zapier to connect it with Microsoft Dynamics 365. Zapier provides a nice setup to make integrations between multiple web apps. This can be seamless provided you do the correct steps, as well as look out for some of the common problems that I’ve encountered when setting up the connection. The next part of this blog series will cover on finishing your setup, including tips to configure some of the field mappings, and testing your Zap with the Facebook Lead Ad Testing Tool.

Definition of an Editable Grid

An editable grid is data entry fields that are displayed in a view of a specified entity in Dynamics 365. This allows the user to efficiently input data into a field without having to go into the form, it is all done within a view. This is an extremely efficient and exciting new feature with Dynamics 365 and I strongly suggest to play around with this feature after reading this blog.

How to use Editable Grids

Editable grids are relatively straight forward once you know what they are. The first step is to enable editable grids on an entity in Dynamics 365. To do this go to (1) Settings -> (2) Customizations -> (3) Customize the System-> (4) Entities (Specify which Entity you would like to have the editable grid on) -> (5) Controls -> (6) Add Controls.

After clicking the “Add Control” button the below screen will appear where you can select the “Editable Grid” button. This enables the Editable grid on the current entity.

Now you can select which platforms (Web, Phone, Tablet) you would like the editable grid to be enabled on, in this example I am going to select all platforms but only demonstrate the editable grid on the web client.

Also you can click “Add Lookup” to further refine where the editable grid appears and configure it. In this example I’m going to have the editable grid on the “Accounts I Follow” view.

In the below image is the editable grid displayed on this view, the user can input data into the fields (unless locked) in a time efficient and easy to see manner. To edit other fields, one simply customizes the view to their desire. Simply click the field and enter the information. It’s easy.

Another amazing feature with this editable grid is the “Group by” function. This is shown below, it essentially groups elements by a certain column value. In the example it is grouped by “Primary Contact”. Where “---“is an undefined Primary Contact and “DOCTOR FROST” is the other group of primary contacts.

Limitations

One limitation with the editable grid is you can’t enter data into multiple records at a time (like bulk edit in excel). It would be a nice feature to be able to select multiple records or group fields and edit the data fields by grouping. To get around this limitation the bulk edit function can be used, although this is okay it would be nice to be able to bulk edit inline.

Another limitation is that some fields are locked e.g. the “Email (Primary Contact”) field, the reason for this is that these fields belong to a related entity and are unable to be edited from the editable grid.

In certain situations, you may want to check if a user has a security role before proceeding with logic for Dynamics 365. This may be because you only want to have users with certain security roles perform these actions, or want to change the logic of the plugin slightly depending on the security roles associated with the user. In any case, the method for finding these associations is fairly simple.

Querying the Relationship

There exists an N:N relationship between Users and Security Roles in Dynamics 365. This relationship can be queried to determine if a given user is linked to a given security role.

The intersect entity is a system entity called “systemuserroles”. This intersect entity is extremely simple, and only contains three attributes: “roleid”, “systemuserid”, and “systemuserrolesid”.

These respectively are the ids for the Security Role, the User, and the Intersect entity. If you know the Guid of the role, and the Guid of the user, then you can use a simple QueryExpression to determine if there exists a relationship between the user and this role. The expression for this looks like the following:

 
However, if you don’t know the Guid of the user or the Guid of the role, this gets slightly more complex. This however, is actually a more common scenario, as Guids will change when deploying to other Dynamics 365 systems.

Obtain the Guid of the User

You can obtain the id of the user that started the plugin via the context, which has an attribute called ‘InitiatingUserId’.

If you’re simply checking the security roles of the user who executed the plugin, this will do. If not, just use a QueryExpression to obtain the Id of the user that you want.

Link the Security Role to the Intersect

If you don’t have the Guid of the Security role, it is easiest to obtain within the original QueryExpression. This is because it is possible to link the Security Role entity to the intersect, and then add a condition to the criteria for the Security Role entity. This is done through the use of LinkEntities. If you need to brush up on those, an example can be found here: https://msdn.microsoft.com/en-us/library/microsoft.xrm.sdk.query.linkentity.aspx

When linked, the code looks like the following:

This allows the user to query the system for the relevant records, given that they know the Id of the user (which can be obtained from the execution context, via a QueryExpresson, or any other viable method) and the name of the role that they want to check for. Users could even be treated like Security roles, and linked to the systemuserroles and searched for via name. This code checks to see that there is at least one Security Role with the specified name associated with this user. This is a handy check when a deployment has multiple business units, as top level security roles are duplicated in each child business unit. This means that if you check for a particular Guid, you may not get a match if you have the Guid for the right security role from the wrong business unit. In this manner, the link entity is more reliable than searching for the Guid of a Security role using a query expression, then using that Guid in the subsequent search for the relationship.

When deploying customisations from a development environment to a testing environment in Microsoft Dynamics CRM 2016, I encountered an issue with imported views in my solution components. The view was on the Connections entity for a custom entity called Portal User. This custom entity is just something which other entities can connect to. The view for the Connections entity contains the filter field “Type (To) Equals Portal User”. Type (To) is an out-of-the-box option set field on a Connection record that states what the entity type of the ‘Connected To’ record is.

 
The error indicates that the option list value no longer exists in the imported test system. Checking the FetchXML for this custom view in the test environment indicates that the condition value does not contain anything.

I’ve inspected the working custom view in the development environment. The ‘Equals’ condition with the Type (To) option set field requires a specific option set value to filter the records.

I’ve made a quick test on choosing the same filter conditions on a new blank Advanced Find view in the Connections entity (this is in the test environment where my imported custom view failed). Inspecting the FetchXML below, it appears that the option set value of Portal User for the environment is different to what I was expecting from the custom view.

This error could be a nuisance especially when a lot of customization components depend on this custom view e.g. sub-grids, dashboards. This error can either happen where option value does not exist in the system being imported to or the wrong option set record gets inputted (e.g. CRM has already assigned a different entity to that option set value). This can commonly occur during imports to different environments or in data migrations where entity GUIDs are maintained or changed throughout the different environments.

It all depends on how each environment is set up. In our case, the test environment setup has the Portal User option set with a different option set value compared to the development environment. Since the ‘Equals’ condition requires option set values to match, it would trigger an error into the custom view as the condition with the given option set value does not exist.

You can obviously manually change the custom view filter every time in the new environment. But it would be a hassle as it would need to be redone every time we deploy the solution. This could also mean inconsistencies between two different environments which we do not want.

A work around to this could be changing the filter attribute to ‘Contains’ or ‘Begins With’. This way we can avoid this issue with imported views into different environments regardless of what option set values are set in the different environments. Here is an example of using ‘Begins With’ in the custom view. The custom view filter now looks for a string in the option set display name as opposed to an exact matching option set value.

Microsoft Dynamics 365 comes with a feature called “Pen Control”, which allows the users to directly draw and add a signature using the Microsoft Dynamics 365 Mobile App. It is a control that can be added to a “Multiple Lines of Text” field. In this blog, I will walk through the steps to setup this feature, followed by a demonstration.

I will create a custom field called “Signature” for Contact, and it will be added on Quick Create and Main forms. The data type must be “Multiple Lines of Text” and recommended size for “Maximum Length” is 15,000.

Once the field has been created and the changes have been saved, it is ready to be added on the forms.

After the field has been added on a form, double click on it to edit field properties. In field properties click on “Control” followed by “Add Control”.

Then add “Pen Control”. Notice that recommended max length of the field size is 15000.

Be sure to enable the control for phones and/or tablets. Also, it cannot be enabled for Web. Then click on OK.

Then save the form, and publish all changes.

Let’s see “Signature” field in action. I logged into Dynamics 365 App on my Android phone. I opened an existing contact. To draw my signature, I must tap on “Signature” field.

I can also clear any input. However, once it has been submitted, the user can neither clear it nor change it.

Pen Control is a useful feature to input a signature, however, there are some concerns about it. Such as, the user has the option to draw only in Mobile clients, not web client. Also, the user’s input is not displayed in web client in its original state, instead some text is displayed. The field can be edited in web client, and user can modify the stored values by mistake.

However, there is a work around this. In my second part of this blog series, I will go through the steps to display the signature on web client.

Zapier is a service that allows for integrations and task automations across multiple web applications. In my previous blog posts, I went over setting up the Facebook Lead Ad Trigger and the Microsoft Dynamics 365 Action in your Zaps as well as some of the common errors to watch out for. This blog post will go over configuring the Full Name field mappings in Zapier for the Microsoft Dynamics 365 Action step.

The most common fields that are retrieved in Facebook Lead Ad Forms are covered. These are: Full Name, Email, Phone Number and Birthdate. Email and Phone Number are simple with direct mapping, where we can just select them in our Zapier dropdown (screenshot below).

The out-of-the-box Lead entity has a Full Name composite field containing the text fields First Name and Last Name. When Zapier retrieves the custom fields from CRM it will retrieve First Name and Last Name, and requires a value to be mapped because the field is set to Business Required. There are two solutions to tackling this problem. The first option is splitting Full Name when customizing your Facebook Lead Ad Form from taking Full Name, and changing it to take in First Name and Last Name. Facebook Lead Ad Forms allow for customization, so you can untick ‘Full name’, and tick ‘First name’ and ‘Last name’.

Note that the best practice is keeping the Lead Ad Form short and simple. The trade-off of obtaining more information from a user is the chance that a user will abandon the form before completing it. Thus, you would need to consider users having additional user actions on the form. Splitting the field Full Name into First Name and Last Name means there are more field controls in the Lead Ad Form.

The second option for mapping Full Name is by using Formatter, a built-in tool that allows for Triggers and Actions in order to reformat data used in your Zaps. You can convert data into different formats before adding it into the Actions steps. For this option, we can use the Formatter to split the Full Name, using the space as our separator (default value). We can then pass the output of this Formatter into our ‘Create Lead’ Action, mapping the field values into Microsoft Dynamics 365. This method allows you to maintain having Full Name in your Facebook Lead Form. The screenshot below is the Formatter configuration I made to split the First Name from the Full Name in the Facebook Lead Ad.

One of the suite of the Relationship Insights is a Relationship Assistant which keeps you updated with the upcoming activity or the task in Microsoft Dynamics 365. It continuously analyses your customer’s communication data in Dynamics 365 and from the Microsoft Exchange. It additionally provides reminders when there is any lack of activity between you and your customers. Consequently, it helps you to improve relationship with your customers.

It displays action cards to remind yourself of the task that need to be completed such as follow up on a task or an email, attend meeting etc. These cards are generated based on your actions taken in Dynamics 365 by analysing your past activities with the customer. Action cards are only available for Dynamics 365 online.

A typical action card consists of a description that shows your records that are inactive for some time. Only the records of the contact, opportunity, lead, account, and case that you own are displayed. It displays the feature that categorizes the type and name of the record and explains why the card was generated. For example, ‘No recent activity with ‘Customer A’. It also has actions to open the record or to create an activity for the record directly from the action card, without you having to navigate to the record.

You can configure the action cards for the activities that you intent to see by following the below steps:

• Click onto the Settings button from the top right side of the navigation bar, and then choose Options from the drop-down list.
• Scroll to the bottom of the General tab, and then click on Manage personal relationship assistant settings link as shown in the below screenshot.

The Relationship Assistant settings window will be opened, showing you a list of action cards that your administrator has made available to you. Note, that the value for the “Days before notifying me when the close.”(as shown in the below image) is read only and can only be set by your administrator.

So, the action cards can be tailored to meet your requirements and can be customized for each user role which ultimately helps you to improve and nurture your business.

Microsoft Dynamics 365 comes with a range of new functionalities that focuses on mobility. One of those functionalities is the “Barcode Scanner” control for form fields. It allows the users to scan a barcode and then store the values in a “Single Line of Text” field using their phones and tablets. In this blog, I will walk through the steps to setup this functionality in Microsoft Dynamics 365 followed by a demonstration.

I will be creating a custom field called “Barcode” for Product entity. The data type will be “Single Line of Text”.

Once the field has been created, it is ready to be added on the forms. I added “Barcode” field on Product main form.

To modify “Barcode” field properties, double click on it. In the field properties, select “Controls” tab and then click on “Add Control”. Then select and add “Barcode Scanner” control.

 
Once the control has been added, enable it for phone and/or tablet. Note, “Barcode Scanner” cannot be enabled for web client. Once the changes have been made, save the field properties. Save all the changes and be sure to publish the solution.

Let’s see “Barcode Scanner” in action. I accessed my modified instance using Dynamics 365 App for Android smartphone. Once logged in, I opened a Product record.

Notice, a new icon appears in “Barcode” field. By clicking on that icon, I can scan the barcode label of the products.

Once the barcode was scanned successfully, its corresponding values were stored in “Barcode” field.

I am also able to view the values stored in “Barcode” field using web client. Even though we do not have to ability to scan the barcode label on web client, we are still able to enter the values manually.

The “Microsoft Dynamics 365 App for Outlook” is a lightweight alternative to the “Dynamics 365/CRM for Outlook Client”. This app does not require a separate installation like the Outlook Client, but can instead be added from your Dynamics 365 environment.

The screenshot above can be reached via ‘Apps for Dynamics 365’ from the cog in the navigation bar. If you can see the above message then the app has already been added to your Outlook, otherwise you would need to add it yourself. By navigating to ‘Dynamics 365 App for Outlook’ area under Settings you will be able to see the screen below. This shows all Users who are currently configured to use the Outlook App, along with the option to manually add the App for these Users.

To be eligible:

• Users must have Server Side Synchronization set up.
• Users must have Outlook 2013 or later installed.
• Users need the “Use Dynamics 365 App for Outlook” privilege under the ‘Privacy Related Privileges’ area.
• CRM Environment must be Online.
• Exchange Server must be 2013 or later.

Once you have clicked the button to add eligible Users, the Status will change to Pending. After about 15 minutes the app should be added to Outlook, with a status of ‘Added to Outlook’ being shown in CRM.

As this app is a lightweight version of the existing Outlook Client there are a few functionality differences. Things in the app that are not available at the time of writing this blog are the ability to work offline, to add email templates from CRM, to sort, filter, format, group and categorize lists, to create word mail-merge docs and to control field synch. The screenshot below shows the ‘Dynamics 365’ button added to the ‘Home’ tab, as opposed to having an entire tab for Dynamics 365 functionality.

When you click the Dynamics 365 button, a panel on the right side of the screen pops out and gives you the option to track the email you are currently on.

Once you have decided to track the email, you are given the option to Set Regarding for the email you want to track, along with the options to create an Account, Contact, Lead or Opportunity from Outlook. You also have the option to create and add Tasks, Appointments and Phone Calls for the set ‘Regarding’ record.

While writing this blog the ability to track appointments was available with the same ‘Dynamics 365’ button. This functionality only allowed Users to track appointments they had created themselves. If an appointment was organized by another User it cannot be tracked this way.

The Dynamics 365 app for Outlook is not only limited to the Outlook desktop client. When a User has activated the app, they are also able to track emails using the Outlook web client as shown in the screenshot below. A small ‘Dynamics 365’ button is added which provides the same tracking functionality as the Outlook desktop client. The app is also available for Outlook on mobile phones and Mac.

In Microsoft Dynamics 365, we have the ability to add custom buttons in a command bar. Most of the time we also make those buttons available on Dynamics 365 Mobile clients. However, the mobile client has some limitations and not all functionalities are available that are on web client. Therefore, sometimes it is best idea to make the custom button not available on mobile client.

We can accomplish this with the help of Ribbon Workbench. It can be downloaded from www.develop1.net and then added as a solution in Dynamics 365 instance. I added a custom button called “Disqualify” on Contact forms, this button is available on web and mobile clients. In this blog, I will walk through the steps to hide “Disqualify” button on mobile clients.

1. In your solution, add JavaScript code as a web resource. I have added mag_/js/hidebutton.js and following is the code that I used.

2. Open Ribbon Workbench.
3. Select the solution that contains mag_/js/hidebutton.js .

4. Once the Solution has been downloaded, select “Contact” entity in solution elements.

5. Click on icon next to “Enable Rules”, and then click on “Add Step”. Select “Custom Rule”. Set the field values as shown in screenshot below.
6. Be sure to publish once the changes have been made.

7. Let’s see the changes in action. I opened the same contact record on both web and mobile clients. Unlike earlier, this time “Disqualify” button no longer appears on    Mobile client, but still does Web client.