As most know, you can create a custom entity to fit almost any need using the Dynamics CRM application. I frequently encourage people to think of CRM Entities as forms; forms that have fields to capture data and user input for storing information in a database. Of course, Entities are much more than that as they can have relationships with other Entities, used to make a ‘connection’ between Entities, used as picklist option type sets for multiple Entities, etc. However, it can be easier for users to envision the possibilities when thinking of an Entity as a form that contains fields for data collection.
Because it is so easy to create Entities in CRM, systems can quickly get out of control, end up with redundant Entities, form fields, etc. Therefore, I encourage you to think about a few things before jumping in and creating the Entity. If you put in a little planning upfront, as it relates to creating Custom Entities, it will pay off for you and your users.
I Thought We Had Something Like That
The first thing you want to do when receiving a request for a new Custom Solution is to review your application and see if you already have something similar. It could be that all you really need to do is add a new Tab or some additional fields to an existing Entity and that will fit the need. It is almost always better to use existing Entities rather than creating new ones as that will generally lend to improved productivity and data retrieval. Users can quickly lose interest in an application if they have to create multiple records of different types that have what appears to be related fields. This can negatively impact user adoption.
Naming Conventions & Access Points
Ensure each of the Custom Entity requests you receive include the name that the user wants. Encourage your users to keep the name simple, 24 characters or less is a good rule of thumb. This will be the name that displays in the Navigation menu for those Modules you indicate when you create the Entity. Also, have the user who requested the Entity, identify where they want to see the Entity. Do they want to see it from the Sales module, Workplace, Service, in the Outlook Offline Client, etc. This minimizes guess work and helps to ensure a more smooth implementation.
Obtain all requirements from end users to include sections they want to see on the form with names, tabs with names, where they want attributes (fields) placed, the order, display labels, default values, and attribute requirement settings such as searchable, not required, etc. This will allow you to quickly move through the creation once you’ve completed your prep work.
Although Users will provide you with the Display label for the field / attribute, you will want to come up with attribute names that have a few key elements. My rule of thumb includes; keep it simple and try to apply relevant names that will help others when dealing with ‘back end’ systems like creating reports, resolving issues, etc.
There are some good tools online that will help ensure you have all the information you need to create the Custom Entity or you can quickly create your own tool using Excel or a similar program. You can also leverage CRM by creating a Custom Entity for managing End User Change Requests. This can be valuable for both you and End Users.
Finishing Touches
Once you have the Entity created and the new Attributes or Fields added to the Entity, the form designed and tested, and the Entity published for use, you might think you are done. However there are a few other items to think about and address before you deliver the Entity to your Users.
One of those areas is Relationships. I encourage you to go through the Cascading rules related to your 1:N, N:1, and N:N relationships. I almost always change the existing Cascading rules associated with the Various Activity types like e-mail, task, phone call, etc. to Configurable Cascading rather than Parental and set all values to Cascade None. If you do not change this then the owner of Activities will change when the Custom Entity record is re-assigned in CRM. Additionally, if I create new 1:N, N:1 or N:N relationships, I generally use Referential as the Cascading Type of Behavior. This defaults to Cascade None and removes links to related records if the record is deleted. Since most Organizations want to keep a historical view of the original owner of e-mails, tasks and other related records, I go through the effort to make this change. This adds a little time upfront but it is well worth it.
Views
Default Views are created for each Custom Entity. Here are a few suggestions for making the views more User friendly.
- Update all System Views. This provides consistency and minimizes confusion when Users move from one View to another (Active, My Active, Inactive, etc.).
- Understand and set fields important to users for Preview, Quick Find, ‘New Entity Name’ Lookup, etc.
- Set View Columns in the Preview, Quick Find, etc. to closely match the other System Views
- Leave the default field values for the Find columns in the Preview, Quick Find, etc. or select one or two others. Please note that selecting additional fields can impact performance so take care when making changes.
Updating the various Views related to an Entity can be tedious and time consuming. However, if you want a richer User experience, you will want to take the time to make the changes needed.
Last but not least, you are now ready to go though your Security Roles and apply the right set of access and other security related settings to each Role.
If you follow these basic guidelines when creating Custom Entities, you will hopefully find your CRM application easier to manage and more user friendly.
Cheers!
Donna Edwards 