Microsoft CRM has a very robust software framework which enables end users to create and alter the database definition from the user interface. Technical skills are not required but permissions to perform customisation are usually reserved for the systems analyst or a system customiser who is in charge of making changes to the system.
This chapter discusses mainly entity customisation where existing and new entities can be defined in several ways:
· Views can be created for all users (personal views can also be shared by the user).
· Custom entities can be created.
· Existing entities can be modified and attributes (fields) changed or new fields added.
· Forms can be altered (only one form per entity).
· Relationships and mappings can be defined between entities (mappings automatically copy field values over from the parent when creating a child record).
· Relationship roles can be defined between the account, contact and opportunity entities.
Any changes made in this area are not reflected in CRM until the appropriate entity has been selected and the changes published by pressing the Publish button at the top of the page.
Before you add any new entities or attributes you should alter the prefix in the customization tab available from settings-administration-system settings to a unique prefix for your organisation. This ensures that your customisations cannot conflict with customisations that you may add later copied from another organisation or created by a software supplier.
Views are very easy to change, and the users themselves can create their own views. A fully customised version of CRM may need many views changed, and this can take some time when you take into account the time spent liaising with the users.
There are several kinds of view:
· The default view (specified with the Actions menu) which is the view first seen when selecting on the entity.
· The associated view is seen when clicking on the navigation pane for a related (one-to-many) entity in a form.
· The lookup view is seen when looking up a related entity.
· Quick find views are used when searching in a View. Fields can be added to find columns in this view and used in the search.
· Public views are defined for all users.
Note: Personal Views can also be shared with other users by the owner.
Views can be edited (only if you have security rights), and you can add fields from any related (many to one) entity. The position of the fields can be changed by selecting the field and clicking the green arrows, and the field widths can be set with change properties.
Each View can be sorted on any (single) field which also powers the alphabet bar along the bottom of the view to help selection. You might want to provide a view sorted by postcode or account number if users are constantly searching with these criteria.
The filter criteria can be specified so that only selected records are shown. The relationship type on the account entity might be used, for example, to select only customers in a View.
Note: Quick find views allow one or more find columns to be specified and are used to search through the table when using the search option for a view.
The preview form is defined together with the views when customising an entity and allows for a collection of fields to be seen by toggling the see more triangle on the view without needing to launch the entity form.
Existing entities can be extended or new entities defined.
A new entity requires the following definitions, and take care, because some of these options cannot be changed once the entity has been created:
· Plural Name.
· The Primary Attribute is used to describe the entity occurrence and is displayed as a hyperlink on a form where a relationship is made to the entity (take care as it cannot be changed later).
· Organisation or User Ownership. This affects security, as only user-owned entities can have business units and allow security to be defined.
· Synchronisation with the Outlook Client.
· Allow Notes or Activities to be added against the entity.
· The Work areas which display the entity can be specified.
Note: All new entities and attributes are automatically created with a new_ prefix. It is a good idea to change this prefix in the Settings menu to a different value so that your customisations will not clash with other customisations that use the same prefix.
Once an entity has been created, the attributes (fields) can be defined. Each field has a type and a display name and a schema name. The schema name and type are set into the database structure and cannot be changed once the attribute has been created.
The requirement level is used to recommend or require that the value is entered by the user on a form. See the next section on how to edit the form to include the new field.
The following field types are available:
· nvarchar – Unicode text value formatted as text, an email address or URL, text area or ticker.
· picklist – integer representing a value defined in a list of options.
· bit – yes/no value
· int – an integer whole number formatted as an integer, a duration, or a time zone.
· float – a decimal number.
· money – a decimal number representing a currency value (which automatically stores both the currency and base currency values).
· ntext – a large piece of text such as a note (or email body).
· datetime – a datetime value which can be formatted to show just the date if required.
Selecting a type will change the available format options available.
Note: Try to ensure that you always add and delete values together on all similar picklists, as CRM does not recognise the text value of the picklist when performing any mappings and always takes the integer value for comparison.
You can view the entities and their definitions with a CRM utility page as follows (substitute your own server name into the URL):
There are some system fields that are automatically defined for all entities:
· Primary Key (a GUID).
· Relationships (many-to-one) have the primary attribute values as well as the foreign key identifier stored.
· Created and Modification dates.
The status and statuscode fields are important and are often used to define the workflow and the status of an entity on completion. Note that most related fields and picklist values store both the key value and a name value corresponding to a text value for the entity to make reporting easier.
Forms can easily be customised in a web-based editor available in the settings-customizations-customize entities work area. Each form is composed of several elements:
· Tabs across the top of the form.
· Each tab is divided into sections which may optionally display header information.
· Fields are positioned within each section.
· An iframe allows a URL to be specified to pull in information from an external website.
Fields can be moved around within a section with the green arrow buttons. Selecting the change properties option allows fields to be moved between sections and the label changed or the field disabled (made read-only). Removing a field removes it from the form only and not the database.
· OnLoad – this allows the form to be initialised as it is loaded.
· OnSave – form level validation occurs here with a false value returned to prevent the form from updating.
Field level events comprise just the OnChange event which fires each time the field is updated. The example below shows how a programmer can add an onchange event to the quantity field on a quotation and automatically calculate the tax.
Note: Programmers can also access the internal functionality of CRM with plug-ins and you might want to disable the tax field and calculate it automatically as the data is saved.
Custom entities usually require that one or more relationships are defined to relate the entity to existing entities already in CRM. Relationships can be of several types:
· 1:N or one-to-many. For example, each order may have many order items.
· N:1 or many-to-one. For example, each order item belongs to just one order.
· N:N or many-to-many relationship. For example, an account can have many contacts and each contact can be associated with several accounts.
Many-to-one relationships are important as they determine the entities which can be joined together easily to make fields available in a view. Each contact has a primary account so the two entities can be joined and fields from the primary account record displayed alongside the contact record. Fields from other related accounts (one-to-many or many-to-many) cannot be displayed in a view because the system cannot determine which of the many account records to display.
Note: Relationships can be self-referential so that a manager, for example, can be defined for contact records that refer to the manager also stored in the contact table.
The following screenshot illustrates the creation of a many-to-one relationship from a custom entity called holiday to the contact entity. The primary entity (contact) is the one side of the relationship, and the related entity (holiday) the many side so that each Contact can have many Holiday records but each Holiday just one Contact.
Publishing the customisations (for both contact and holiday) adds a new option into the navigation pane of the contact entity form showing Holidays. Selecting this pane allows new holidays to be added and related to the contact.
The Holiday entity is also made available from the sales work area, and adding a new Holiday record allows the user to look the Contact up to join the two records together. In this case, a Holiday record cannot exist without a related contact record in this example because of the parental relationship. Complex behaviour can be defined so that all holiday records are deleted, for example, if the parent contact record is deleted.
The available modes are:
· Referential. The many records can exist independently of the one record.
· Parental. The many records cannot exist independently of the one record.
· Referential, Restrict Delete. The one record cannot be deleted until all of the many records have been deleted.
· Configurable Cascade. Configure each feature manually so that changes in ownership and so forth cascade down from the one entity to the many records.
The cascading option extends past that of the behaviour of the Delete operation. The cascading options control the way in which the related records in a many-to-one relationship change if the parent record also changes. Changes to the Owner assigned to the master record, or to the Teams shared, can be passed on down to the related records.
Note: You may need to change some of the system relationship cascade behaviour to stop changes in the ownership of a Lead, for example, from reassigning all related activities to the new Owner.
The Mappings for a relationship allow fields to be copied automatically (from the one to the many entity) when a new entity is created. For example, the email address of the Contact is copied over automatically when the Holiday record is created from the contact form.
An entity description can be changed, and CRM customisers often rename the Accounts entity as Company. You can easily rename the entity, but doing the job properly requires more than just changes to the entity name:
· Change the entity name and plural name.
· Rename any views.
· Rename any labels on the forms.
· Change system messages.
· Change labels in reports.
· Change the online help.
Relationship Roles can be defined between the core account, contact, and opportunity entities to capture relationships between entities. For example, you may sell services to doctors and their patients and need to keep track of their relationships.
In this case you might create a relationship called doctor to make relationships between the Doctor’s Surgery (account) and their patients (contacts). This is an account role for contacts and you would also create the opposite patient relationship as a contact role for accounts.
The example below shows the creation by the system customiser of a relationship that operates between accounts and contacts:
You can create the relationship from the contact (or the account) form by adding a new relationship from the relationships pane. Select the current contact record as party 1 and then select the appropriate account record for the Doctor’s surgery in party 2. Now you can specify the appropriate roles and use them later for marketing or informational purposes when communicating with the Doctor or their Patient.
Note: Relationship Roles are flexible but are difficult to report on and difficult for new users to understand. A similar (but less flexible) relationship can be created between entities by creating relationships between entities.