This article is targeted at developers looking at making the transition as a Dynamics 365 Customer Engagement (or CE for short).  Dynamics 365 and the Power Platform (PowerApps, Common Data Service, PowerBI) is really getting a lot of attention at the moment.  As organisations become more customer focused, platforms that provide capabilities in customer engagement are becoming more and more important.

The aim of this guide is to provide you with the necessary tools and resources to reduce the learning curve of this often complex platform, understand where to get help when needed, and allow you to focus your learning on areas which will be applicable to you on the job.

It is helpful if you have had exposure to the following before you continue reading:

  • .NET Development
  • JavaScript Development
  • Visual Studio IDE or similar IDE

The Data Entity Model

Dynamics has a robust entity model, instead of directly modelling your tables as a SQL relational database, you build your model through Dynamics Data Entities.  The entity model is called the Common Data Model and has approximately 54 core entities, as well as a number of standard entities that relate to the first party Microsoft applications such as Sales, Service, Marketing, etc.  To understand more about the CDM check out this overview at at Microsoft Docs:

https://docs.microsoft.com/en-us/powerapps/common-data-model/overview

The Common Data Model allows you to build your custom entities and relationships, that will eventually drive the data captured by your forms.

Tip: 

    • For the most up to date schema model for CDM, please refer to the Microsoft GitHub project here:

https://github.com/Microsoft/CDM/tree/master/schemaDocuments#directory-of-cdm-entities

Features

Once you have your data model in place, you can configure your Forms, Views, Business Rules, Workflows.  These are in-built features that make configuring your application simple.  Views are exactly that, configured at the system or at a user level, they allow you to control the data that is presented in a view (or a grid like interface, similar to how SQL views work with columns+sorting and so forth).  Forms allow you to control the way data capture forms are presented with attributes, sections, tabs, and their visibility properties.  Workflows allow you to automate certain tasks (such as creation of follow up activity records).  Business rules allow for the creation of simple logic similar to workflows but react to your inputs on screen.

For more information on each of these concepts check out:

And security modelling, allows you to control access to features and data at a granular level.  These are additive, and managed through what are known as security roles.  For more information about security models see here: https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/security-dev/security-model

 

When should you be extending the platform? (Configuration vs Customisation)

Firstly, we encourage configuration over customisation (or custom code).  Because Dynamics 365 receives major updates to the platform twice per year (April and October), platform extensions will require some level of testing and maintenance to ensure backwards compatibility.  It is the single most important factor in determining whether you should be extending the platform when it comes to Dynamics.

However, there will be times when creating platform extensions through custom code is highly desirable, or even necessary to the success of a project.  That’s where the Dynamics 365 CE developer will play an important role.

Broadly speaking, platform extensions can be split into two categories – Client Side Development and Server Side Development.  That’s not necessary true in call cases, as some front end development will have the potential to perform server side functions but we don’t have to worry about this when you’re starting out.

 

Client Side Development

The only tool you really need to get started is notepad and your browser’s debug function.  Client side development occurs when want to apply logic to a Dynamics form or control.  For example a form save event, or an on-change event on a form control.

This would be achieved through JavaScript – methods can be created within JavaScript resource files which you load into your solution and referenced from a form or a control.  For documentation on the Client Side API see here:

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/clientapi/client-scripting

However, before you jump straight into client side scripting, do note that Dynamics 365 supports portable business logic through Business Rules.  Business rules allow you to define logic without the use of code, such as showing and hiding attributes based on values, or performing simple calculations and updates.  So as I mentioned in the previous section, aim for configuration over customisation to ensure you remain lock step with updates in the future.

Tips for Client Side Development:

  • Reusability – break up your JavaScript files into smaller reusable methods/js files.  Then add to forms only where necessary.
  • Supported Customisations – run your JavaScript through a code compatibility checker to ensure you are using supported code.  This is important for future updates.

 

Server Side Development

Server side code can be written that perform actions based on server side events.  Such as when a record is retrieved, updated, created, or deleted.  Server side code can be both synchronous (occur in real time) or asynchronous (run when resources become available).  These extensions can take the form of Custom Workflows or Plugins.  Custom workflows allow you to include your own logic as steps within the in-built workflow engine (for example code that connects to an external system).  Whilst Plugins have other platform specific features that allow it to registered to selected entities and triggers (such as an update), can be easily enabled/disabled, and can have their execution order updated easily through the plugin registration tool.

In order to register a plugin or custom workflow, you can do so through the Plugin Registration tool (that comes with the downloaded SDK) or directly within Visual Studio.

