Design Considerations for Different Form Presentations

[Applies to: Microsoft Dynamics CRM 2011]

When you design forms in Microsoft Dynamics CRM 2011, you should consider the different ways forms are presented in the application. This topic describes design considerations for the different ways that data defined within FormXml can be displayed. The different form presentations are introduced in the following table.

Form mode Description

Edit

This is the “classic” form that can be used to edit data for all entities that have forms. For more information, see Edit Forms.

Read-optimized

Read-optimized forms are an optional feature to let users decide whether they prefer to quickly view records by using a form that is optimized to load quickly but cannot be edited. Users can quickly switch to the edit mode. For more information, see Read-Optimized Forms.

Updated

Updated forms provide a new user experience for the Case, Contact, Opportunity, Lead, and Account entities. The updated forms are a more advanced type of read-optimized form. The updated form allows for faster loading and allows the record to be edited. For more information, see Updated Forms.

Microsoft Dynamics CRM for Outlook reading pane

The Microsoft Dynamics CRM for Outlook reading pane (preview) provides a read-only view of a record. This view presents a stack of all the sections that are defined in the form. Users can rearrange the sections, and their preferences are preserved. For more information, see Microsoft Dynamics CRM for Outlook Reading Pane Forms.

Mobile

Mobile Express for Microsoft Dynamics CRM uses a simple form that displays a list of controls for attributes. You can decide which attributes to display and change the order of the attributes. For more information, see Mobile Forms.

In This Topic

Edit Forms

Read-Optimized Forms

Updated Forms

Microsoft Dynamics CRM for Outlook Reading Pane Forms

Mobile Forms

Form Scripts in non-Edit Forms

Edit Forms

By default, each entity that has forms will have a form named Information of the type Main. Edit forms are optimized for editing data.

Because edit forms for common and custom entities support the ribbon and have full access to the Xrm.Page object model, edit forms provide the most extensibility options for developers.

This form behaves differently based on the state of the record, the user permissions, and the action that is being performed. The edit form has the following form types that you can determine by using scripts with Xrm.Page.ui.getFormType.

  • 1 = Create

  • 2 = Update

  • 3 = Read Only

  • 4 = Disabled

  • 6 = Bulk Edit

For example, if a user does not have privileges to update a record, the form will use the Read Only form type. Trying to update an attribute value in a read-only or disabled form throws an error. You should always check the type of form to make sure that the actions you want to perform apply to actions possible for each type of edit form. Form event handlers are not enabled for the Bulk Edit form.

Read-Optimized Forms

Read-optimized forms were included in Update Rollup 7 for Microsoft Dynamics CRM 2011. By using read-optimized forms, you can let users decide whether they prefer to view records by using a form that is optimized to load quickly, but cannot be used to edit records. Users can click the Edit button to display the edit form. The read-optimized form improves productivity for users who primarily read records instead of edit records. It also helps prevent unintentional editing of field values.

For Microsoft Dynamics CRM 2011 Update Rollup 12 and Microsoft Dynamics CRM December 2012 Service Update, read-optimized forms have the following changes:

  • When updated forms are enabled, updated forms are displayed instead of read-optimized forms for Case, Contact, Opportunity, Lead, and Account entities. For more information, see Updated Forms.

  • The form navigation pane is displayed so that navigation to related records is possible. The navigation pane can be expanded or collapsed.

  • Read-optimized forms support all kinds of web resources to be added to the form. There is a new check box in the web resource properties labeled Show this Web Resources in Read Optimized form. This check box must be selected for the web resources to display. If the web resource depends on form resources that are not available in a read-optimized form you should not display it.

