16. Customisation

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 defined between entities.

· 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 is 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 you customisations cannot conflict with customisations that you may add later copied from another organisation or created by a software supplier.

16.1. Views

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 considerable time when you take into account the time spent liaising with the users.

There are several types 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 a related (one to many) entity in a form.

· The Lookup View is seen when lookup up a related entity.

· Quick Find View are used when searching in a View. Fields can be added Find Columns in this View and used in the search.

· Preview used when toggling the show more triangle on the view.

· Public Views 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 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 alphabetical characters along the bottom of the view which help selection. You might want to provide a view sorted by postcode or account number if users are constantly searching using 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 to select only customers in a View for example.

16.2. Entities

Existing entities can be extended or new entities defined.

A new entity requires the following definition and take care because some of these options cannot be changed once the entity has been created:

· Name.

· Plural Name.

· The Primary Attribute is used to show the related entity value for related entities (often a field called name).

· 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.

· Work Areas which display the entity.

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 your customisations will not clash with other customisations that use the same prefix.

16.3. Attributes

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 cannot be changed once the attribute has been created.

The following field types are available:

· nvarchar - Unicode text value formatted as text, an email address or URL, textarea 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.

· ntext - a large piece of text like 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. Picklist values, for example, are maintained here.

Note: Try and 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.

The requirement level recommends or requires 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.

You can view the entities and their definitions with a CRM utility page as follows (substitute your own server name into the URL):

http://crmserver:5555/sdk/list.aspx

http://crmserver:5555/sdk/mdbrowser/entity.aspx?entity=entityname

There are some system fields that are automatically defined for all entities:

· Primary Key (a Guid).

· Status.

· State.

· Owner.

· Relationships (many to one) have the foreign key identifier stored.

· Created and Modification dates.

The status and statuscode fields are important and are 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 a text value for the entity to make reporting and performance easier.

16.4. Forms

Forms can be easily 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 made read-only. Removing a field removes it from the form only and not the database.

Note: Security is applied to the whole table so users are given read, create, modify, and delete permissions on each entity with the scope modified to the organisation or business unit. Security on individual fields on the form is implemented programmatically with JavaScript if different security is required for different users.

16.5. JavaScript

The behaviour of a form can be modified with JavaScript to enable and disable fields and perform many other tasks. The use of Ajax programming techniques can make this a very powerful feature.

The form designer allows JavaScript code to be pasted into form level events and the preview button allows some limited testing to take place before publishing the modified form. There are two form-level events which can be customised with JavaScript code:

· 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.

There are various JavaScript functions available within a CRM form to set field values, check the status of the form (is it being run from a laptop for example), save the form and so on. Examples can be found online and we recommend that programmers read the Working with CRM book for more information (see the resources section).

16.6. iframes

IFRAMES allow integration with external web sites and are a great way for programmers to integrate with CRM or call external functions such as displaying a map for example. Most of these integrations will require some JavaScript or the passing of the object level identifiers to the page.

16.7. Relationships

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.

N:1 or many to one relationships are important as they determine which entities can be joined together easily to make fields available in a View for example. Each Contact has a Primary Account so the two entities can be joined and fields from the Primary Account displayed alongside the Contact record. Fields from other related accounts (many to many) cannot be displayed because the system cannot determine which one of the many account records to display.

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 onto 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 lookup the Contact to join the two records together. 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 behaviours comprise:

· Referential. The many records can exist independently of the one record.

· Parental. The many record cannot exist independently of the one record.

· Referential, Restrict Delete. The one record cannot be deleted until all 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.

Cascading option extend past that of the behaviour of the Delete operation. The cascading options control how 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.

16.8. Renaming an Entity Description

An entity description can be changed and CRM users often rename the Accounts entity to Company. You can rename the entity easily but to do 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

· Compile and redeploy help files to remote users using outlook for laptops.

16.9. Relationship Roles

Relationship Roles are named relationships that can be easily defined between Contact, Account, and Opportunity entities.

Relationships are added by selecting the relationship pane from the entity form and adding a new relationship. The available relationships appear once the two parties have been entered.

The same relationship role might be entered for both parties in some cases and others will have different relationship roles depending on the party. Relationship Roles are defined in the Settings-Customizations-Relationship Roles work area.

A Doctor-Patient relationship (where the Doctor's Surgery is represented as an account not a contact) for example, requires two relationships to be defined:

· The Patient relationship role which is a Contact role for an Account.

· The Doctor relationship role which is an Account role for a Contact.