Customising Dynamics 365

One of the aspects of Dynamics 365 that quickly becomes obvious to even the casual user is that there are a multitude of different ways that it can be customised and functionality added.

Each of the approaches listed below overlaps to some extent, and each has various pros and cons which an experienced consultant will consider before recommending a particular solution.

• Plugins: written in C#/.Net and execute on the server and execute when records are created or updated (plus various other less used options).
• Workflows, used to schedule a series of steps that take place on demand or in response to some event, such as an update to a field.
• Custom workflow steps, similar to plugins but execute in the context of a CRM Workflow process.
• Azure integrations between the CRM server and Azure.
• Actions, a special kind of workflow that can be invoked on the CRM server by a web request.
• Power automate flows which are part of the power platform.
• Power apps: Model or Canvas apps.
• JavaScript customisations on CRM web forms
• Typescript PCF custom controls
• Business Rules
• Business Process flows
• Calculated and Rollup fields.
• Customising fields and layout of forms. Custom entities.

In choosing any particular approach, a number of factors should be considered: -

• Performance: Plugins and custom workflow steps come at the top of this list, CRM workflows somewhere in the middle with Power flows bringing up the rear.
• Immediacy. When a user updates a form, they may expect related fields on the form to update to new values immediately. They may expect fields to update immediately on saving. If fields are updated by an asynchronous server side process the new values may only become visible when a user manually refreshes the form (which users tend not to like!)
• Ease of creation: this depends very much on who is doing the creation.
  For a functional consultant or “citizen developer” this can be business rules, business process flows, calculated fields and rollups or power automate and power apps.
  Workflows are almost as accessible to most users.
  For hard core .Net/CRM/C# developers a plugin or custom workflow step can often be an easier approach, and the same applies to Javascript form customisations and Typescript PCF controls.
  Those with a high degree of Azure experience may also tend towards this approach
• Long term maintenance: this is the question of how we control what is developed and deployed to our production environment.
  If we have changed a feature, can we tell how it has been modified from the last release?
  How easy is it to revert to an earlier (working) version?
  Who made these changes, why were they made and how were they tested? If something is now working, how do we debug the problem?
  Plugins, custom workflows steps, PCF controls and Javascript score highly here as the source code and CI/CD pipeline can all be managed in a code repository (azure devops or github).
  The other customisation approaches can be difficult to manage, as they are hard to capture for version control, and even when they are captured it is then hard to determine what has changed in any particular version.
• Large numbers of workflows, Power automate flows, or business rules can create their own problems in managing, validating, testing and deploying this functionality in a consistent manner.
• Devops integration. If you are not using devops to manage your CRM deployments then you should be. Period.
  Devops can ensure that components are built, tested and released in a consistent manner.
  Many of the code components: plugins custom workflow steps and PCF controls are easy to manage.
  Managing the more “click and feel” components (meaning almost anything that can be in a solution) can be more of a challenge, but is still achievable through use of managed solutions.
• Testing. This is a larger topic, but for unit testing of c# code components there is a lot that can be achieved using libraries such as FakeXrmEasy with C# plugins and code activities (and any .Net code that interacts with CRM SDKs)
  The plugin pipeline as a whole can be tested using .Net/SDK code to give a baseline for how it should behave.
• Typescript PCF controls also lend themselves to unit testing.
  Javascript customisations can be unit tested, but are more challenging.
  Unit testing the other components: Power automate flows, power apps, BCF flows, business rules, CRM workflow processes lies somewhere between the very difficult to impossible. In these cases testing will almost always rely on manual approaches.