Some considerations for read-optimized forms:

  • When you enable read-optimized forms, all entities that display a ribbon will use them. You cannot set specific entities to have a default form mode.

  • When the form contains enabled custom form event handlers in the form OnLoad Event, the Tab TabStateChange Event, or the IFRAME OnReadyStateComplete Event, the edit form is displayed instead of the read-optimized form. Because the read-optimized form does not allow for editing data, event handlers for the Field OnChange Event and form OnSave Event events will not cause the edit form to display because they cannot be fired.

    Access to the Xrm.Page object model is limited and can only be accessed by web resources through the parent property. Only the following methods are supported:

    • parent.Xrm.Page.data.entity.getEntityName

    • parent.Xrm.Page.data.entity.getId

    • parent.Xrm.Page.ui.getFormType
      This method returns 11 for read-optimized forms.

  • If your form design depends on form scripts to use resources that are not available for read-optimized forms, see Form Scripts in non-Edit Forms for additional options.

  • When entities have more than one form enabled, read-optimized forms use the form that the user last used.

  • Read-optimized forms will use all field level security and role-based form definitions.

  • Read-optimized forms support IFRAME controls but do not have the same option that web resources have to control whether they should be displayed in read-optimized forms. As long as the content of the IFRAME does not include code that uses the parent property to access the parts of the Xrm.Page object model or the crmForm object that is not present, the IFRAME appears as expected. If the IFRAME cannot display correctly in the read-optimized form mode, use the Visible by default check box in the form editor to configure the IFRAME so that it does not display.

Control Use of Read-Optimized Forms for an Organization

By default, read-optimized forms are not enabled. A system administrator can control whether read-optimized forms are enabled and whether users can decide to enable them. The settings that control whether read-optimized forms are used cannot be included in a Microsoft Dynamics CRM solution. If you prepare a solution that depends on certain settings for read-optimized forms you will need to be prepared to detect the current settings, prepare instructions on how to set the organization’s settings to be compatible with your solution, or prepare some code that will allow an organization installing your solution to adjust the settings to be compatible with your solution.

To control the use of read-optimized forms in your organization

  1. In the Navigation Pane, click Settings.

  2. In the System group, click Administration, and then click System Settings.

  3. In the System Settings dialog box, in the Customization tab and under Form Mode, select either Read-Optimized or Edit as the default mode for viewing forms.

  4. Set the Allow users to select a mode for viewing forms check box to control whether users can decide between the options.

The following table shows the two settings that an administrator can use for the listed options.

Needed outcome Form-mode setting User options for the “Allow users to select a mode for viewing forms” check box

Completely disable read-optimized forms.

Edit

Clear

Enable users to select read-optimized forms as their personal preference.

Edit

Select

Enable users to select the edit form as their personal preference.

Read-optimized

Select

Require all users to use read-optimized forms.

Read-optimized

Clear

You can programmatically control these settings by setting the Boolean attribute values of the organization entity. The following table lists the possible values that you can use to customize the system setting.

System setting Property Description

Form Mode

Organization. UseReadForm

Indicates whether the read-optimized form is enabled as the default setting for the organization entity.

Allow users to select a mode for viewing forms

Organization. AllowUserFormModePreference

Indicates whether users can select a form-mode preference in their personal options.

When the Organization.AllowUserFormModePreference value is set to true, users can make a choice in their personal options to override the organization-wide default setting. This setting is stored in the UserSettings.EntityFormMode attribute, which has the options that are listed in the following table.

Value Label Description

0

Organization default

Use the default mode for the organization entity (no personal option is set).

1

Read-optimized

Use the read-optimized form if the organization provides this option.

2

Edit

Use the Edit form if the organization provides this option.

As a system administrator, you can specify the UserSettings.EntityFormMode for users.

To specify preferences for specific users

  1. Navigate to Settings, and then click Administration.

  2. Click Users.

  3. In the list, select one or more users.

  4. In the right side of the ribbon, use the Form Mode button to select either Read-Optimized or Edit.

Updated Forms

If an organization using Microsoft Dynamics CRM Online has the Microsoft Dynamics CRM December 2012 Service Update, and if the organization has installed the Product Update for sales and service, or if the organization's Microsoft Dynamics CRM Online subscription began after December 2012 the organization will have updated forms for the Case, Contact, Opportunity, Lead, and Account entities. These forms are part of the updated user experience. These forms are not available in an on-premises deployment of Microsoft Dynamics CRM 2011.

