In this post I will show some new (usability) features in customizing entities. I really like the way almost all tasks can be accomplished without closing the form editor. Because I need to customize an entity for this demonstration, I thought it would be nice to demonstrate the new possibility to create custom activities at the same time. Customer Relationship Management has its roots in automating 'customer correspondence' files. Microsoft CRM has always had a very strong selling point there with the Outlook plugin that made tracking (and sharing) e-mail correspondence almost zero-effort. As you probably know, tracking 'contact moments' with 'customers' was not limited to contact by email. In Microsoft CRM 'contact moments' are tracked in activity entities like appointment, task, phone call, letter or fax. There are also a few special activity types that were included more for history completeness than because they were truly contact moments, like 'case resolution' and 'opportunity close'. A bit of a negative in CRM up until 4.0 has been the inability to add you own activities and the limitations on customizing activities. I have always been able to 'explain this away' by pointing out that the activity records easily contain hundreds of thousands of records, even in a small deployment, and that keeping the performance good has a cost in how much customization you can do. And if that didn't convince, I could always make some cryptic remark about the Outlook synchronization depending on activities (good thing they never asked me just how this was an issue with customizing J). The true reason is probably more that the behavior of activities in CRM is 'not so standard' and to allow you to extend on that would be a lot of extra work for the engineers at Microsoft. The good news is that in Microsoft CRM 2011 most of these limitations are lifted. We now can: Create our own activity entities Fully customize the 'activities' and 'closed activities' (formerly 'history') views, including filter criteria and sort order The fields 'base' activity (containing the fields that are shared between all activities) is still not customizable, however, so this in a sense limits your ability to customize it's views as well. Also, a new 'recurring appointment' activity has been added. I might write a post about that later. Create a new activity entity Ok, suppose we are running a Web 2.0 type of operation and we need to track tweets about our products and campaigns. We want to have this as part of the contact history of our contacts/accounts because To do this, we will create a new activity entity 'tweet'. This is very straightforward. Go to the new 'development center' (Settings -> Customizations -> Customize the System) and select New -> Entity. On the new entity select 'Define as an activity entity'. This disables a lot of the other checkboxes because these are no longer relevant. On the Primary Field tab, we see the primary field is automatically set to 'Subject' and has a length of 200. For tweets this is just fine. A tweet has a maximum length of 140 so apart from the subject, we really don't need much. So we press 'save' and continue to change the form. Notice that repositioning the fields in CRM 2011 is done by drag & drop. Now, what we need is a new field for the 'twitter user' who tweeted this tweet. In CRM 2011 this can be accomplished directly from the form editor by clicking the New Field button below the field list. Also, the name of some properties are not so intuitive as they could be. Actual end could better be something like 'date' as this will be the time the tweet has taken place. And Subject should be renamed to maybe 'tweet'. We could (of course) update the labels on the form, but that would leave the old labels in the views. Better is to change the 'Display Name' of the Field itself. In CRM 2011 we can do this within the form editor as well. Select Actual End and click op Properties. Then go to the details tab where you can now click the Edit button. It would have been nice if this new Display Name was immediately set on the Label as well. Now we need to either update that manually or remove and re-add the field. Let's hope they fix this before RTM. Now, this 'owner' field is pretty pointless here as well. I would like to remove it from the form but it is 'locked' as a 'required field'. I used to do this by either hiding it in Javascript or placing it on a tab called 'administration' to get it out of the way. In CRM 2011 there is an easier way to accomplish this. In the Form Editor you can uncheck a 'visible by default' box and the field is hidden for us. Now, after some icons (I will get back on the new way CRM 2011 handles resources like icons in a future post), we now have our own custom activity. Let's add a 'tweet' to an account: Now, the form for our new activity opens and we can add some data: Selecting 'Mark Complete' the tweet now appears under 'closed activities' (history in CRM 4.0) under the account. Customizing Associated Views New in CRM 2011 is the ability to fully customize the 'special' views like the Associated Views and the Lookup Views. This includes the ability to change the filtering. In the customization center, open the Activity entity and choose 'Views'. Select the Open Activities Associated View and edit it (double click). On the View editor (not shown), select Edit Filter Criteria and the following dialog appears: Here we can see 'Is Regular Activity' 'Equals' 'Yes' on the filter. This filters out system jobs and other items you don't expect to see. Twitter integration for CRM 2011 or CRM 4.0 If you're looking for twitter integration for Microsoft CRM 2011 (or CRM 4.0), we have a component for this that we are currently 'packaging'. Please drop us a line if you're interested.

