Writing client side code with Microsoft Dynamics 365

Client sided development in Dynamics 365 allow us to alter the user interface and influence how a user interacts with the application. In this context, I refer to client side code as that which primarily effects the user interface and is executed on the client machine. However, the lines are a little blurred at time, e.g. the XML driven elements are parsed on the server before rending on the user’s machine. We have the following options for client side code.

This article is part of a series

Form script – using JavaScript

We can add JavaScript to 365 forms which allows us to customise client side logic. You can do things like add client side validation, show user popups, pre-populate fields, set mandatory fields, manage read only fields, hide and show content, and generally control existing elements of the user interface. You can’t fundamentally change the user interface however, e.g. don’t expect to be adding buttons willy-nilly or creating bespoke web apps.

As well as controlling the user interface, you can also use JavaScript to quickly access the 365 web services. This will allow you to interact with the wider application beyond the immediate context of a form. This is most often used when you need to access entity data related to the current record, e.g. data from a record shown in a lookup field.

A significant amount of the client side work can also be achieved using Business Rules. This no-code approach is useful for lowing the skill barrier required of the customiser, and can enable rapid implementations. That said Business Rules don’t provide feature parity with JavaScript, and often JavaScript implementations are easier in complex scenarios. As such it’s not unusual for a project to mix JavaScript and Business Rules.

A key consideration when using JavaScript is that it is only applied if a user opens a form. Don’t rely on JavaScript alone to enforce critical business rules, enforce data consistency, or for security. For example, workflows, plugins, web service calls, and bulk edit are all unaffected by JavaScript.

Finally, a web developer with existing JavaScript skills may approach 365 development as any other web app, e.g. with DOM manipulation. This is not a sensible approach, and will likely lead to unsupported situations. The only JavaScript functions you can use are defined on the MSDN; this enforces limits on what you can do and how can you do it. However, it ensures your code is supported and reduces the risk of future upgrades breaking your implementation.

Web Resources – using HTML, and JavaScript

You can create and store HTML web resources within 365. This enables you to build mini web apps within the context of 365, these are typically placed in forms and dashboards. This is handy as the web resource is packaged as part of the CRM solution with no additional hosting or deployment steps required.

Within a web resource you have greater freedom in respect of development options and you can build far richer and bespoke user interfaces. They can be developed far more like a typical web app. That said the same JavaScript API used for form scripting is still available. The biggest issue with web resource development is the lack of a decent IDE, and interactions between web resources and forms can occasionally be tricky.

If you feel like going old school you can also create Silverlight web resources. However this has largely gone out of fashion since Microsoft are dropping support for Silverlight as a technology.

Command Bar (aka Ribbon) – using XML

Not truly coded development, but a handy way to customise elements of the user interface. Editing the command bar, previously known as the ribbon – and in some locations still presented as a classic Office ribbon – allows you to add buttons and edit existing buttons. You have to export a solution of the required elements, edit the XML, and then reimport the solution. For a long time this was a trauma and Microsoft failed to provide any decent tooling to make it easier. Fortunately, Scott Durrow filled the gap – use Ribbon Workbench to do the heavy lifting here.

Sitemap – using XML pre 365

The sitemap allows you to control the navigation of CRM, e.g. which sections are shown and how entities are grouped together. This can be useful if you want to present a third party web app within the application via an iframe accessed as part of the normal navigation.

Pre-365 the sitemap was largely controlled by editing XML much like the command bar, so use a plugin within the XrmToolbox by Tanguy Touzard to do this. Post-365 you can now control the sitemap via a dedicated editor inside 365. For all versions you can set where entities appear within the customisation settings for that entity.

Original Post https://woodsworkblog.wordpress.com/2017/06/25/writing-client-side-code-with-microsoft-dynamics-365/