Important

If your organization has been updated to Microsoft Dynamics CRM Online Fall ’13, please use the latest version of the SDK. Download the updated SDK package for Microsoft Dynamics CRM 2013 and CRM Online Fall ‘13.

Note

The blog post Customizations in the December 2012 Service Update provides an overview of new elements with the Microsoft Dynamics CRM December 2012 Service Update.

Updated forms are a type of read-optimized form with the following enhanced capabilities.

  • Inline edit controls: Although the updated form is based on the read-optimized form, it allows for editing.

  • Process control: For Lead, Case, and Opportunity entities a process control allows you enter data to move the record through a configurable process.

  • Command bar: Instead of the ribbon, the command bar provides buttons for common actions to be performed on the record or, for users who have appropriate permissions, access to the form editor or to open a process configurator. The command bar also provides a Switch to Classic option that displays the record in the edit form mode.

  • Auto Save: Changes made are automatically saved. For more information, see Auto Save Control for Updated Forms.

  • Web resources: You can add web resources to an updated form. You must select the Show this Web Resource in Read Optimized Form check box for the web resource to display.

  • Partial Xrm.Page : Access more of the Xrm.Page object model than read-optimized forms. For more information, see Access to the Xrm.Page Object Model for Updated Forms.

  • Editable header fields: Fields found in the body of the form are included in the form header and are can be edited there.

  • Quick Create: Related Tasks, Phone Calls, Accounts, Contacts, and Case Resolution records can be created by using controls integrated in the form instead of opening a new window.

  • Bing maps integration: Displays a location based on address data.

For more information, see the help topic Customizing the forms in the new sales process.

With the updated forms, the Case, Contact, Opportunity, Lead and Account entities have a new form named after the name for the entity: the <entity name> form. For example, for the Account entity, in addition to the default Information main form, there will be a second main form named Account. The Information form will display using the updated presentation if the user and organization settings call for the use of the read-optimized form. Otherwise, the edit form is displayed by default. The *<entity name>*form always displays using the updated presentation regardless of settings for read-optimized forms. The following table describes the presentation used for each type of main form and the organization or user’s read-optimized form preferences setting.

  User Setting Organization Setting

Read-Optimized

Edit

Read-Optimized

Edit

Case, Contact, Opportunity, Lead, and Account Entities

Information main form and forms created using the Information form

Updated

Edit

Updated

Edit

<entity name> main form and forms created using the <entity name> form

Always displays updated form presentation

Other Entities

Information main form(s)

Read-Optimized

Edit

Read-Optimized

Edit

Updated forms do not support any type of event handler to be configured in the form definition. If an event handler is applied to these forms they will appear as edit forms. However, a web resource added to the form has limited access to the Xrm.Page object model. For more information, see Access to the Xrm.Page Object Model for Updated Forms.

If you have <entity name> forms but do not want to use them, you can modify the security roles assigned to a form so that it will not be shown. For more information, see Manage Role Based Forms.

Auto Save Control for Updated Forms

Modern applications are moving to an implicit save model. The updated forms introduce this behavior in Microsoft Dynamics CRM Online. Auto save is not configurable. You cannot disable it or change the behavior. There is no save button. The auto save control appears in the bottom right area of the updated form and has the following behaviors:

  • When creating a new record there is a Create button in the command bar.

  • Auto save does not apply until the record is created.

  • After the first edit of the form, auto save occurs every 30 seconds.

  • Auto save retrieves any changes to the record and displays them without reloading the form.

  • Only data that has been changed since the last save are saved.

  • The field currently being edited is not saved.

  • Command bar actions like New, Close, or Qualify saves the record.

  • Closing the form saves the record.

Note

Each time auto save occurs, it is considered an update to the record. Plug-ins, workflows, and auditing of records will treat each update as a separate event. Developers and creators of workflows need to consider the impact this will have on the business logic included in their plug-ins and workflows. Rather than triggering business logic on each update, you should include conditions to check the values of specific fields in the update to initiate your logic so that they won’t occur indiscriminately with each update.

