Whenever you create a new Entity within CRM, you generally find yourself going through the same rhythm each time, both in terms of the general approach from a planning perspective and then the setup involved just after you hit ‘Save’ when creating the new Entity. Whilst often somewhat laborious, these steps are essential in ensuring that your Entity is configured in a professional and clear way. Anyone who works often within the Customizations area within CRM should have a well-defined “checklist” of items that are worked through as a minimum after an Entity is created. In this week’s blog post, we will focus on what I think are the most important things you have to look at doing once a new Entity has been created. Note that the below checklist should not be taken as “gospel” for what you should be doing, and there are a few things below that are more personal preference based as opposed to being absolutely required. I would be interested to hear if anyone has their own checklist items they follow when creating new Entities in the comments below, so please feel free to share 🙂

Decide Options for Entity

You have a number of different options you can specify on Entity creation, which facilitates additional functionality such as duplicate detection, support for Business process flows etc:

Since a lot of these options are irreversible once you select them, it is generally better not to add them in when your Entity is first created, unless you are absolutely sure you need them. Enabling them from the outset will potentially add a number of additional attributes, which may impact on performance long-term. As a minimum, however, I would suggest that the Duplicate detection option is always selected. This is because you will almost always want to configure some kind of duplicate detection rules on your data, in order to ensure your CRM does not get clogged up with useless or unnecessary data.

Give everything within your Entity a clear and meaningful description

Regardless of whether it’s a form, attribute or a view, you should always ensure that a Description field is supplied with an appropriate 1 or 2 lines of text that describes what it is and what it is doing. You should never assume that it is obvious what a particular field is doing, and you are potentially doing a disservice to yourself, colleagues and your end-users by not taking the time to complete this step. My preference is always to be borderline obsessional in this regard, as past experience has taught me the invaluable nature of clear documentation and how my extra effort at the outset can potentially save hours for someone down the line.

The Curious Case of the Name field

Every custom Entity needs to have a Name, or Primary, field, which is specified on creation. You are limited in how this is customised, which can lead to trouble deciding how best to utilise it:

Where possible, you should customise the Name field so that is storing some required value on your new Entity. For example, if you have a new Event Entity, then you can use the Name field as the Event Name field. If it’s the case that you decide not to use the Name field at all or are unable to find a suitable use for it, then you will still need to ensure that this is populated with a value of some kind. The reason? On the record page itself, CRM will populate the field with a rather undescriptive and generic value:

Now you could just force it so that end users populate this field with a value, but this in my view creates unnecessary data inputting steps and could lead to significant discrepancies within the database on how this data looks. It is better to create a workflow that populates this with a consistent value, that references other fields that will always contain data of some kind. The benefit of this route is that, if these fields are ever changed on the record, you can configure your workflow to run again to update the Name field accordingly.

Rename the Main form and update the description

I find it really annoying and strange that the default form created for new entities is called ‘Information’ as opposed to just ‘Main’, so I generally always rename this accordingly, updating the description of the form as well in the process.

Tidy up the default System Views

This step will generally need to be done after you have created all of your Entity attributes. When you first create your Entity, CRM will automatically create the following views for you:

• Two default public views - one that shows all Active records and another that shows Inactive records.
• An Advanced Find View - This is used whenever a user clicks the Create Personal View button or selects [new] from Advanced Find when creating a new view. Essentially, it is used as a default template to assist users when creating new views.
• An Associated View - Shown when the user clicks on the related records button on the sitemap from a form.
• A Lookup View - Shown when the user clicks on the ‘Look Up More Records’ button on a lookup field
• A Quick Find View - This view is displayed when a user performs a Quick Search function from the Entity view page. The important thing to remember with this is that only the fields that are specified under Add Find Columns will be searchable via a Quick Search, so you will almost certainly need to customise this at some stage.

The views are always populated with the Name field and the Created On field. You will need to ensure that all of these views are modified so they contain the information that is most pertinent about your new Entity. If you are not using the Name field at all, then removing it from these views would be sensible, to ensure that end-users are not confused by a list of Entity records with a blank value being displayed.

Update your Security Roles accordingly

This can be sometimes easy to overlook, but unless you have configured your organisation’s security roles to include all relevant permissions, then your users won’t even be able to see, let alone use, your new Entity! So you should always ensure that your organisation’s security roles are updated to reflect the data access requirements of your business.

Conclusions or Wot I Think

Having a consistent approach when it comes to designing a CRM system is important for a number of reasons. It helps to inform and shape best practice approaches within a business, enables you to ensure a minimum level of quality as part of your solution and is essential when working as part of a team to ensure that team members are able to easily go into a solution and understand how everything operates. By combining together past experience, mixed together with well-understood best practice approaches, it can be very straightforward to put together a set of items that need to be checked-off as part of creating a new Entity, and will give everyone within a team the confidence and surety that they are customising CRM in the correct manner.