The CRM Address Entity: There’s more to it than you think!

I’ve been working with Microsoft CRM in production environments since 1.2 was released, but apart from some minor tweaks to the form I haven’t had to work with the Address entity in too much depth. Until now. I was surprised to find that there are a lot of, er, “undocumented features” that make this built-in entity behave quite differently than I expected. The SDK has a few remarks about the Address entity, but it took me a while to put all the pieces together, and I thought I’d share what I’ve found:

1. Two blank address records are created for each Account and Contact. Out of the box, CRM Accounts and Contacts have built-in fields to capture two addresses. These fields are address1_street1, address1_city, address1_stateorprovince, etc., as well as another whole set for address2 fields.

Whenever an Account or Contact is created, the CRM platform creates two blank address records related to that parent Account or Contact.

The purpose of these two blank address records is to store synchronized data that is entered in the address fields on the Account or Contact itself. The platform handles keeping these two entities in synch. If you change the values stored in the Contact’s address fields, the associated Address record is updated automatically.

2. The first two Address records that the platform creates are hidden in the “More Addresses” associated view on the Account or Contact. I guess this is because these addresses should be maintained on the Account or Contact, not in the Address entity itself. The purpose seems to be so that addresses added on the Account or Contact form are available when you do an address lookup on a quote or order. (Note that you’ll need to enter data in the “Address Name” field on the Account or Contact if you want it to show up in the Address Lookup view as well.)

3. You cannot update the Address record via workflow. You can create workflows based on the Address entity, but it’s not available to update itself. Not sure why, though…

4. You can’t modify the relationship mappings between the Account entity or the Contact entity and the Address entity. And you can’t add custom relationships to the Address entity.

5. Addresses are not available on Security Roles. You want to restrict users from editing or deleting Addresses? Can’t do it, at least not with Security Roles. Go figure…

6. There’s no built-in way to add the parent Account or Contact to the Address form. Adding the “Parent” field to the Address’s Advanced Find or Lookup views only returns a blank column as well. This seems to be a shortcoming or a bug of some sort. For all other entities with a N:1 relationship, you can add the ‘1’ part of that equation to the ‘N’ form. For example, if you create an entity called “Projects” with a N:1 relationship to Accounts, you can add the Account lookup field to the Project form. The lookup field actually consists of an array that contains a GUID, a string for the record’s name, and the object type code (OTC). In the case of Addresses, the only thing stored in the Address table is a field for the GUID. Without the name of the related object and the OTC, the interface can’t present a normal, functioning lookup field.

WORKAROUNDS:

With all of these limitations, organizations that need to manage multiple addresses for their Accounts or Contacts, and that need to perform logic against these addresses regularly, may need to do some workarounds. Among the options to consider: create a plug-in that “un-hides” the first two address records so they’re visible in the “More Addresses” associated views. Another option would be to create a custom entity with a N:1 relationship to the Account or Contact. This option has the benefit of allowing you to do the full range of mappings and workflow that you can do with just about any other entity. The downside is that if you want the address fields on the Account or Contact to be used and available for mail merges and Outlook synchs, the custom entity option will require some more create workflow solutions.

New Article on MSDynamicsWorld.com

I've got a new article published on MSDynamicsWorld.com about assessing your organization's readiness for CRM 4.0. It includes some important factors to be aware of if you are planning on deploying CRM on-premise. The article can be read here.

CRM 4.0 Email Tracking Token Can be Turned Off

Nice feature of CRM 4.0: Users and system administrators alike have never been fond of the tracking token that CRM places in the email subject line in order to track email replies to the correct account or contact in CRM. In CRM 1.2 and 3.0 this token could be turned off completely, but then it was impossible to track replies to CRM emails. With version 4.0, administrators can still use the tracking token for precise tracking, but CRM now offers the ability to turn off the tracking token and still track most messages. CRM 4.0 uses a combination of the email's sender, recipient and subject to figure out which records to relate inbound email to, even without the token! To turn the tracking tokens off in CRM 4.0, go to Settings > Administration > System Settings, and click on the Email tab. See the image below for the checkbox to de-select to disable the tracking token:

CRM Workflow Emails Not Being Sent

I hope this helps anyone who runs into a similar problem: I ran into a problem on a client's CRM server yesterday where the emails being generated from CRM's workflow rules were not being sent out, causing the workflow rule to fail. This had been working in the past, but suddenly it was not. There were a bunch of failed and paused rules in the workflow monitor. taking a look at the failure messages there revealed two different messages:
"Invalid association. the request association is not valid." and "Invalid Visibility Modification Access."

