Skip to main content

Notifications

Dynamics 365 CRM Development Standards - Configuration 2

Overview

This is a series of blogs introducing the Development Standards and Best Practices to help configure and customize CRM to do so consistently, clearly, and meaningfully.

This is the part2 of Dynamics 365 CRM Development Standards - Configuration

1.   Forms

Introduction

Forms provide the user interface that people use to interact with the data they need to do their work. It’s important that the forms people use are designed to allow them to find or enter the information they need efficiently.

There are different types of forms, and each type has a specific functionality or use. These include:

  • Main (the main user interface)
  • Quick Create (rapid data entry)
  • Quick view (to see related data).
  • Card form (a compact view)

Best Practices

1, Before you begin to build forms, it’s worth determining whether you have all the columns necessary to solve your business problem.

2, Hiding form elements is not a recommended way to enforce security. There are several ways people can view all the elements and data in the form when elements are hidden.

3, Keep the number of fields to a minimum

The more fields you have in a form, the more data needs to be transferred over the internet or intranet to view each record.

4, Avoid using synchronous requests Synchronous requests can cause slow page loads and unresponsive forms.

5, Avoid including unnecessary JavaScript web resource libraries
The more scripts you add to the form, the more time it will take to download them. Usually, scripts are cached in your browser after they are loaded the first time, but the performance the first time a form is viewed often creates a significant impression.

6, Avoid loading all scripts in the Onload event
If you have code that only supports OnChange events for fields or the OnSave event, make sure to set the script library with the event handler for those events instead of the OnLoad event. This way loading those libraries can be deferred and increase performance when the form loads.

7, Use collapsed tabs to defer loading web resources
When web resources or IFRAMES are included in sections inside a collapsed tab they will not be loaded if the tab is collapsed. They will be loaded when the tab is expanded. When the tab state changes the TabStateChange event occurs. Any code that is required to support web resources or IFRAMEs within collapsed tabs can use event handlers for the TabStateChange event and reduce code that might otherwise have to occur in the OnLoad event.

8, Set default visibility options
Avoid using form scripts in the OnLoad event that hide form elements. Instead set the default visibility options for form elements that might be hidden to not be visible by default when the form loads. Then, use scripts in the OnLoad event to show those form elements you want to display. If the form elements are never made visible, they should be removed from the form rather than hidden.

9, Keep the number of controls to a minimum.
Within the command bar or the ribbon for the form, evaluate what controls are necessary and hide any that you don’t need. Every control that is displayed increases resources that need to be downloaded to the browser.

10, Use asynchronous network requests in Custom Rules. When using custom rules that make network requests in Unified Interface.

 

Not Recommended

1, Placing all fields under the same tab can slow down page loading. Please consider dividing them into separate tabs.

2, If you determine that auto-save will cause problems with any extensions you’re using, you can disable it for your Organization or Form.

 

2. Attributes/Fields

Introduction

Entities include a set of attributes that represent the data that can be included within each record. Developers need to understand the different types of attributes and how to work with them. The metadata for attributes describes the valid operations and behaviors of different types of attributes.

Best Practices

  1. use lowercase in the Name field. When you enter a Display Name of “Company Name” into CRM, it will automatically generate a Name of “prefix_companyname”.

Not Recommended

  1. Don’t change the attribute’s Display Name dramatically in meaning from the Name.

3. Security Roles

Introduction

A security role defines how different users, such as salespeople, access different types of records. To control access to data, you can modify existing security roles, create new security roles, or change which security roles are assigned to each user. Each user can have multiple security roles.

Best Practices

  1. To control data access, you must set up an organizational structure that both protects sensitive data and enables collaboration.
  2. To ensure that users can view and access all areas of the web application, such as entity forms, the nav bar, or the command bar, all security roles in the organization must include the Read privilege on the Web Resource

 3480.pastedimage1680957848560v1.png

3. Copy an existing role when you create a new one. You can copy from the Sales Manager Role as the base role. Or find an existing role that is closest to your new target role and make changes to the new role.

Not Recommended

  1. Creating a new security role from scratch will cause a lot of problems.
  2. Don’t Rename an existing security role.
  3. Don’t change the default roles. There is no reason to do that.

Please refer to this page for all the content. 

Dynamics 365 CRM Development Standards and Best Practices.

Comments

*This post is locked for comments