Avoiding form reload when switching CRM forms based on a field

Quite often we define different forms for a given entity and we do a form switch based on a field rather than based on the security role of the user. The problem we observe with this approach is that there is often a double form load because when the wrong form loads then record re-loads using the appropriate form. This post offers a solution for avoiding the double form load in this scenario.

Say you have different types of opportunity which are identified by an “Opportunity Type” field and each opportunity type has its own form and BPF. The traditional approach would be to have a JavaScript on load of the form which will navigate to the appropriate form. The issue is that CRM web application loads by default the form that was last used by the given user. So if the user was looking at an opportunity of type “New Sale” and then opens an opportunity of type “New Service Contract” then the service contract opportunity will first load using the “new sale” form and after that form is loaded it will open the correct “service contract” form. The effect is bad user experience because the form loads twice so it doubles the form load time.

I have come across a solution that prevents this double form loading from happening which was suggested by a colleague. The solution is based on the premise that we can change which is the last viewed form for a given user on the fly when the user is retrieving a record. So you can intercept the retrieve operation from a plugin and then look at the type of opportunity that the user is retrieving and then update the user’s last viewed form to be the correct form for the opportunity type that is just getting retrieved. This way, the opportunity is always loaded in the correct form without a form switch.

The solution is a two-step process for the retrieve plugin:

1. In the pre-operation you must make sure to include the “opportunity type” field in the ColumnSet so that it is available later on for you to decide which is the appropriate form for the record.

2. In the post-operation you will have the “opportunity type” value and then you can update the user’s last viewed form to the correct form for the given opportunity type. To do so you simply need to modify the UserEntityUISettings entity for the given user and set the lastviewedformxml field.

Here is some sample code to use from your Retrieve plugin:

on Retrieve plugin

1. var pluginContext = (IPluginExecutionContext)context;
2. if (pluginContext.IsPreOperationStage())
3. {
4.     var columns = (ColumnSet)pluginContext.InputParameters["ColumnSet"];
5.     if (!columns.Columns.Contains(OpportunityTypeAttributeName))
6.         columns.AddColumn(OpportunityTypeAttributeName);
7. }
8. else if (pluginContext.IsPostOperationStage())
9. {
10.     var currentEntity = context.GetEntityFromContext();
11.     if (currentEntity == null)
12.         return;
13.  
14.     SetForm(currentEntity.ToEntity<Opportunity>(), service, context.UserId, tracingService);
15. }

 

Set the correct form

1. private void SetForm(Opportunity opp, IOrganizationService service, Guid userId)
2. {
3.     var query = new QueryExpression(UserEntityUISettings.EntityLogicalName);
4.     query.Criteria.AddCondition("ownerid", ConditionOperator.Equal, userId);
5.     query.Criteria.AddCondition("objecttypecode", ConditionOperator.Equal, Opportunity.EntityTypeCode);
6.     query.ColumnSet = new ColumnSet("lastviewedformxml");
7.     var settings = service.RetrieveMultiple(query).Entities;
8.  
9.     // Some users such as SYSTEM have no UserEntityUISettings, so skip.
10.     if (settings == null || settings.Count != 1 || opp.pwc_OpportunityType == null) return;
11.  
12.     var setting = settings[0].ToEntity<UserEntityUISettings>();
13.     string formToUse;
14.     switch ((pwc_contractedengineservice)opp.pwc_OpportunityType.Value)
15.     {
16.         case pwc_contractedengineservice.NewSale:
17.             formToUse = String.Format("<MRUForm><Form Type=\"Main\" Id=\"{0}\" /></MRUForm>", AdHocEngineServiceSaleFormId);
18.             break;
19.         case pwc_contractedengineservice.ServiceContract:
20.             formToUse = String.Format("<MRUForm><Form Type=\"Main\" Id=\"{0}\" /></MRUForm>", ContractedEngineServiceSaleFormId);
21.             break;
22.         default:
23.             return;
24.     }
25.     if (!formToUse.Equals(setting.LastViewedFormXml, StringComparison.InvariantCultureIgnoreCase))
26.     {
27.         // Only update if the last viewed form is not the one required for the given opportunity type
28.         var s = new UserEntityUISettings { Id = setting.Id, LastViewedFormXml = formToUse };
29.         service.Update(s);
30.     }
31. }

 

Regarding the supportability of this approach it seems to be a grey area. Technically you are doing operations via the SDK and using regular plugins which seems like a supported approach. The only problem is that the lastviewedformxml field of the UserEntityUISettings which is not documented in the SDK (although the entity seems valid for update).

A few things to consider is that if you are able to make this work with simple security roles then it would be simpler to configure the forms using security roles and you would not need this work-around. Consider as well whether you really need multiple forms or you can have other approaches such as JavaScript to hide/show sections depending on the type of record. I have posted some guidance regarding the different options available: http://gonzaloruizcrm.blogspot.ca/2014/07/different-entity-flavours-new-entity.html