How to Use Dependent Lookups for Dynamics CRM 2013/2015/2016 Like a Pro

Have you been looking for a way to filter the available options in one lookup field based upon the value of another lookup field? This can be done easily in Microsoft Dynamics CRM 2013, 2015 and 2016 without any custom code, and in today's blog, we will show you how! Let's begin!

Let's walk through the necessary steps using two fields to classify your Accounts as an example. We'll use Class and Sub-Class as the fields. For this example, we've created a new entity for each of these fields.

The Sub-Class entity contains the name of the Sub-Class as well as a lookup to the "parent" Class record. This relationship will allow us to filter the list of available Sub-Classes based on the selected Class.

The Class entity has only a single field to store the name of the Class. We've added a sub-grid to display only the list of Sub-Classes that are valid for this Class.

For the example below of Retail, once we add these fields to the Account form and modify the properties of the Sub-Class field, the user will only be able to choose one of the Available Sub-Classes listed, when Retail is selected as the Class on the Account form.

Now that we have the entities and some sample data in place, we'll need to create these new fields on the Account entity and add them to the Account form.

This is how the new lookups look on the CRM form:

Next, we'll configure the Sub-Class field properties so that only the Available Sub-Classes are options.

Note: Be sure to publish your customizations once you are finished.

You should now see the desired behavior on the Account record. If you populate a value for Class, you'll notice how only the Available Sub-Classes can be be selected as an option.

This is technically all that needs to be done, however, you should also put a Business Rule in place to prevent a user from selecting a Sub-Class unless the Class field is populated.

In the Account entity, navigate to Customize the System, select Business Rules, and then click New.

The Business Rule below will meet this need.

In the red box below, we are saying that if the Class is blank, we lock the Sub-Class field. This will make it Read Only.

In addition, we need to clear the Sub-Class field. We do this to ensure that a user cannot change the value of the Class and leave an invalid Sub-Class populated.

In the blue box, we are saying that if Class is populated, we unlock the field so the user is able to populate it.

That's all for the blog today! Want to learn more about Dynamics CRM 2016? Register for our CRM 2016 Boot Camp in Minneapolis, MN.

Happy CRM'ing!

Don’t Delete Your Configuration Data! Use Real-time Workflows Instead

Picture this scenario. After weighing the pros and cons between filtered lookups vs. dependent option sets for States/Provinces and Country entities, your organization decides to go with filtered lookups. You've entered in your configuration data for both State/Province and Country entities and used the Configuration Migration Tool to make the data (and their GUIDs) match between your environments. Great!

Real-time Workflows

But, as a CRM System Administrator, you still have the ability to delete that configuration data, which breaks all of the workflows, business rules, views, dashboards, and other items that depend on that data. Yikes!

Real-time Workflows

Fortunately, there is a quick out-of-the-box way to help stop yourself from accidentally making life harder while maintaining the ability to delete when you truly need to do so, and in today's blog, we will show you how! Let's begin!

1. First, create a real-time workflow that is triggered ONLY before delete.
Real-time Workflows

2. In the workflow designer, click Add Step and then select Stop Workflow.

3. In the stop workflow clause, change the status to Canceled and then click Set Properties.
Real-time Workflows

4. In the window that opens, you can write yourself a note, including steps on how to actually delete the data when it's got to go.

5. Save, Activate, then test it out!

Bonus: If you have cascading delete on a Parent entity, this workflow will stop both the Parent and the Child entities' records from being deleted!
Real-time Workflows

That's it! You've now stopped the deletion of configuration data and have prevented yourself from having to "start over" with your GUID-reliant configurations. That's a win in our book!

That's all for the blog today! Got a little more time for CRM? Go ahead and check out our entire library of Webinars on Demand. It's CRM anywhere, anytime!

Happy CRM'ing!