The Microsoft Dynamics CRM Team Blog
News and views from the Microsoft Dynamics CRM Team
What is terminology in Microsoft CRM? Terminology is what we use to describe the collection of terms used for specific items in CRM, from entities/record types to wizard names to field labels. I spend a lot of time researching terms across Microsoft and in various industries trying to figure out which words will mean the most to you – get the point across - without you having to learn anything new. (Believe it or not, even though I’m in the business of educating users, one day I want all the Help to be accessed in the user interface (UI) itself, so you don’t have to go search for it. Better yet, I want to design products so easy to use that you don’t need any help at all.)
I strive for “intuitive” words, the ones that are considered user-friendly, non-techy, not jargon. Getting that right is harder than you might think. Microsoft CRM has a broad audience of users. Often, I come up with a word that will mean the right thing to one group, like system administrators, but won’t be clear to another, like sales reps. For example, you might have noticed above “entities/record types”. That’s one of those situations. In v1, we were certain that sales reps, customer service reps (CSRs), and business managers wouldn’t know what an “entity” was. That it wouldn’t make sense to them. But there are places in Microsoft CRM where an “end-user” (sales reps, CSRs, business managers) will need to select an entity. Since we call each instance of an entity a “record”, we decided to call the group of instances “record types”, i.e. Account record type, Contact record type, Case record type, etc, when we were talking to our end-user audience.
Did making this distinction work? Maybe. If a term works, most of the time no one says anything about it. If it doesn’t, the feedback I get is, “I don’t like it.” Sometimes people give me great ideas for replacement terms that are great because they are 5 or 6 words that describe the term. I wish I could use those. I agonize over it. But I have to distill those descriptions down to 1 or 2 words that will fit into a field or button label – with 30% empty space left for the expansion that often happens when the product is localized into other languages.
“Case record type” also brings up a good point. Once a term is in the database, consider it written in concrete. I’ve tried. Really I have. But no one will let the Editor do a copy edit on the database in order to change the name for the Incident entity to Case or sync up the names for the access levels (Global, Deep, Local, Basic) in the system to the ones we’ve used in the UI (User, Business Unit, Parent: Child Business Units, and Organization). Discrepancies like this happened mostly before I came on to the team in v1. Hopefully, you aren’t seeing more of those now.
If you have questions/comments about the terms we’ve used, please respond to this post. I’d love to hear all your comments. I’m starved for it actually. Most of the doc feedback we get goes to the writers (lucky people!) because you ask questions about how to do something. However, several people have written in to ask, “What does this mean?” and that’s my cue! I love those questions. I use that feedback to add to our in-product glossary, which you get when you download our Help updates, and to inform future terminology decisions. If you have other ideas about where you’d like to see terms defined, whether technical and user-friendly terms for the same concept are helpful, opinions about existing terms – good or bad, or comments about names in the product, let me know. I’m listening.