Dynamics 365 Development Best Practice Guide

Adding a prefix to solution components that’s relative to you or your organization enables users to quickly identify who created or customized each component.

Customizations created within default solutions cannot be exported or distributed to other environments. In addition, the default solutions use their default publisher, which results in an unspecified/uncontrolled publisher being assigned to components. To avoid these issues, create custom components (e.g., entities, web resources, modern apps, processes, security roles) within custom solutions. If you want to customize out-of-the-box (OOB) components, add them to the custom solution before customization.

Adding detailed descriptions to entities, forms, views, fields, and processes prevents confusion and enables fellow developers to easily identify what the component is for.

Unmanaged solutions can be used to reconfigure the system or set up a new instance if the development environment fails. Managed solutions must be used to deploy customizations in higher environments (QA, pre-production, and production).

Ribbon workbench imports entire solutions, recreates each entity ribbon, and then publishes them. Fewer entities reduce ribbon update time.

Duplicate field names may cause an error while importing data, or confuse users creating personal views, Power Automate flows, and more.

Choose a data type that accurately reflects the data you want to store. If your data contains null values, ensure the data type you select supports null values.

For example: If time is not required for a date, then choose the “Date Only” field data type. Or, if a field allows only two values without any default value, then choose the “Option Set” data type.

This prevents the user from creating records with duplicate field values or combination of field values.

Warning: Once the key is deployed to the managed environment, it cannot be deleted.

This prevents users from selecting unrelated options from recent searches.

For example: If the lookup fields are ‘State’ and ‘City’, disable most recently used items for ‘City’. If not disabled, users may be able to select a city from recent searches irrelevant to the selected state.

Enable field mapping to auto-populate field data from a parent record when a child record is created (common for sub-grids).

On quick create forms, the Save & Close button does not wait for asynchronous function calls to complete (e.g. retrieve record WebAPI). If possible, remove asynchronous calls when saving quick create forms and instead execute the calls upon form load, or upon change of field values.

Use JavaScript method addOnChange to bind field onChange events instead of binding it from form properties. This helps you programmatically gain control over field events.

Using special characters for view names may cause issues when importing from Excel.

Optional fields may not have data and may increase the size of the grid to accommodate empty cells.

If you add a parent column to sub-grid views, the same value will be shown for all related records.

For example: If a state entity is added as a sub-grid in a country entity, don't add a country column in sub-grid view of state, as it will be the same for every country record.

Adding icons for status, gender, rank, profit, loss, etc. enables users to quickly identify fields.

This ensures consistency in information available for records across both states.

Use the app’s URL suffix to access the app instead of the app’s globally unique identifier (GUID). Using the URL suffix is more user-friendly.

Instead of executing moveNext() and movePrevious() operations from scripts, consider updating custom fields (such as status or gender) directly from scripts. This action activates predefined background workflows, plug-ins, and Power Automate flows linked to the Business Process Flow (BPF) entity, updating the active BPF stage.

This ensures JavaScript methods are unique and prevents collisions between identifiers.

This ensures the web resource references are environment independent, as absolute path references include the environment name.

For example: use an HTML page to reference a JavaScript library.

This saves time by enabling developers to quickly reference and reuse common code.

ExecutionContext is a parent object of FormContext, which enables not only form event handlers, but grid event handlers also using GridContext.

This ensures high performance and easy maintenance of code related to custom filtration of lookup fields.

Use Xrm.Constants to access constants like attribute required levels (e.g., none, required, recommended), attribute types (e.g., Boolean, date/time, lookup), and form notification levels (e.g. error, warning).

Use Xrm.Navigation.navigateTo to open forms (entity record, entity list or HTML web resource) as a modal dialog instead of using Xrm.Internal.openDialog or jQuery custom dialog frameworks which are either deprecated or unsupported.

Debugging a JavaScript web resource in console often requires re-writing code. Debugging from browser tools is faster than using external tools.

For example: To retrieve current record data from Xrm.WebApi, use Chrome DevTools’ Run Snippet feature, which has access to the page's JavaScript context and can run on any page (Firefox DevTools has a similar feature called Scratchpad).

If context.depth is not used, it causes infinite recursive plug-in calls.

Instead of directly updating a case entity like service.Update(case), create a new entity using Entity temp = new Entity('case'), temp['x'] = 'value', service.Update(temp)). This creates a new instance with required fields only, which avoids unnecessary field updates and effort.

All other helper functions should be declared as private to reduce code duplication and improve performance.

Creating separate files improves code readability.

Microsoft Dynamics CRM plug-ins have a maximum plug-in size. Exceeding that limit prevents remaining plug-ins from being imported.