New in Microsoft Dynamics CRM 2011 is the possibility to create multiple forms for the same entity. This makes the following scenario's possible: Show a different form depending on the user's role in the organization ('role tailored' forms), e.g. The 'order' form for the account manager contains summary information about the status of the order, maybe including financial details, work done and progress. The 'order' form for the engineer is an entry form for information about part delivery, schedules and work/progress entry. A person in both 'account manager' and 'engineer' roles could switch between both available forms depending on the task at hand. Allow (some) user(s) to choose a form depending on the action he wants to perform ('special purpose' forms), e.g. Create a specialized 'entry' form showing fields in the best order for data entry and including javascript logic for easy entry and input validation and create a normal 'overview' form showing fields to give a good summary view of the record. Printing a record now prints the current form. This means that a form can be designed specifically for printing as a way to customize printing a record (customizing the 'print view' is not possible in older versions like CRM 4.0). With some javascript, show a different form depending on entity properties ('record type' forms), e.g. We want to use 'contact' cards for both students and faculty members. Now we can use a different form with different form logic for both types by using javascript to select the right form 'on open'. Using the option to hide the 'navigation items' you can create dialog style forms. In this post I will show: How to create multiple forms and how this affects printing records How to assign forms to roles and how the default behavior is How to choose a form if multiple forms are available and setting the default form At the bottom, I will also give some 'best practices' to allow you to pick the right multiple form strategy. How to change forms with javascript will be the topic of a different post where I will also look into 'dialog style' forms. How to create multiple forms for an entity Suppose we are designing a system for a Real Estate Agency. Their agents can be employed in two roles: as a Buying Agent or as a Listing Agent. Potential sales for either role will be tracked using opportunities so a nice pipeline can be created giving an overview of all potential revenue. As a Buying Agent they need to track information about the desires (and constraints) of the buyer. So let us create a form for that. Go to the list of opportunities, change the ribbon to the Customize tab and choose 'Customize Entity'. The new customization center will show in a different window. The opportunity entity will already be selected. Choose 'Forms' in the left menu and select New -> Main form: The form designer will open with a new 'almost blank' form. Use the 'Form Properties' button on the 'Home' tab in the ribbon to set the name of the form. After adding a few fields, select Save and then Publish. This form will now be the default (for 'System Administrator' and 'System Customizer', more on that later) but in order for this default to be effective, you need to close all instances of Internet Explorer and then return to CRM. Opening an opportunity with the sample data now looks like: Printing records A bonus of this new 'multiple forms' feature is that it is also a way to customize printing behavior. When printing a record, the layout of the current form is used for printing: Tip: when creating specialized forms as in this example, leave the default form for what it is. This keeps the default form available for all people not requiring a specialized form. Also, the default form is always present so other customizations might depend on it, especially if these customizations originate from older versions of CRM where multiple forms do not exist. How to assign forms to roles Go to the Customize tab on the ribbon and choose Design, Form to open the Form Editor. Choose Assign Security Roles: Under 'Assign Security Roles' you can select the roles that you want to have access to this form (or use the radio button to give all roles access). There is also a 'Enabled for fallback' option (selected below, by default unselected). This works as follows: If a role has forms assigned to it, only the forms that are explicitly assigned are shown. If a role has no forms assigned, all forms that are 'enabled for fallback' are shown. It is mandatory for an entity to have at least one form with 'enabled for fallback' checked. This means that as soon as you explicitly assign a form to a role, the default form is no longer shown. If you want to continue to have the default form available to that role, you need to explicitly assign the default form as well. Default form visibility The default 'Information' form is assigned to no roles and has 'enabled for fallback' selected. New forms are by default assigned to 'System Administrator' and 'System Customizer'. This means that for 'us customizers' a newly published form will replace the default form as we now have a form assigned explicitly, but for all other users the new form remains invisible. This is nice default behavior as it will enable us to test the new situation for the role we intend to target for the form. How to choose a form if multiple forms are available and setting the default form For this example we will give the 'System Adminstrator' role two forms to choose from. This can be accomplished by checking the assignment box for the 'System Administrator' role on the default 'Information' form. This gives the administrator two explicitly assigned forms. Alternatively, we could clear the assignment checkbox for 'System Administrator' on the 'Buyer' form and checking fallback. This gives all roles two fallback forms and because the 'System Administrator' role now has no forms assigned, it will use both fallback forms. How to choose a form if multiple forms are available Now we have both the default form (titled 'Information') and the new form ('Buyer') available. The desired form can be selected in the navigation pane, left: Setting the default form The form that opens by default for a record is the first form in the 'assignment order'. This assignment order can be modified as follows. Go to the customization center for the Opportunity entity again (see above or via Settings -> Customization; Components -> Entities -> Opportunity) and select Forms, we can change the 'Form Order': A dialog opens where we can change the order: Determining the default form for a user works as follows: Consider all the roles the user is in; For each role, determine which forms are visible; Of the visible forms, the topmost form is shown by default. This means that getting the default form right for all users can be a bit tricky if forms are re-used between roles in different combinations and users are assigned to multiple roles. In practice, however, this is seldom the case. Form visibility 'best practices' or 'choosing a multiple form strategy' In a 'role tailored client' situation, create new forms and assign them to the corresponding roles. Keep the default 'Information' form as 'the fallback form' for all roles that do not require a 'role tailored' form. If you want users to have multiple 'role tailored' forms to pick from, it is usually better to assigning them to multiple roles as this also sets correct security. CRM security works 'additive' (there is no 'deny' option). This makes it a best practice to create roles that contain the minimal security needed for that role and then combining roles on a user if a user should be able to accomplish tasks of both roles. This 'additive security' is not strictly true for forms. If role A works with fallback forms and role B has a form assigned explicitly (e.g. a 'role tailored' form), a user having both roles A and B will only see the explicitly assigned forms. This can be solved by assigning the fallback form(s) explicitly to role A. For users only in role A this will make no difference. You can use the form order to set which form is the default for each user. As there is only one form order that is used for all roles, not all scenario's with default forms are possible. For 'special purpose' forms, like a specialized 'entry form', it is best to create these as an extra 'fallback form' and use the Form Order to set the right form to open by default. If 'special purpose' forms are mixed with 'role tailored' forms in a solution, you need to check the roles with 'role tailored' forms on the 'special purpose' form as well in order for the 'special purpose' form to be available. For 'record type' forms (see my post about using javascript with multiple forms) make sure the forms for all record types are available to all users having access to these record types. This is best accomplished like for 'special purpose' forms, above. Usually it is best to order forms like this: First: Role tailored forms (if necessary ordered correctly for users that have multiple roles assigned) Second: the default 'Information' form Third: 'special purpose' forms Last: 'record type' forms (as those will be chosen by javascript anyway)