Dynamic Communities Magazine

This article introduces three very useful plugins that system customizers can use to address several common problems.

Originally published in H2 2018 D365UG/CRMUG Magazine

The XrmToolBox comes with tons of extremely useful plugins right out of the box, but with the addition of the Plugin Store, the number of “third-party” plugins has skyrocketed. In this article I hope to focus on three very useful plugins for system customizers (those that are responsible for defining attributes/relationships/views etc.) that must be downloaded from the store since they do not come by default in the base XrmToolBox install.

Attribute Manager
The Attribute Manager, developed by me, has its roots in a plugin that was created back in 2012 for converting entity specific option set attributes into global option set attributes. It was later expanded to handle converting most any attribute to another attribute. Confused by what this means? Let’s walk through a couple example problems:

Problem 1: Fixing the Dreaded “new_” prefix.
Microsoft Dynamics 365 will by default prefix the schema name of these attributes with “new_” rather than (assuming hypothetical company Xyz) “xyz_”. And since this is the database backing field, it can’t be updated. Have you ever asked someone to create a new attribute for an entity, and they created it with the “new_” prefix? And then to compound the problem they’ve added dependencies on it by adding it to three forms, 10 views, two workflows, four business rules, and a plugin registration step filter?

Problem 2: Requiring a “Yes/No” Option Set
I’ve seen this issue pop up on countless projects. A customizer creates an “Are You Married?” attribute with two values, “Yes” and “No”, but with two value option sets, there is no way to require it on a form. It either has a default value of “Yes” or a default value of “No”, but there is no “Not Selected” option, and unfortunately, Dynamics 365 does not allow for changing a two-value option set to a normal option set with more than two values.

Problem 3: Satisfying OCD Tendencies
There is a fine line between just being OCD and being a master Dynamics 365 craftsperson. Every Dynamics 365 implementation has attributes that are perhaps named incorrectly or maybe even spelled wrong. Sometimes there are regrets that an entity specific option set wasn’t a global option set, or that decimal really should have been an integer or money, etc.

To fix any of these problems, the attribute itself must be deleted (since the system does not allow these properties to be updated), and a new attribute with the desired properties must be created in its place. To delete the attribute, all system dependencies would have to be removed. Not only does this include removing it from all forms, views, workflows, business rules, plugin registration step filters and images, and so on, but it also requires that the new attribute be re-added to these dependencies, exactly as it was before. This work is extremely time-consuming and extremely error-prone, but this is exactly what the Attribute Manager does, allowing attribute problems to be fixed that are normally too costly to be fixed.

Let’s walk through solving the first two problems since the second is just a specific instance of the third, but where there is a business reason for the change, not just OCD tendencies:

Problem 1: Fixing the Dreaded “new_” prefix.

1. Select the entity the attribute is on
2. Select the attribute to be renamed
3. Optional – Choose to optionally migrate the data to the new attribute
4. Optional – Provide a CSV mapping file if the migration of data should be mapped; since this is just a name change, this shouldn’t be required
5. Rename the attribute
6. The steps in 6 to the right will automatically be updated to reflect the required changes; you can choose to implement one at a time and test after each step, or leave them all checked and run in succession
7. Click the “Execute Steps” button and the checked steps in 6 will be executed
8. The steps that are being performed and the results will be outputted in the log

Problem 2: Requiring a “Yes/No” Option Set

1. Once again, select the entity
2. Then the attribute
3. Now check “Convert Attribute Type”
4. Since the name hasn’t changed, the steps now include a temporary attribute that everything is migrated to and then back again
5. Select the “Attribute Type” as an already existing “Global Option Set”
6. Select the “Option Set”
7. Click “Execute Steps” to convert the two option set to a requirable “normal” option set

Limitations
Like a scalpel, the Attribute Manager is a tool that can do incredible good as well as damage. Keep these limitations in mind:

• It can’t update/delete managed attributes.
• It works best in Dev. If something is wrong in Prod and in a(n):
        • Unmanaged Solution – The steps will need to be run in each environment before solutions that reference the change can be imported since Dynamics 365 isn’t prepared to handle an attribute’s type being different than expected.
        • Managed Solution – A managed solution will need to be made at each step where an attribute is added or removed, and then all the solutions will need to be propagated, and the migration done with the tool or manually at each step.
• Not all attribute types/settings are supported. Like most plugins in the XTB, it is a work in progress, so submit bugs and feature requests to its GitHub via the XTB’s Help menu.

FetchXml/View Record Counter
When working in Dynamics CRM Online environments, it can be surprisingly difficult to determine how many records of a particular entity exist if it is more than 5,000 since views and advanced finds will just display “1-250 of 5000+”. You could export it in Excel which can be a semi-lengthy process, but even then, you are limited to 100,000. But what if you are performing some action against all records, and you need to estimate how long it will take (say using the Attribute Manager and migrating the data for an attribute), and if there are 60,000 records it’s okay, but if there are 600,000 records, then the task can’t be completed in the allowed time frame? This is what the FetchXml/View Record Counter, developed by Baris Kanlica, was created for.

The Record Counter takes FetchXml (it defaults to giving you views, but you can always copy in the FetchXml by hand that’s been created via Advanced Find, or with the FetchXml Builder) and queries all records using the given criteria, in the fastest and most efficient methodology allowed by the Dynamics 365 API, returning the total count. It’s a very simple tool that provides very important information.

Let’s walk through the steps to get a count of all Accounts:

1. Click “Load Entities”
2. Select the entity to count
3. Select the view to use
4. Update or edit the Xml if needed (removing all attributes all but the id attribute and any outer joined linked entities is probably a good idea)
5. Click “Execute Count”
6. Wait to get the total count.

And that’s it! Hard to go wrong.

Bulk Data Updater
Within the course of most CRM projects, there comes a time when a new attribute needs to be added, but there are multiple possible default values that should be set, depending upon related data in the system. A very simple and direct manner for defining what these values should be is to create a workflow to set the value for a record, but unfortunately it is extremely time-consuming to trigger this workflow on more than 10,000 records, and creating a workflow can be time-consuming as well. Here is where the Bulk Data Updater, developed by Jonas Rapp, comes in incredibly handy.

The Bulk Data Updater allows you to update multiple attributes to a particular value for a particular set of entities. You can use views, hand entered/copied fetch Xml, the Fetch Xml Builder (if you have the plugin installed), or even a file with fetch Xml, to define what records need to be updated. Then you can configure what attributes to be updated, cleared, or touched (the value will be set to its current value, so it’s not changed, but will trigger plugins and workflows to run) and update the desired records. Bring on the visual!

1. Select the methodology to be used to determine what records to update
2. Click “Get records” to get a preview of what records will be affected
3. Add whatever attributes to be updated by selecting them one by one in the attribute drop-down
4. Select what should be done to the value; you can select a specific value or clear the value, or, for it to be set to its current value meaning, it won’t be changed, but any associated workflows/plugins will be triggered
5. Click “Add attribute”
6. Which is then added to the grid
7. Finally click “Update records” and watch as all the filtered entities’ attributes are updated accordingly.