Killer app for dialogs – Extend customer addresses in Microsoft Dynamics CRM without code

By - December 19, 2014

The address (AKA customer address) entity is an important entity in Microsoft Dynamics CRM.  However, one major frustration is that you cannot extend the entity by creating a lookup to it.  In fact, you cannot create any new type of relationship to the address entity.  If you try to create an N to 1 from another entity back to the address, you’ll find it does not exist in your option set of entities to choose.

One way to get around this is by creating a Look Up Address feature, similar to what is provided on the Order entity in Dynamics CRM.  As an example, we’ve used this extension, Looking up Address field on Custom Entity in CRM 2011, by calling the lookup address dialog box, utilizes an Odata/REST call and then stuffs the values into custom address fields on the opportunity entity.

Killer App for Dialog 1

Killer App for Dialog 2

 

There are a few issues/limitations with this approach:

  • For orders, you do not have access to any additional fields from the address entity, other than what is being passed already.
  • Even if you use this extension, you can only perform the lookup to one account’s addresses. In the example I’m going to present, we are going to lookup addresses for the customer and another account (the reseller) lookup on the opportunity.
  • The solution requires javascript code, including an oData/REST call to the address entity.
  • Calling the Look Up Address dialog from javascript code may not be a supported customization. I’ve looked for guidance here and it’s unclear.

Use a dialog instead

For this solution, we’re going to leverage dialogs.  Dialogs were one of those great features that came with Dynamics CRM 2011 that I was sure we would utilize heavily in our CRM implementations.  How has that worked out?  Well, I’ve built more dialogs for Demos and Proof of Concepts than I have for production implementations.   The solution I’m presenting here is a “killer app” for dialogs, extending the customer address functionality.

User Experience

Before I go into the details of how this is built, I’ll first present the user experience.  The requirement here is that the addresses can be from either the potential customer or the reseller of the opportunity, for the bill to and ship to addresses.

While in an opportunity, the user clicks on the command bar (ellipses) and selects “Start Dialog”>>selects the dialog (in this case, Opportunity – Select Addresses)>>clicks Add.

The first dialog page that the user is presented with has a question with 3 valid answers (note: ship to customer, bill to reseller is not a valid option in our case):

  • Bill to and ship to addresses are both from potential customer
  • Bill to address from reseller, ship to from potential customer
  • Bill to address from reseller, ship to from reseller.

Killer App for Dialog 3

Click Next. The user is then presented with two option sets, one for the bill to address and one for the ship to address. The drop downs are looking up the values depending on what the user selected on the first screen.

Killer App for Dialog 4

So, that’s it, the user has 3 questions to answer on 2 screens.  Once the user clicks Next, depending on what options they selected for the addresses, all of the address fields are copied over to the opportunity, including any custom fields that were created on the address.  As an example of a custom address field, many folks use an option set or a lookup for the state/province or country fields.  Now, let’s create the dialog.

Creating the Dialog

Settings>>Processeses>>New>>Enter Process name>>Select Dialog as Category>>Select Opportunity as Entity (or whatever entity you want to extend)>>Click OK.

Dialog Overview

Before we continue, let’s take a look at the workflow in its entirety and what the workflow should resemble, when complete.

Killer App for Dialog 5

Killer App for Dialog 6

In Summary, the dialog has the following components:

  • Two queries, one to look for the addresses based on licensed account and one to look for addresses based on the reseller of the opportunity
  • One Page, with a prompt and response to capture which addresses will be used for this opportunity (licensed account versus reseller).
  • Three conditional branches that will display a different page depending on which of the 3 valid options were selected on the first page.
  • Two prompt and Responses (one for bill to and one for ship to) for each of the 3 conditional branches
  • One update Record (Opportunity) Step for each of the three conditional branches.

Dialog Detailed Steps

The first thing we do is add two queries.  One query will be used when a user selects an address from the potential customer and the other query will be used when a user selects an address from the reseller.

Click Add Step>>Query CRM Data>>Enter a Statement Label>>Click Edit Columns and add all the columns you want displayed in the option set or want set on the target entity>>Enter a filter by looking in the related records and choosing, in this case, the Parent (Account) entity and go ahead and select a specific account for your criteria.  Next, we’ll show how to make this value dynamic.

Killer App for Dialog 7

Now, click on the “Modify Query Variables” tab in the Define Query dialog.  Note that Variable1 is currently set to be the specific guid for the account you selected in the previous step.  Delete that Guid.

Killer App for Dialog 8

On the right in the form assistant, leave the “look for” to be Opportunity and select the specific field you want this query to be based on.  In this case, we’re using “licensed account”>>Click Add>>Click OK.  Your screen should now look similar to the below:

Killer App for Dialog 9

Click Save and Close

Note:  It’s very easy to go back in and extend the queries to include additional fields from the address entity, just remember to re-add the dynamic value for Variable1 on the “Modify Query Variables” tab.

Now we’re ready to create our pages for the dialog.

The first page we want to create is the one that asks the user which account (the licensed account or reseller) they want to use for the bill to and ship to addresses they will be selecting.  Based on the response, we will display 1 of 3 pages that corresponds to this initial user selection.

Click Add Step>>Page>>Name your step>>Click Add Step>>Prompt and Response>>Name your step>>Click Set Properties>>Complete the form as below:

Prompt Text:  Opportunity Address Options

Response Type:  Option Set (picklist)

Provide Values:  Define Values

Response Values:  0,1,2, respectively.  (0=both the bill to and ship to come from licensed account, 1=bill to from the reseller, ship to from licensed account, 2 = bill to and ship to from the reseller)