Tips for Server Side Development:

  • Get only what you need – when using a retrieve statement, retrieve only data you intend to use.  Similarly, write back only data what you intend to update.
  • XrmToolBox is your best friend.  Community built tools that speed up development and management of the platform. 
  • Learn how to attach the debugger to your plugins, and the tracing service for Dynamics 365 online.

Low-Code Development

Once you have defined your data model, you can extend the functionality through low-code or codeless development.  The technologies that enable this are PowerApps, Flow and LogicApps.

PowerApps has been referred to as “PowerPoint for Applications”, allowing you to create pixel-perfect apps (known as Canvas apps) or data driven apps (known as Model apps).  It is largely a drag and drop affair, with its own syntax that is similar to what you would find in Excel and other Office applications.  PowerApps allows you to rapidly deploy across your organisation.

Flow is a workflow system that has 200+ connectors into other systems, it works similarly to other workflow systems such as If This Than That (IFTTT).  And allows you to design flows with no code.

LogicApps is the underlying technology behind Flow.  LogicApps has the ability to be extended through custom code, and deployed / monitored in enterprise deployment scenarios.  It is a consumption based system, that enables integration-as-a-service.

It’s important to understand these emerging technologies, as they will become more and more prevalent within Dynamics deployments.

 

Does it matter if the solution is hosted in the cloud or on-premise?

While Dynamics 365 is largely hosting agnostic, the short answer is yes it does matter.  For many years now, the recommendation is to always develop and run plugins and workflow extensions in sandbox mode to enable cloud deployment, there are still options that enable you to run OS layer operations and deploy to the GAC.  In the on-premise days you could potentially fire events to Office Server to perform operations within Microsoft Word and other Office Applications, now there isn’t a real need to as most services are now available in the cloud.  So always aim to design your extensions in a fashion that lends itself to a cloud deployment, even if your customer happens to be on-premise.  When in doubt, reach out to colleagues or the community for a second opinion (more on how to do that later).

 

Things you need to watch for when developing for Dynamics

Number one, licensing.  Multiplexing is has licensing implications – that means if you’re developing an application that is enabling multiple users to read Dynamics data through a single service account, you will still need individual user licensing.  An example would be if you were to develop a custom portal where employees could read a list of contacts, each employee would still need at least a team license.  This is all covered within the Dynamics 365 Licensing Guide.

Number two, performance.  Registering too many extensions may decrease system performance.  Consider making extensions asynchronous wherever possible so that they run the background.  Reduce complexity and the number of calls required.  Use threading where appropriate.  Though I feel this applies to all applications not just Dynamics, it just needs to be said as many of us veterans have spent hours looking for that one runaway plugin at some point or another.

Number three, use supported frameworks.  Keep in mind that whilst Dynamics has largely kept pace with technological advancements, some of the patterns and libraries aren’t exactly cutting edge.  For those more experienced developers it may be tempting to carry over a frameworks to help with development just note it may not necessarily be the best fit for Dynamics.  Know what is okay to use, jQuery for instance is supported, some of your favourite libraries may not.  Once again, when in doubt seek a second opinion.

 

Learn by Doing

The best way to get started is to start up a test environment which you can delete at anytime – use this environment to familiarise yourself with Dynamics features and as a general playground for testing your ideas.  You can sign up for a 30 Day trial of Dynamics 365 at https://trials.dynamics.com/.

If you have a team member currently on a Dynamics projects, ask if you can shadow them for a while or help out with some of the more simple configuration items.

 

Learn through Training

Microsoft partners can obtain access to the Dynamics Learning Portal.  Here you will find self-paced reading material and videos that guide you through to becoming proficient in platform development.  Your organisation’s partner manager should be able to assist with providing you access.

Customers can access the Dynamics CustomerSource Portal.  Similarly there is a variety of learning materials here for existing customers of Dynamics 365.

And I would highly recommend sitting an exam or two, to ensure your transcripts reflect your current level of expertise.

 

Dynamics Communities

One of the best ways of getting started in Dynamics is by getting involved with the Dynamics User Group communities.  We welcome levels of experience to the user groups, and most if not all are free events that run in virtually all regions.  Here are some of the more popular ones:

 

Summary

So there you have it, a brief overview on transitioning your skills to the Dynamics 365 platform.  If you feel lost at first, don’t despair there are plenty of people in the community who are willing to help you.  Chances are whatever you’re trying to accomplish has been attempted before.

If you have any questions, thoughts or general comments please do drop me a line below.  Until next time!