Both of these error messages, along with an error on the CRM server's event log, pointed me to look at the antivirus software. I had run into a problem once before with a CRM server that was running McAfee antivirus that was blocking outbound traffic on port 25 - the port that carries SMTP mail. This client also was running McAfee, and some googling turned up the following KB article (support.microsoft.com/kb/916925) which, among other things, suggests placing the W3wp.exe process in the antivirus software's exclusion list. (I'm not sure if this problem only occurs with McAfee, it just so happens that these are the two cases I've come across, which was helpful since it helped me narrow down the problem a little more quickly than I might have.)

The only problem was that the W3wp.exe process was already excluded from being blocked by the A/V software. In this instance, the CRM server was relaying mail to the Exchange server for outbound SMTP mail, so I thought I'd change the registry settings to make it use the SMTP service in IIS on the CRM server. Before doing this, however, the IT wiz at my client's company discovered that the AntiVirus software was also blocking the CrmWorkflowService.exe - something that's not listed in Microsoft's KB article. By adding this to the exclusion list, workflow email started flowing again.

What are "Subjects" in CRM, and how do I use them?

I sometimes get questions from clients and partners, and find that the answers would be helpful to a broader CRM audience. Today I received a question about the Subject field on the Sales Literature entity in CRM. Here's the quick rundown I gave on how to make use of Subjects:

Subjects in CRM are a useful way to organize a variety of records, and to provide some ability to tie them together. As you may have found, Sales Literature is categorized by subject, as are KB articles, service cases, and some other items. Subjects are added in the Settings area of CRM, and are created in a hierarchy, a “subject tree.”

In the CRM web client, go to Settings > Subjects. It’s pretty straightforward to add and edit subjects. You will want to give some thought to your subject hierarchy, however. A typical approach would be to build your subject tree by product or service offering. So you might end up with something like this:

+Exchange Server
+Installation
+Migration
+Upgrade
+From Other Mail App
+Maintenance
+Cisco
+Router Installation
+Configuration
+Troubleshooting

(I’m sure you get the idea…)

While you can set Subjects as not required, it will help to use this field if you plan on having a lot of literature and KB articles in CRM down the road. To set the Subject field as “not required” on the Sales Literature form, go to Settings > Customization and open the Sales Literature entity. Click on Attributes and double-click the “Subject” attribute (subjectid). From the Requirement Level dropdown, select “No Constraint”, save and close the attribute, and then, back on the Sales Literature entity form, choose Actions > Publish to make the change live.

How To Extend CRM In Order To Clone A Record

Ben Vollmer over on his Mid-Atlantic Microsoft CRM blog has a great post on extending CRM with simple javascript in order to clone a record. Based on a sample for cloning a contact, Ben shows how to add a custom button to a case form that calls a simple .htm page. The .htm page contains some javascript that opens a new case and pre-populates the new case with data from the master case. This is a great example of how easy and flexible the customization of CRM is. I added some comments to his post to show some other ways to use this kind of script to get nice results. Check it out!

Thanks, Ben...

Customizing Printed CRM Records

Got a post from someone on the newsgroup today about how to customize quotes and print them and/or email them. I posted a reply that got pretty long, so I thought I would finish it here. Here's the text of my reply:

I haven't done any work directly with quotes, but I have found that for most of the CRM records, the canned printed forms are somewhat lacking in content and visual appeal. (In addition to being unable to customize them with logos and company letterhead type stuff.)

I ran into this problem with leads. I have a client whose salespeople wanted to be able to print out a "Lead Card" to take on sales calls that would have all the most relevant info on one page. I created a report in Crystal that showed all the lead's pertinent information on the top (basically everything from the Lead form Information tab) and the 5 most recent activities on the bottom, plus the rep's name, etc.

This kind of report is easy to make in Crystal, the problem is that it creates a report for every lead in the database, and would crush the server if I ran it. So the next thing I did was to add a parameter to the report, then add an ISV button to the lead form that passed the lead's GUID to Crystal. You click on the button and Crystal report viewer launches and asks you to select a parameter (you have to have two choices, so in order to keep people from running the whole thing I made the second choice return a blank report). So the salesperson can leave the parameter at the default choice without selecting, and click OK, and voila---they have a customized, easily printed lead card.

[There's more about using parameters in CRM and Crystal Reports on Microsoft's website in a whitepaper about optimizing CRM performance.]

I think this would work well for quotes too. The next problem is how to email them, which I haven't had to try to figure out yet. That's a little harder, because from here you would basically be trying to email a dynamic web page. Maybe you could then use a PDF utility. Copying the report and pasting it into Outlook or word (or a CRM email) will cause it to lose formatting. I think I would look for a cheap or shareware PDF utility for salespeople to use so they wouldn't have to buy a copy of Acrobat.

Here are some screenshots of the lead card button and the screen that comes up in the Crystal Report Viewer window prompting you about the parameter:




After the user clicks OK, the one page lead report for the specific lead comes up. This same method could be used for quotes, or any other entity in CRM.