Every so often I am asked a question or see on a forum post similiar to this; “What is the best practice, a workflow or a plugin?” Or “Should I use JavaScript, or could I use Business Rules for this?”
For someone just starting out, its hard to determine what option/feature/tool to use, let alone knowing what options are even available!
Even then, most requirements can be handled in different ways, and the pros and cons of the various approaches need to be consider and understood.
To help, I started a list of various configuration/development and Azure based options and scenarios/examples of when they could be used.
Note that this list is definitely not complete, nor should it be taken as absolute gospel. If it makes more sense to implement an autonumber solution using a workflow or JavaScript in your implementation, by all means, do it! (But really, autonumber using JavaScript?) For the most part, these options don’t use any 3rd party tools or add-ons.
These are just notes from my experience, I hope you find them helpful.
Configuration Options
The following is information about configuration options that can should be considered first before looking at development options. Note that even if requirements can be met using configuration, a development option may provide a better return on investment in areas of speed and usability.
| Approach | Description | Scenario/Example Use Case |
|---|---|---|
| Field, Form, View, Entity Customizations | This is the core of Dyn365 configuration and allows someone to model business objects as entities and attributes as fields.
The various forms, views of the data can be created to capture and review data in Dyn365. |
Essentially all Dyn365 projects have some level of custom or customized Entities, Forms, Fields and Views. |
| Embedded Views | Multiple child records can viewed from within a “grid” in the context of a Form for faster viewing and potential data manipulation. | Any situation where the user needs to see or act upon the related records quickly without having to navigate further into the system to retrieve this information.
For example, an Account could have an embedded view of its employees. |
| Embedded Charts | An Embedded View (see above) can be configured to show only chart data and provide end users with aggregate data (counts, totals) in the context of the parent record. | A Case form can be configured to show a chart that displays the total billable time from related service activities for that particular case.
Consider rollup fields and calculated fields as alternatives. |
| Quick View Forms | The ability a related (parent) record information (beyond the lookup) information on a form. Allows user to see this information without needing to drill down to locate further info. | On a Case form, can show all the related Account details (Phone, Address, etc) without needing to copy data from the parent records. |
| Business Rules | The ability to provide simple business logic to a form, such as hide/show fields and sections, make some items mandatory based on other selections. | Business Rules show a “membership” section on the Contact form.
A combination of Business rules and JavaScript on the same entity form can cause confusion/issues and ideally should be avoided. |
| Rollup Fields | Rollup fields allow for aggregation of data from related records to a field on an entity. (Count of records, sum of values in records, etc) Note these get updated every hour or on demand as needed. | A simple example would be a “Number of Employees” field on an Account that counts how many related “child” contacts exist that are flagged as employees.
Note, if “realtime” calculations are needed, consider a plug-in on child record updates. |
| Calculated Fields | Calculated fields allow for data to be calculated based on values from other fields. | A simple example would be weighted revenue on an Opportunity. This calculated field would determine by estimated revenue multiplied by close probability. This was traditionally done by plug-ins or client side javascript. |
| Business Process Flows | Business process flows “drive” the user to enter in key information over a series of entity records. | Entering key data as it relates to a sales process on leads and opportunities.
Dialogs could be considered or just via fields on a form that may open close using Business rules. |
| Dialogs | Allow user to launch a process that will take them through a series of questions/responses to update data or perform other actions. | A dialog launched from an Order record that will create a corresponding Case record with associated appointment records. User is prompted for dates and Dyn365 users to assign Case to.
Consider Business Process flows as a possible alternative. |
| Workflows | Workflows are automated processes that can perform a number of functions. Workflows can run synchronously, meaning once triggered they must run to completion before any more interaction can happen or they can run asynchronously meaning the process will run but the user can continue working.
Workflows can be triggered from a number of different actions. |
An email can be created and sent when a Case is resolved.A workflow can update the blank “name field” when a new record is saved.
Workflows are easily maintained, but plug-ins run much faster. |
| Mobile Forms | For functionality that requires manipulation on a mobile phone or tablet device, the out of the box mobile options should be considered before a mobile application development effort is put forth. | User needs to update or read information on a mobile device.
Note that in CRM 2015 and higher the mobile form provides a series of more touch friendly controls. |
Development Options
The following is information about development options that can be used if the system cannot accommodate the requirement either functionally, efficiently or in a user friendly manner.
| Approach | Description | Scenario/Example Use Case |
|---|---|---|
| Custom Workflow Extensions | Allows for custom options and functions to be provided when creating workflows that are not provided as part of the out of the box workflow features. These elements can be surfaced to functional folks setting up workflows. | If a user wanted to generate a PDF from a report and attach it to an email, the workflow extension could call the appropriate reporting extensions, generate the PDF and attach it to an email.
Consider full plug-ins. |
| Custom Actions | Allows for custom code to be written that can be called from JavaScript, plug-ins or workflows. | Example would be to run a plug-in by clicking a menu button as opposed to firing by updating a field and saving.
Actions could be used to store configuration and “rule” data as opposed to custom entities. |
| Client Side JavaScript | JavaScript on the Dyn365 form allows for various automation to occur on the user interface, calculations or other features.
JavaScript can be triggered from various events (form loading, field changes, record saving, etc) Many of the traditional JavaScript use cases can now be handled using Business Rules. However, mixing Business Rules and JavaScript can cause functional issues and should be avoided or carefully managed. |
Once a user enters a phone number, a JavaScript function will format the phone number into a North America standard format.
Javascript can only be triggered on a form, form elememts or custom button, if data is updated via backside integration or import, form scripts will not be triggered. JavaScript ideally should be used for small, specific client side functions. |
| Plug-ins | Plug-ins allow custom actions in the Dyn365 execution pipeline. Many Dyn365 actions can be intercepted and data manipulated. Plug-ins are very powerful method to provide unique functionality to a project. | An example plug-in would be code that calculates the tax on an invoice based on particular product types, customer and current values.
A plug-in could also be triggered when a specific view is being rendered and the data manipulated to the end user. Plug-ins run fast, can be triggered by pretty much any Dyn365 action but require special tools (Visual Studio) and knowledge to implement. For solutions where speed or complexity is not an issue, consider workflows. For processes that require a lot of data manipulation or compute power, consider offloading to Azure Service Bus or Azure Functions. |
| Web Resources | Web resources can be different files and custom user controls loaded in CRM for various functions (XML for static data) or a HTML5 type special user interface.
Care should be taken to ensure that the controls are following supported best practices. Traditional CRM UI (Business Process Flows, Dialogs) should be considered before using a Web Resource as a specialized user interface. Consider using custom menu/ribbon buttons before adding “button” web resource controls on a CRM form. |
A specialized user interface that requires data to be entered in a unique, systematic way. E.g. an interface to apply payments to an invoice but allow for payments to dispersed in a unique way.
A drag and drop interface. |
| Integration Solutions (Data updated via an external tool) | If mass amounts of data need to be updated or manipulated on a regular basis, consider using an integration solution to update the data from an external source rather than update the data from within Dyn365. | Updating large amounts of data.
Various tools are available (Scribe, Kingsway, etc) Consider Azure options. |
Azure Options
Azure technology and Features are constantly evolving, this now opens up many exciting new and innovative ways to build solutions and to resolve technology roadblocks within Dynamics 365 Online. I am only just getting started using Azure on Dyn365 projects and pretty encouraged of what can be potentially done!
| Approach | Description | Scenario/Example Use Case |
|---|---|---|
| Azure Service Bus | Events can be triggered from Dynamics 365 to offload processing to Azure, typically for processes that may take longer than the 2 minute limit on plug-ins will allow. | Good for batch processing large amounts of data (Membership renewals, invoice batches, etc) |
| Azure Functions | Functions that will run independently of Dyn365 but can act on the data (or triggered), again, good for offloading heavy tasks.
Good for things that need to query other systems or generate data . Azure Functions can be scheduled, so they can do updates to Dyn365 data. |
Could be used for external processing of data (generate memberships renewals, process payments in a different system)
A schedule could be setup in an Azure funciton to send out/generate renewal notices, etc. Could also be used to do some external processing or generation (generate QR code attachments) |
| Azure Logic Apps | Essentially the “developer backend” for Microsoft Flow. This tool can orchestrate the movement of data to/from Dyn365 from other systems. | I think this would be good for situations where data needs to be integrated, but where a tool like Scribe is too much overkill to do it, so for lower volume type stuff.
Could be for a non-Dyn365 portal to send info from a form to Dyn365. |
| Azure SQL | Add-in for Dyn365 that will replicate data to an AzureSQL. | Good for reporting and BI without straining the Dyn365 database directly.
Not sure if we can write contextual SSRS (t-SQL) reports and upload them in Dyn365 directly? |
| Azure Machine Learning | Tool with ability to identify trends in data and provide statistics for effective decision making. | An example that I have seen is the Azure ML took a list of reasons why opportunities were lost and look at the profile of the potential customers and in turn, analyzed data and provide best possible “next steps” for existing opportunities (e.g. offer 10% discount to this customer type will provide the highest probability to close this sale) |
I will likely be going back and updating this list on a regular basis. I hope you find it is a good resource in both knowing what options are available and helping you determine where and when its best to use something.
Cheers
Nick
ReadyXRM 