Save and Close.

As you might expect, once the user makes their selection and clicks next, we can query this value in subsequent steps.  So the next step to add is a check condition, with multiple (3 in all) conditional branches.

Add Step>>Check Condition>>On field list, go down until you see the name of the prior Page, “Address Options”>>Select “Equals”>>Type in the value 0.

Killer App for Dialog 11

Click Save and Close

We chose the value of 0 (rather than the label) so the label can change without needing to change the conditional steps.

Now, under this condition, we want to add a page that allows the user to select the appropriate addresses based on their selection of the first option, which is that both addresses will be from the licensed account, rather than the reseller.  So, we’ll have one page with 2 prompt and responses (one for the bill to selection and one for the ship to selection).

Add Step>>Page>>Name the page, in this case, “licensed account address options”.

Add Step>>Prompt and Response>>Name: “Licensed Account Bill To Address Option”>>Click Set Properties>>Fill out the screen as below

Provide Values: Query CRM data (this will allow us to choose any queries we’ve established)

Query Variables:  Query Licensed Account Addresses.  We will be choosing this option for both the bill to and ship to address, since in this case, the user selected the first option (0), which stated that both addresses would come from the Licensed Account (rather than the reseller).

Separator: “ | “.  Without the double quotes, this is a {space} {bar} {space} to act as a separator for each field value that the user will see.

Columns:   Choose all the fields you want to display to the user.  Note:  All the address fields from the query will be available, based on the user selection, regardless of whether you choose to display the fields to them.

Click Save and Close.

Repeat the exact same process, with the same options for the ship to address, as below:

For the ship to, we chose the Query Variable, “Query Licensed Account Addresses” because, again, the user will have selected the very first option (0), which stated that both the bill to and ship to addresses would come from the Licensed Account.

The last thing we need to do under this conditional branch, we want to take the address data, based on the user selected addresses, and update the bill to and ship to address fields that have been added to the opportunity entity.  This is the most tedious step because we need to map every field from both addresses, to the fields on the opportunity we’re updating.

Add Step>>Update Record>>Leave Opportunity Selected>>Click Set Properties>>Fill out screen as below:

Killer App for Dialog 14

The key here is that in the Dynamic Property section on the right side of the form, all of our prompt and responses are down in the local values section of the “Look For:” option set.  We are able to get the user selections for the addresses (and the entire row, with all the fields, from our query) from the bill to and ship to prompt and responses in the prior step.  It’s important to name your prompt and responses appropriately, so you know how to refer to them when performing this update.  Once you choose the correct prompt and response, then you have a list of all the fields to choose from that were part of the query for that prompt and response, as you can see from the following print screen.

Killer App for Dialog 15

This is where everything comes together.  On the form, then, for each field, you are selecting the corresponding field from the prompt and response address fields.  This is how you wire (or connect) the update you are performing (on the opportunity for this example), back to the selections made by the user.

This takes care of the first conditional branch.

Next we need to build our second conditional branch.

While the first condition is selected>>Click Add Step>>Conditional Branch.  If Conditional Branch is greyed out, this is because you have to select just in the right place on the first conditional branch (I try to click on the first letter of the first conditional branch name to get the right thing highlighted).

For the field to filter on, again we’re going to choose “Address Options”, but this time, we’re going to choose response value equals 1 (the 2nd selection the user could make, which is that the bill to should come from the reseller account, but the ship to should come from the licensed account.

 

Killer App for Dialog 16

Under this condition, we want to add another page, with, again, 2 prompt and responses, one for the bill to and one for the ship to.

Add Step>>Page>>Name the Page

Add Step>>Prompt and Response>>Name the Step>>Click Set Properties>>Fill out screen as below:

Killer App for Dialog 17

 

This prompt and response is identical to the first two except here, we are using the Query Variable:  “Query Reseller Addresses” because in this condition, the user selected that the bill to address was to come from reseller, rather than the licensed account.

At this point, I would expect you to build out the additional prompt and response for this condition for the ship to address, as well as, the update step, just as we did for the first condition, but we would be choosing different prompt and responses.  In addition, you would add the last conditional branch, page and the 2 prompt and responses and add the update step as appropriate for the last selection.  Once the steps are complete, Click Save>>Activate and then test the dialog as described in the user experience section of this article.

In this article, we have presented a solution that will allow you to extend the address functionality to any “out of the box” or custom entity.  This solution did not require any code and easily extensible.  In the Denver Front Range, we provide our customers with Dynamics CRM solutions that are:

  • Scalable
  • Extensible
  • Upgradeable
  • Flexible
  • Easily maintained

Are you looking to configure your Dynamics CRM solution? Would you like to learn more about this solution?  Leave a comment for me or contact our professionals at crm@mcgladrey.com.

By: Bill Caldwell – Colorado Microsoft Dynamics CRM Partner

 

Bill Caldwell is a director and lead Microsoft Dynamics CRM consultant in the Denver, Colorado practice.  Bill is a certified Microsoft Dynamics CRM consultant and specializes in customizations, reports, customized queries and integrations.  Bill is an active member of the Dynamics community since joining RSM in 2007.  Bill is also experienced with the Microsoft development suites, which includes SQL Server, Visual Studio.Net and SQL Server Reporting Services.  Prior to this, Bill spent five years working in industry as an accountant and financial analyst. Contact Information: Email: Bill.Caldwell@rsmus.com Phone: 303.298.6465 Follow Bill on Google+

Receive Posts by Email

Subscribe and receive notifications of new posts by email.