When configuring Microsoft Dynamics solutions, implementing best practices is crucial for achieving a scalable, maintainable, and secure system. Following these expert guidelines not only ensures compliance with industry standards, but also enhances overall solution performance. By adhering to best practices in Microsoft Dynamics, consultants can effectively design and implement systems that grow with the business, allowing for easy adjustments and feature additions. This approach minimizes the risk of data breaches and unauthorized access, safeguarding sensitive information. Embracing these best practices ultimately empowers organizations to optimize operations and secure a competitive edge in today’s dynamic market.
Using best practices when configuring Microsoft Dynamics solutions is essential for ensuring that the solution is scalable, maintainable, and secure. Best practices are a set of guidelines that have been developed over time by experts in the field and are based on their experience and knowledge. By following these guidelines, consultants can ensure that the solution is designed and implemented in a way that meets the needs of the business and is aligned with industry standards.
Here are some reasons why it’s valuable for consultants to abide by best practices when configuring Microsoft Dynamics solutions:
- Scalability: Best practices ensure that the solution is designed in a way that can be scaled up or down as needed. This means that the solution can grow with the business and adapt to changing needs without requiring a complete overhaul.
- Maintainability: Best practices ensure that the solution is designed in a way that is easy to maintain. This means that consultants can quickly identify and fix issues, make changes to the solution, and add new features without disrupting the existing functionality.
- Security: Best practices ensure that the solution is designed in a way that is secure. This means that the solution is protected against unauthorized access, data breaches, and other security threats.
By following best practices, consultants ensure that the solution is designed and implemented in a way that meets the needs of the business, is aligned with industry standards, and is scalable, maintainable, and secure. This can help businesses achieve their goals, improve their operations, and gain a competitive advantage in the market.
Methodology
Creation & Activation
Adhering to good configuration practices is crucial in the design and implementation of Microsoft Dynamics 365 solutions. Consistent, clear, and thoughtful configuration not only enhances the maintainability and scalability of the software but also improves user experience and productivity. Every item created for the D365 Integration is to follow the below formatting template.
By following the guidelines outlined in this document, you can ensure that the various components of your Dynamics 365 environment are easily identifiable, logically organized, and purposefully constructed. This reduces confusion, prevents conflicts, and enhances the efficiency of your development process. More importantly, it fosters better collaboration among teams, as it provides a clear understanding of the system architecture and functionality.
Therefore, these practices are fundamental principles that contribute to the successful deployment and effective utilization of your Dynamics 365 solutions.
Deactivation & Deprecation
Continuing good configuration practices by correctly deprecating outdated and obsolete components is essential for maintaining a healthy, efficient, and secure Microsoft Dynamics 365 environment. As business needs evolve, certain components may become redundant or obsolete. Without proper deprecation, these components can clutter the system, making it difficult to navigate and manage.
More importantly, they may cause confusion for users and developers, leading to inefficiencies and potential errors. Furthermore, outdated components pose security risks when they are not updated or patched regularly. By correctly deprecating and removing these components, you can streamline your system, enhance its performance, reduce potential security vulnerabilities, and ensure that your Dynamics 365 environment remains robust and fit for purpose. Proper deprecation practices also facilitate smoother upgrades and migrations, contributing to the long-term sustainability of your system.
All items in the system that need to be removed will be deactivated (if applicable) and given a prefix for the Display Name of the component that reads:
“zzz_Deprecated_….”
This prefix will determine if items are to be active or not. The assumption is, if an item is Deactivated, and does not have the above “deprecated prefix”, it needs to be reactivated. The reverse scenario is also true.
Components
Publishers
Description: A publisher in Dynamics 365 refers to the party who is responsible for the development and distribution of a solution or app. Every component will have a designated publisher. The publisher of a component is inherited by the solution’s publisher that the component is created in.
Publishers act as a way of segmenting and organizing different sets of components and solutions, which can simplify management, improve clarity, and assist in version control. For instance, different departments or teams within an organization may use distinct publishers for their specific solutions, facilitating easier tracking and isolation of their work. Additionally, third-party solutions often have their own publishers, allowing for clear differentiation between in-house and external components.
Build Guide: Navigate to the ‘Settings’ area, select ‘Customizations’, and then ‘Publishers’. Click ‘New’ and fill in the required details such as the publisher’s name, prefix, and description.
Best Practices: Always set a unique prefix for your publisher to ensure there are no conflicts with other solutions or apps. Don’t create a new publisher unless you are bringing on a new division with a new set of entities, fields or other components that you want to segregate those with a different entity prefix. If so, stick with an option value prefix that is consistent across the publishers if possible
Schema Naming: Use a clear, descriptive name that reflects the publisher’s identity. The name usually corresponds to the organization or individual responsible for the solutions or apps.
- Desired Display Name Format: Developing Organization Name
- Desired Schema Name Format: Mirror the Chosen Prefix
Solutions
Description: A solution is a container for storing the components needed to extend Dynamics 365. Always create a solution for a specific purpose, and only include the necessary components. Keep solutions small and manageable. Solutions differentiate the business processes, or release waves.
Build Guide: To create a solution, navigate to the Solutions page, click ‘New’, fill in the required fields, and save.
Best Practices: As a best practice, the schema name should be all lowercase and the components that make up the schema should be separated by an underscore.
As an example, an organization may decide to have a solution for the Market to Quote Business Process (to handle all related components), a Customer Claims Business Process, etc. Conversely, solutions can be organized by release wave. For example, you can have a “September 202X Release”, “October 202X Release”, etc. and the solution would contain all components apart of a wave release (spanning business processes).
Organizations may decide to do a combination of the two methods and have an “Apps September 202X” , “Flows September 202X” , etc.
Schema Naming: Use a clear, descriptive name that reflects the solution’s purpose, prefixed with your organization’s abbreviation.
- Desired Display Name Format: “Publisher Prefix” “Component Type” “Target Release Date”
- Desired Schema Name Format: publisherprefix_componenttype_targetreleasedate
Apps
Description: Apps in Dynamics 365 are modular and focused, driving user productivity through easy navigation and use.
Build Guide: Navigate to the ‘My Apps’ area, click ‘Create New App’, fill in required details, choose components to include, and save.
Best Practices: As a best practice, the schema name is all lowercase and the components that make up the schema should be separated by an underscore. Only include the entities, dashboards, and forms that are necessary for the app’s function.
The customer is responsible for setting the Display Name as it displays in the app to the end user. Be sure that the name adequately represents the business process.
Schema Naming: Use a short, descriptive name which reflects the app’s purpose and function. It should provide enough context for developers to understand what the app does. Normally, the schema should reflect the Display Name (but follow the correct format)
- Desired Display Name Format: Meet Client Specifications
- Desired Schema Name Format: publisherprefix_displayname
Chatbots
Description: Chatbots are AI programs that interact with users in a natural language format.
Build Guide: Use Power Virtual Agents to create chatbots. Create a new bot, define topics and entities, and set up conversation flows.
Best Practices: As a best practice, the schema name should be all lowercase and the components that make up the schema should be separated by an underscore. Make sure your bot covers all necessary topics, and regularly review and refine its performance based on user interactions.
Schema Naming: Use a name that clearly reflects the bot’s function.
- Desired Display Name Format: Meet Client Specifications
- Desired Schema Name Format: publisherprefix_displayname
Choices
Description: Choices are to create a list of options for a field in Dynamics 365.
Build Guide: Navigate to solution explorer, select the table, select the column, and add choices.
Best Practices: As a best practice, the schema name should be all lowercase and the components that make up the schema should be separated by an underscore. Clearly label each choice and limit the number of choices to avoid overwhelming users.
Schema Naming: Use descriptive, straightforward names for your choices.
- Desired Display Name Format: Meet Client Specifications
- Desired Schema Name Format: publisherprefix_displayname
Power Automates
Description: Part of Power Automate, cloud flows automate tasks and processes in Dynamics 365 and other applications.
Build Guide: Use Power Automate to create a new flow, select your trigger, and add actions.
Best Practices: All flows should try to be contained in a single solution for every release. Flows are complex with how they integrate into Dynamics and it is often desirable for them to be deployed in an UNMANAGED solution (unlike all other components), incase there was a need for an immediate update.
As a best practice, the display name will incorporate three components and each component is separated by a bar (example: | ). The three components that are included in every flow name are:
- Trigger Table: For Dataverse Actions, include the table that the trigger step is looking at. If the trigger is not related to a Dataverse table, still provide a 1 word description of the trigger step.
- Examples could be “SharePoint”, “HTTP Request”, etc.
- If the flow is a Child Flow, replace the Trigger Table component with “Child Flow”
- Triggering Event: Explain what occurrence will cause the flow to run in 1-4 words.
- Examples include “Open Task is Closed”, or “Opportunity Temp is Warm”, etc.
- Action: Explain what the flow will be doing in 3-7 words. You can explain the final action or all of the actions in total as you seem fit.
Some examples are: “Send Case Created Email” , “Reassign Lead and Notify New Owner” , etc.
Schema Naming: The Schema Name will mirror the Display Name for Cloud Flows.
- Desired Display Name Format: Triggering Table | Triggering Event | Action
- Desired Schema Name Format: Same as Display Name
Column Security Profiles
Description: These allow you to set permissions on specific data columns to control who can access and view the data.
Build Guide: Navigate to security settings, select ‘Field Security Profiles’, click ‘New’, and set up the desired permissions.
Best Practices: As a best practice, the display name should capture the Publisher Prefix and the Group in which the Column Security Profile will belong to, separated by a hyphen. Ideally, these groups should mirror the Security Groups defined in the system.
To show a few examples: “HSL – Business Development Managers” , “HSL – Lead Assignment Group” , etc.
Schema Naming: Use a name that reflects the data and access level. The schema name is inherited from the display name.
- Desired Display Name Format: “Publisher Prefix” – “Group Name of Users who will have the Profile”
- Desired Schema Name Format: Same as Display Name
Dashboards
Description: Dashboards provide a consolidated view of various data types and can display data from multiple entities.
Build Guide: Navigate to the dashboard area, click ‘New’, select your layout, and add components.
Best Practices: The customer is responsible for setting the Display Name as it will display in the app to the end user. Be sure that the name adequately represents the function of the data displayed.
Schema Naming: Use a clear, descriptive name that reflects the dashboard’s purpose.
- Desired Display Name Format: Meet Client Specifications
- Desired Schema Name Format: Same as Display Name
Duplicate Detection Rules
Description: This feature prevents duplicate records in Dynamics 365 by setting rules that the system checks when records are created or updated. Note: The rules can only be applied to active records; they do not apply to inactive or closed records. Also, the system allows a maximum of five published duplicate detection rules per entity. Each rule can have a maximum of 450 conditions, but no more than 10 involving different fields.
Additionally, record matching during rule creation or de-duplication process is case-insensitive and not accent-sensitive. Importantly, duplicate detection is not enforced when records are created or updated programmatically using the SDK.
Build Guide: Navigate to ‘Data Management’, click on ‘Duplicate Detection Rules’, select the entity, and define the rule.
Best Practices: As a best practice, the display name should incorporate two components and each component should be separated by a bar (example: | ). The two components that are included in every Duplicate Detection Rule name are:
- Base Record Type: Every Duplicate Detection Rule will have a defined “Base Record Type”. This is effectively the table that the rule will look at for comparison. The name of the table selected should be in the name of the rule.
- Triggering Fields: Briefly explain what fields are in the Duplicate Detection Rule. If there are too many to list, please consolidate.
Schema Naming: Use a clear, specific name that reflects the rule’s purpose.
- Desired Display Name Format: Base Record Type (Table) | Triggering Fields
- Desired Schema Name Format: Same as Display Name
Process Workflows
Description: Workflows automate business processes by performing actions based on defined criteria.
Build Guide: Navigate to the processes area, click ‘New’, select ‘Workflow’, and define your steps.
Best Practices: As a best practice, the display name should incorporate three components and each component should be separated by a bar (example: | ). The three components that each flow name includes are:
- Trigger Table: Include the table that the workflow step is looking at.
- Triggering Event: Explain what occurrence will cause the workflow to run in 1 word. This is determined by which option is selected for when the Automatic Processes is triggered.
- The options available are to be used in a name are “Created”, “Updated”, “Assigned”, “Deleted”. You can use multiple of these option if necessary (separated by “and”).
- If there are none selected and this workflow will only be run as an on-demand process, enter “On Demand” as the Triggering Event.
- Action: Explain what the workflow will be doing in 3-7 words. You can explain the final action or all of the actions in total as you seem fit.
Some examples can be: “Lead | Created | Set Temperature to Warm” , “Account | Created and Updated | Set Status to Deactivated” , “Contact | On Demand | Update Specific Field” , etc.
Schema Naming: The Schema Name will mirror the Display Name for Workflows.
- Desired Display Name Format: Triggering Table | Triggering Event | Action
- Desired Schema Name Format: Same as Display Name
Business Process Flows
Description: These guide users through specific business processes, ensuring that users follow the same steps every time.
Build Guide: Navigate to the processes area, click ‘New’, select ‘Business Process Flow’, and define your steps.
Best Practices: The customer is responsible for setting the Display Name as it displays in the app to the end user. Be sure that the name adequately represents the function of the data displayed.
Schema Naming: Use a clear, descriptive name that reflects the dashboard’s purpose.
- Desired Display Name Format: Meet Client Specifications
- Desired Schema Name Format: Same as Display Name
Reports
Description: Reports are to display, organize, and analyze data from Dynamics 365.
Build Guide: Navigate to the reports area, click ‘New’, and use the Report Wizard to define your report.
Best Practices: The customer is responsible for setting the Display Name as it displays in the app to the end user. Be sure that the name adequately represents the function of the data displayed.
Schema Naming: Use a clear, descriptive name that reflects the dashboard’s purpose.
- Desired Display Name Format: Meet Client Specifications
- Desired Schema Name Format: Same as Display Name
Tables
Description: Tables in Dynamics 365 are to model and manage business data.
Build Guide: Navigate to solution explorer, click ‘New’, select ‘Table’, and define your columns and data types.
Best Practices: As a best practice, the schema name should be all lowercase and the components that make up the schema should be separated by an underscore.
Be sure that the Display Name is SINGULAR. If the Display Name ends with the letter “s” it can cause issues when other components try to interact with the table. The system will automatically create a “Plural Version” of the Display Name.
Schema Naming: Use a clear, descriptive name that reflects the data stored in the table. The Schema Name will contain the Developing Org Prefix followed by the Display Name without capital letters and spaces. For example, if you had a custom table with the Display Name: 3rd Party Contact, the schema should be: hsl_3rdpartycontact.
If the table is an activity table, be sure to include “_activity” at the end of the Schema Name.
- Desired Display Name Format: Meet Client Specifications
- Desired Schema Name Format: publisherprefix_displayname or publisherprefix_displayname_activity
Table Columns
Description: Columns in a table are to store and categorize data.
Build Guide: To create a column, navigate to the table you want to modify, select ‘Columns’ and click ‘New’. Define your column properties and save.
Best Practices: As a best practice, the schema name should be all lowercase and the components that make up the schema should be separated by an underscore. The schema will also contain the column type at the end of the Schema Name. Follow the chart below to determine the suffix that is appropriate:
| Column Type | Schema Name Suffix |
| Text, Email, Phone Number, Text area, Ticker symbol | _text |
| Rich text | _richtext |
| URL | _url |
| Whole number, Decimal, Float, Language Code | _number |
| Duration | _duration |
| Time zone | _timezone |
| Date and time, Date only | _date |
| Lookup, Customer | _lookup |
| Choice, Yes/No | _choice |
| Currency | _currency |
| Autonumber | _autonumber |
| File | _file |
| Formula | _fx |
Schema Naming: Use a clear, descriptive name that reflects the data the column will hold. The Schema Name will mirror the display name and include the appropriate prefix and suffix.
- Desired Display Name Format: Meet Client Specifications (must be singluar)
- Desired Schema Name Format: publisherprefix_displayname_suffix
Table Forms
Description: Forms are to present and collect data related to a specific table.
Build Guide: To create a form, navigate to the table, select ‘Forms’ and click ‘New’. Design your form layout and save.
Best Practices: The customer is responsible for setting the Display Name as it displays in the app to the end user. Be sure that the name adequately represents the function of the data displayed.
Schema Naming: Use a clear, descriptive name that reflects the dashboard’s purpose.
- Desired Display Name Format: Meet Client Specifications
- Desired Schema Name Format: Same as Display Name
Table Views
Description: Views provide a way to present a filtered list of records from a table.
Build Guide: To create a view, navigate to the table, select ‘Views’ and click ‘New’. Define your filters and sorting and save.
Best Practices: The customer is responsible for setting the Display Name as it will be readily displayed in the app to the end user. Be sure that the name adequately represents the function of the data displayed. It is common for customers to want the views to be in a particular order. Currently out-of-the-box, the app sorts them alphabetically.
If you want to change the order of the views, you will need to manipulate the names to begin with chronological numbers following this format: “01 – View Name”, “02 – View Name”, “03 – View Name”, etc.
Schema Naming: Use a clear, descriptive name that reflects the dashboard’s purpose.
- Desired Display Name Format: Meet Client Specifications
- Desired Schema Name Format: Same as Display Name
Table Charts
Description: Charts provide a visual representation of table data.
Build Guide: To create a chart, navigate to the table, select ‘Charts’ and click ‘New’. Define your chart type and data sources and save.
Best Practices: The customer is responsible for setting the Display Name as it displays in the app to the end user. Be sure that the name adequately represents the function of the data displayed.
Schema Naming: Use a clear, descriptive name that reflects the dashboard’s purpose.
- Desired Display Name Format: Meet Client Specifications
- Desired Schema Name Format: Same as Display Name
Table Dashboards
Description: Dashboards display data from multiple tables in a single location.
Build Guide: To create a dashboard, navigate to the dashboard area, click ‘New’, select your layout, and add components.
Best Practices: The customer is responsible for setting the Display Name as it displays in the app to the end user. Be sure that the name adequately represents the function of the data displayed.
Schema Naming: Use a clear, descriptive name that reflects the dashboard’s purpose.
- Desired Display Name Format: Meet Client Specifications
- Desired Schema Name Format: Same as Display Name
Table Business Rules
Description: Business rules apply business logic to table data, without the need for code.
Build Guide: To create a business rule, navigate to the table, select ‘Business Rules’ and click ‘New’. Define your condition and actions and save.
Best Practices: It can often be hard to deliniate the difference between workflows and Business Rules in the Power Apps Maker. Because of this, every business rule will use hyphens ( – ) to separate components (as opposed to bars).
As a best practice, the display name should incorporate three components. The three components that are included in every flow name are:
- Table: Include the table that the business rule exists on.
- Filtering Criteria: Explain what filtering must be met for the business rule to be active in 3-7 words. Examples could be: “Phone is Null”, “Phone Contains Data but Email Null”, etc.
- Action: Explain what the workflow will be doing in 3-7 words. You can explain the final action or all of the actions in total as you seem fit.
Some examples can be “Account – Phone is Null – Require Email” , “Account – Phone Contains Data but Email Null – Require Address” , etc.
Schema Naming: The Schema Name will mirror the Display Name for Workflows.
- Desired Display Name Format: Table – Filter Criteria – Action
- Desired Schema Name Format: Same as Display Name