Last post, we looked at reasons why it is important to consider other options before starting to write code.  However, sometimes there is no other way to solve a problem then by rolling up your sleeves and coding a solution. The main advantage of code is its ability to solve almost any problem. Microsoft and third party developers have done an excellent job of designing tools that allow power-users and citizen developers to make changes to 365 without needing to code, but they haven’t thought of everything, nor is it worth their time to try to plan for every possible business case.  That’s where traditional developers come in. Let’s look at the two most common areas coding is used in Dynamics 365 CE.

Forms

One of the most common things a user does in 365 is enter data into forms. Business Rules (BR) allow the user to specify certain actions based on field values.  They run at the server level and can run on multiple devices or platforms. However, Business Rules come with some severe limitations.  Firstly, they can run only when the Form first loads or when field values change. Secondly, they do not run when the form is saved, unless the rule’s scope is set at the entity level.  Thirdly, if a field that the Business Rule references does not exist on the form, the BR simply will not run. Finally, when a Business Rule changes the value of a field, that field’s event handlers will not run. JavaScript has none of these limitations.  In fact, JavaScripts functions are required for Command Bar buttons.  They can respond to changes in field values and perform complex logic when needed.  Before writing your own code, though, check online to see if someone has already written a library or examples that do what you need it to.  Even when you have to use code, avoid rewriting the wheel. Pro-Tip: Have a JavaScript file for each entity and Command Bar, and name them accordingly.  This will make it obvious what references the file and prevent misguided deletions.

Plugins

Plugins pick up where JavaScript leaves off.  Custom plugins are run exactly the same as their standard counterparts, and 365 cannot tell the difference between custom code and Microsoft code. The main disadvantage of plugins is that they can’t be triggered manually.   Plugins can be written in C# or VB .NET (though C# is by far more common). Because these two languages are not often learned by anyone except professional developers, it would be wise to check if the operation can be performed by JavaScript (which is much more commonly learned) before opting to use plugins, as it limits the number of people who can maintain the code. Where plugins really shine is when curating data for the database. They are useful for transforming data in CRUD operations (CReate, Update, and Delete), and can be configured to run on certain conditions, as well as before a database operation or after.  Running pre-operation can be useful for populating fields unknown to the user (like a new account ID) while post-operation can be useful for getting database IDs, which are only known once the database record is created. There are two questions to take into consideration when designing a plugin.  The first is, does the user need to know the results of the execution?  If so, the plugin must operate synchronously.  Asynchronous operations occur in the background and cannot display messages directly to the user.  The second question to ask is where will the program run, and how much trust will it need?  Plugins that run for Dynamics 365 CE online usually operate in Sandbox (partial-trust) mode, and only a deployment manager can register plugins that require full trust.

Summary

These are the main situations where coded solutions are needed for Dynamics 365 CE development.  If you haven’t already, go ahead and check our post on When Coding Is NOT the Solution. For all advice on the Dynamics 365 market please do contact our consultants, we will be happy to answer any questions.