Access to the Xrm.Page Object Model for Updated Forms

If any form event handler is added to a form that would display using the updated form presentation, the form will revert to use the edit form presentation. The only access available to the Xrm.Page object model is through web resources that can be added to a form. A web resource can access the form using the parent property. You can access the Xrm.Page object using parent.Xrm.Page.

Except for the Xrm.Page.ui.getFormType method, the Xrm.Page.ui object is not available in updated forms. This includes the Controls Collection for attributes.

Web resources load asynchronously when the form loads. As a performance enhancement for updated forms, parts of the Xrm.Page object are loaded asynchronously. As a result, some Xrm.Page objects that scripts in your web resources depend on may not be available when a script runs. There is no public event that is fired to indicate that the parts of the Xrm.Page object are available. To counter this, scripts in your web resource should implement a strategy to query the Xrm.Page object to determine whether the objects you want to use are available before you use them. For more information, see Sample: Detect When an Object is Available Using Script in a Web Resource and an Updated Form.

Microsoft Dynamics CRM for Outlook Reading Pane Forms

The Microsoft Dynamics CRM for Microsoft Office Outlook reading pane is based on the formXML for the default form for an entity. It is a read-only view of data and does not display web resources or IFRAME controls. If your form design depends on form scripts to use resources that are not available for Outlook Reading Pane Forms, see Form Scripts in non-Edit Forms for additional options.

Mobile Forms

The forms used by Mobile Express for Microsoft Dynamics CRM are a simple list of fields. By default, there is a single form named Information with Form Type of Mobile. You can add mobile forms, set a default form and manage which security roles will view each form just like with the Edit Form. However users cannot switch forms.

There are no opportunities to use scripts in Mobile forms. If your form design depends on form scripts to use resources that are not available for Mobile Forms, see Form Scripts in non-Edit Forms for additional options.

Form Scripts in non-Edit Forms

You can use form scripts in an edit form to create dynamic forms. Form scripts are frequently used to do the following:

  • Control visibility of form elements.

  • Display calculated values.

Without access to ways for scripts to control visibility, forms rely on the default visibility values that are set in the form definition to control which form elements are displayed. Each form tab, section, and field has a Visible by Default property that controls whether the default setting is to display the element in both edit and read-only forms. This property corresponds to the visible attribute, which is found in the <tab> (FormXml), <section> (FormXml), and <cell> (FormXml) elements.

When you want to hide specific elements, instead of using form scripts in the form OnLoad event, you can hide elements as the default setting. Then use the client-side setVisible method to show form elements, as appropriate, in the edit form. Alternatively, you can use role-based forms to control the data that users can view. For more information, see Manage Role Based Forms.

If your forms rely on form scripts to display calculated values, they can perform these calculations by using a synchronous plug-in that runs in an isolated environment (sandbox). Apply the plug-in only when a record is retrieved so that a client-side calculation is not required.

If the form script is only calculating values that are already in the form, the form can more quickly perform the calculations by using a plug-in. If the calculated field requires retrieval of related records, you can expect that this additional processing time is reflected in the time that is required to load the form. To avoid the additional loading time, you can design the form to be viewed in edit mode and to perform calculations asynchronously by using JavaScript.

If the form cannot perform the calculation by using a plug-in, consider setting the visibility for the form fields so that they do not automatically display in the non-edit form. You can then make the fields visible by using a form OnLoad event-handler script in the edit form.

See Also

Concepts

Customize Entity Forms
Create New Entity Forms
Manage Role Based Forms
Change Form Navigation
SystemForm (System Dashboard) Entity Messages and Methods
SystemForm (System Dashboard) Entity Metadata
SystemForm (System Dashboard) Entity OptionSet Attribute Metadata

Other Resources

Update Rollup 7 for Microsoft Dynamics CRM 2011 is available (KB Article)
Read-Optimized Forms (Resource Center Article)

Microsoft Dynamics CRM 2011
Send comments about this topic to Microsoft.
© 2013 Microsoft Corporation. All rights reserved.