Armanino Blog

Best Practices for Designing New Entities in Microsoft Dynamics CRM

February 12, 2014

MS CRM is a very powerful tool, and very easy to customize—this can be good and bad. However, with some planning, you can help ensure that any new entities you add to the system make sense and are easy to use.

Before Adding the New Entity

  • Understand your company-specific terminology. One of the first things you should do is ensure you understand the terminology that will be used in your organization. For example, you're building a new entity to track projects, and the entity is referred to inconsistently as a "Job", "Task", "Project" or "Team Project". Ultimately, it doesn't matter which one is chosen, but there needs to be a agreement on a name, and that name needs to be consistently used throughout your system. Having consistent naming and terminology is very important in ensuring an easy to use system.
  • "Wireframe" data layout. Next, I generally like to "wireframe" the data layout of the new entity. There are a number of tools (both free and commercial) to help you along this path. One very popular tool is Visio, but even a whiteboard or some notes on paper can be of great use here. No matter how simple it might seem, planning ahead is always best practice.
  • Request feedback. Once you have a basic idea on the data layout, it would be good to include some people that will be actually using this new record, get their input and continue drawing up the plan before implementing in CRM. NOTE: This step is very important and can save you a lot of headaches down the road.

All of this planning may seem like overkill—especially since adding a new entity to Dynamics CRM takes about 3 clicks—however, these tasks are easily completed, and as the system grows larger and more complex, poor initial planning can result in decreasing productivity, system usability, increased training costs, and at the worst case user adoption of the system.

To illustrate the confusion that lack of planning can cause, I've put together a scenario below:

Sally is tasked with building a project tracking system in CRM. She gets a general idea of what is needed and starts adding the new entities to the system.

She creates a project entity linked to an account that has a number of tasks underneath, each linked to a user. She wraps this up in half an hour and starts showing the project managers her hard work. The project managers say "That's great Sally, but we don't have Projects, we have Jobs, and Jobs have Work Items not Tasks, and Work Items are assigned to Technicians not Users."

Sally says "No problem! I'll just update the display names on the entities and fields". Sally then proceeds to updates the display names on all the forms in 15 minutes and everyone is happy.

Below are just a few examples of how this lack of planning could become an issue:

  1. The first problem with this is, depending on how you change a display name of a field or entity it might not update the referenced display names in other places.

For example, if Sally updates the Project form and changes the field title for the Account lookup to "Customer", this doesn't update the display name of the actual field. So on the form it's a "Customer" but in views it's an "Account", a bit confusing and not terribly difficult to update, but it is more time spent cleaning up a mistake that could've have been avoided in the first place.

  • A new employee is told to find all the completed jobs for a specific customer. He opens Advanced Find but because "Customer" is known as "Account" it takes him a bit longer to design the query, now this new employee sees this system as confusing and will be more reluctant to use it in the future.
  • A few weeks later the project managers want to implement some automation that closes out a job when all the work items are flagged as complete. They call up Developer Dave and describe this to him. He jumps on CRM and finds the Job entity but notices that the back end name is "new_project" so through-out his code he refers to it as a project, same thing with the Work Items and Technicians. It takes developer Dave some time to get used to this and he could've written his code a lot quicker if he didn't have to constantly cross reference the names of fields and entities to what the users know them as.

Now in this case the problems presented are pretty minor and easily overcome, but as the system grows larger and more complex these minor naming convention discrepancies get more confusing and more difficult to work with.

As you can see, planning ahead will enable you to create an intuitive system and eliminate confusion. You are building a CRM system to make your lives easier, right?

Stay In Touch

Sign up to stay up-to-date with the latest accounting regulations, best practices, industry news and technology insights to run your business.

Related News & Insights
Armaninos 10th Anniversary Reception in Chicago
Live Event
Rooftop reception to celebrate Armanino’s 10th anniversary with the firm’s supporters and friends.

September 29, 2022 | 02:30 PM - 05:30 PM PT
Nonprofit Symposium 2021
Live and Virtual Event
Nonprofits - Get Back to [Focusing on] the Future

September 29, 2022 | 08:00 AM - 12:00 PM PT
Workday Adaptive Planning 2022 R2 Release
Learn about Workday’s newest features and enhancements.

August 30, 2022 | 10:00 AM - 11:00 AM PT