You’re offline. This is a read only version of the page.
190
Hi All,
Good Morning.
I was wondering if there is general standard way for documenting dynamics 365 CE customization implemented, which gives a conceptual idea similar to high level design documentation.
Thanks and Regards
Venkatesh
Hi Everyone,
I came across the following link which helps in documenting also
regards
Venkatesh G
Hi Everyone,
Thank you for your valuable response and all responses have some or many point to be considered while documenting.
The contents for documenting will also depend on the level of customization that needs to done.
Many be for developing the product based on the dynamics 365 apps may need more comprehensive documents.
Thank you again
Venkatesh G
As far as I understand your question, you want to keep track D365 customization in the system. To do that I would also suggest to use Azure Devops and visual studio solution first to maintain your code and work items, deployment etc.
In addition you should maintain Datamodel document for the entities and field , for that you can download plugins tools from XRMToolBox. You can have use case documents and then HLD, LLD or technical design documents where you can update time to time about your customization.
And the most important things use Solution and bring all your customization there to track what you did. It would be more better if you can export solution and track customization.xml in the Azure Devops in daily basis. By which you can easily track the changes you done in dynamics 365.
For customization best practices you can follow my article -
https://goutamdascrm.wordpress.com/2018/12/31/performance-improvement-check-list-for-dynamics-365/
The following best practices can help you customize and extend Dynamics 365 Customer Engagement (on-premises).
Best practices for Dynamics 365 Customer Engagement (on-premises)
The Microsoft Dynamics 365 Customer Engagement (on-premises) patterns & principles for solution builders white paper download provides guidance specifically about building solutions using Dynamics 365 for Customer Engagement.
Using custom entities and attributes
Always use the entity name to refer to entities in code and queries. Do not use the object type code (also referred to as entity type) code because the integer value varies for custom entities in different organizations.
Save space on your server by using these techniques:
Create custom attributes for existing entities instead of creating a new entity.
Rename existing entities to make the entities more meaningful.
When should you customize an entity?
Customize a system entity, such as the opportunity entity, instead of replacing it with a new custom entity so that you can use the any built-in features in an existing entity.
When to use plug-ins vs. workflow?
As a developer who is interested in extending or customizing Dynamics 365 Customer Engagement (on-premises), you can choose from several methods to perform your tasks. In addition to adding client-side JavaScript code to a form or adding custom ASP.NET pages, you can write a plug-in or create a custom workflow by using the web interface that calls a custom workflow activity. How do you decide when to use a plug-in and when to use a workflow? The technology that you use depends on the task that you have to perform and who will author the customization.
For example, you must use a synchronous plug-in real-time workflow if you want to execute custom code immediately before or after the core platform operation executes and before the result of the operation is returned from the platform. You cannot use an asynchronous workflow or asynchronous plug-in in this situation because they are queued to execute after the core operation finishes executing. Therefore, you cannot predict when they will run. If you want to add custom functionality to Dynamics 365 for Customer Engagement, workflows, custom workflow activities, and plug-ins are supported, but custom XAML workflows are not.
Evaluate these technologies and select the one that best suits your business objectives after you consider the deployment, performance, and maintenance concerns of your plug-in or workflow solution.
What type of workflow is better?
From a performance perspective, is it better to create a single long workflow or is it better to have multiple child workflows and call them in one parent workflow? The child workflow approach achieves lower throughput, but it is more manageable if you frequently change your workflow definition. Compilation overhead is not a major concern because the workflow is compiled only during publishing. However, Dynamics 365 Customer Engagement (on-premises) incurs overhead when it starts each workflow instance. The overhead occurs when all entities that are used in the workflow are retrieved and the child workflow is started in a two-step process that includes a 'Workflow Expansion Task' and the actual workflow instance. Therefore, for maximum throughput, use a single long workflow.
How should you mark your custom workflow activity as completed?
The return value from the Execute method is used by the workflow runtime to mark the activity as “completed.” You should use return base.Execute(executionContext) unless the activity bypasses base class functionality. Avoid returning ActivityExecutionStatus.Closed. More information: ActivityExecutionStatus Enumeration
How should you report exceptions in custom workflow activities?
You should throw an InvalidPluginExecutionException in your code. This error will be shown in the workflow instance form.
Can you define custom entities that are specific to business units?
Custom entities have privileges for each security role but not for each business unit. To define custom entities that are visible only to specified business units, you must create different security roles for each business unit and grant privileges to the custom entity in the appropriate role.
I hope this helps!
Ruskin | Check out the blog Microsoft Power BI vs Tableau
Hi,
As there can be varying best practices from organization to organization, here are some of the key points I'd like to put forward -
1. Assuming your organization has DevOps and you use to commit your code. Prepare Developer Document, Approach Document, Change Request Document and Business Requirement Document in Word format. The ones which have well indexed sections covering flowcharts and technical aspects of D365 like Plugin information, License information, Workflows, Fields and Forms created, Web Resource information etc. Anything you did custom should be added.
2. An Excel based Test case document to maintain while your customization are in progress. You can share the same with the client and even ask them to test themselves and add their own test cases. Add a status to each test case to filter and see at glance, which ones are due or need to be fixed.
3. If you are an advanced User, use Work Items in Visual Studio for your project and maintain the same in DevOps using Visual Studio. Using Using Boards in DevOps is also a superb way to track progress.
4. Make sure these documents are in SharePoint/OneDrive and are always synced so that you don't lose them or have different copies in your teams.
Hope this helps.
Hi partner,
If you want to find some documentation about CE customization development, you could refer to the following links.
https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/overview
https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/customize/overview
If you want to track your own customization comments and plan, then you could make some notes :-)
And you could ask any questions you meet about your customization in D365 CE in this community.
Best Regards,
Leo
#1
Siv Sagar
149
Super User 2025 Season 1
#2
Muhammad Shahzad Sh...
61
Most Valuable Professional
#3
Daivat Vartak (v-9d...
53
Super User 2025 Season 1
Share
Report
All responses (
Answers (
