This is an accompanying blog post to my YouTube video Dynamics 365 Customer Engagement Deep Dive: Creating a Basic Jscript Form Function, the first in a series that aims to provide tutorials on how to accomplish developer focused tasks within Dynamics 365 Customer Engagement. You can watch the video in full below:

Below you will find links to access some of the resources discussed as part of the video and to further reading topics.

PowerPoint Presentation (click here to download)

Full Code Sample

function changeAddressLabels() {

    //Get the control for the composite address field and then set the label to the correct, Anglicised form. Each line requires the current control name for 'getControl' and then the updated label name for 'setLabel'

    Xrm.Page.getControl("address1_composite_compositionLinkControl_address1_line1").setLabel("Address 1");
    Xrm.Page.getControl("address1_composite_compositionLinkControl_address1_line2").setLabel("Address 2");
    Xrm.Page.getControl("address1_composite_compositionLinkControl_address1_line3").setLabel("Address 3");
    Xrm.Page.getControl("address1_composite_compositionLinkControl_address1_postalcode").setLabel("Postal Code");

    if (Xrm.Page.getControl("address2_composite_compositionLinkControl_address2_line1"))
        Xrm.Page.getControl("address2_composite_compositionLinkControl_address2_line1").setLabel("Address 1");

    if (Xrm.Page.getControl("address2_composite_compositionLinkControl_address2_line2"))
        Xrm.Page.getControl("address2_composite_compositionLinkControl_address2_line2").setLabel("Address 2");

    if (Xrm.Page.getControl("address2_composite_compositionLinkControl_address2_line3"))
        Xrm.Page.getControl("address2_composite_compositionLinkControl_address2_line3").setLabel("Address 3");

    if (Xrm.Page.getControl("address2_composite_compositionLinkControl_address2_city"))

    if (Xrm.Page.getControl("address2_composite_compositionLinkControl_address2_stateorprovince"))

    if (Xrm.Page.getControl("address2_composite_compositionLinkControl_address2_postalcode"))
        Xrm.Page.getControl("address2_composite_compositionLinkControl_address2_postalcode").setLabel("Postal Code");

    if (Xrm.Page.getControl("address2_composite_compositionLinkControl_address2_country"))

Download/Resource Links

Visual Studio 2017 Community Edition

Setup a free 30 day trial of Dynamics 365 Customer Engagement

W3 Schools JavaScript Tutorials

Source Code Management Solutions

Further Reading

MSDN – Use JavaScript with Microsoft Dynamics 365

MSDN – Use the Xrm.Page. object model

MSDN – Xrm.Page.ui control object

MSDN – Overview of Web Resources

Debugging custom JavaScript code in CRM using browser developer tools (steps are for Dynamics CRM 2016, but still apply for Dynamics 365 Customer Engagement)

Have any thoughts or comments on the video? I would love to hear from you! I’m also keen to hear any ideas for future video content as well. Let me know by leaving a comment below or in the video above.

The world of database security and protection can be a difficult path to tread at times. I often find myself having to adopt a “tin-foil hat” approach, obsessing over the smallest potential vulnerability that a database could be compromised with. This thought process can be considered easy compared with any protective steps that need to be implemented in practice, as these can often prove to be mind-bogglingly convoluted. This is one of the reasons why I like working with Microsoft Azure and features such as Azure SQL Database Firewall Rules. They present a familiar means of securing your databases to specific IP address endpoints and are not inordinately complex in how they need to be approached; just provide a name, Start/End IP range and hey presto! Your client/ application can communicate with your database. The nicest thing about them is that the feature is enabled by default, meaning you don’t have to worry about designing and implementing a solution to restrict your database from unauthorised access at the outset.

As alluded to above, Database Firewall Rules are added via T-SQL code (unlike Server Rules, which can be specified via the Azure portal), using syntax that most SQL developers should feel comfortable using. If you traditionally prefer to design and build your databases using a Visual Studio SQL Database project, however, you may encounter a problem when looking to add a Database Firewall rule to your project. There is no dedicated template item that can be used to add this to the database. In this eventuality, you would have to look at setting up a Post-Deployment Script or Pre-Deployment Script to handle the creation of any requisite rules you require. Yet this can present the following problems:

  • Visual Studio will be unable to provide you with the basic syntax to create the rules.
  • Related to the above, Intellisense support will be limited, so you may struggle to identify errors in your code until it is deployed.
  • When deploying changes out to your database, the project will be unable to successfully detect (and remove) any rules that are deleted from your project.

The last one could prove to be particularly cumbersome if you are tightly managing the security of your Azure SQL database. Putting aside the obvious risk of someone forgetting to remove a rule as part of a deployment process, you would then have to manually remove the rules by connecting to your database and executing the following T-SQL statement:

EXECUTE sp_delete_database_firewall_rule 'MyDBFirewallRule'

Not the end of the world by any stretch, but if you are using Visual Studio as your deployment method for managing changes to your database, then having to do this step seems a little counter-intuitive. Fortunately, with a bit of creative thinking and utilisation of more complex T-SQL functionality, we can get around the issue by developing a script that carries out the following steps in order:

  • Retrieve a list of all current Database Firewall Rules.
  • Iterate through the list of rules and remove them all from the database.
  • Proceed to re-create the required Database Firewall Rules from scratch

The second step involves the use of a T-SQL function that I have traditionally steered away from using – Cursors. This is not because they are bad in any way but because a) I have previously struggled to understand how they work and b) have never found a good scenario in which they could be used in. The best way of understanding them is to put on your C# hat for a few moments and consider the following code snippet:

string[] array = new string[] { "Test1", "Test2", "Test3" }; 

foreach(string s in array)

To summarise how the above works, we take our collection of values – Test1, Test2 and Test3 – and carry out a particular action against each; in this case, print out their value into the console. This, in a nutshell, is how Cursors work, and you have a great deal of versatility on what action you take during each iteration of the “loop”.

With a clear understanding of how Cursors work. the below script that accomplishes the aims set out above should hopefully be a lot clearer:

DECLARE @FirewallRule NVARCHAR(128)

FROM sys.database_firewall_rules

	EXECUTE sp_delete_database_firewall_rule @FirewallRule
	PRINT 'Firewall rule ' + @FirewallRule + ' has been successfully deleted.'


EXECUTE sp_set_database_firewall_rule @name = N'MyDBFirewallRule1',
		@start_ip_address = '', @end_ip_address = '';

EXECUTE sp_set_database_firewall_rule @name = N'MyDBFirewallRule2',
		@start_ip_address = '', @end_ip_address = '';

To integrate as part of your existing database project, add a new Post-Deployment Script file and modify the above to reflect your requirements. As the name indicates, the script will run after all other aspects of your solution deployment has been completed. Now, the key caveat to bear in mind with this solution is that, during deployment, there will be a brief period of time where all Database Firewall Rules are removed from the database. This could potentially prevent any current database connections from dropping or failing to connect altogether. You should take care when using the above code snippet within a production environment and I would recommend you look at an alternative solution if your application/system cannot tolerate even a second of downtime.

The recent releases of Dynamics CRM have very much been missing something for developers who work with the product. Whilst a number of exciting new features have been added to the product – the Web API, Interactive Service Hub and Portals, to name a few – there very much feels to be a lack of attention towards surrounding support tools to give developers a head start in progressing their careers and facilitating more agile and efficient development of bespoke CRM solutions. Exams are one area that has been guilty of this, with no up to date exam for developers released for over 3 years. In today’s modern world, 3 years is a lifetime of change and can leave developers in a situation where they are not aware of the latest technologies and potentially developing solutions that will soon be deprecated or lead to additional development time and administrative headroom to manage.

With this in mind, it is pleasing to hear that an updated version of the Visual Studio Developer Toolkit will be released for Dynamics 365 and that a beta version of this tool is now available to be downloaded. For those who have not used the earlier version of this tool for Dynamics 2013 and earlier, it provides developers the mechanism to create Visual Studio project templates that can store all of your related development assets, facilitate the deployment of these assets to your CRM instance from within Visual Studio and allow you to generate early-bound class files of your CRM entities and the requisite template class files for your Plugins; enabling you to focus more on developing your business logic. I have some experience using the tool myself in a sparing manner and have found it somewhat cumbersome to use. For example, I have had issues where I have had to sign into a development CRM system every time the project loads and I have not found it straightforward to use alongside existing CRM solutions. The tool is also only compatible with Visual Studio 2012 and earlier, which means developers running the latest version of Visual Studio will miss out on being able to use the toolkit. Nevertheless, the ability to generate the required code for your plugins in a quick manner is a major boon and, with the new release, a major opportunity is present in order to improve the tool and resolve some of its glaring issues. I’ve been taking a look at the Beta release of the Dynamics 365 Toolkit, and here are some of the new features which I am most excited about and feel will be a big help to developers in the months ahead:

Templates for Mobile App Development

For most standard deployments, the out of the box Dynamics 365 for Tablet/Mobile app will be sufficient for your users. You could even look at developing a simple app using PowerApps. For more advanced scenarios, the SDK would be your next port of call in order to develop a mobile app that connects up with CRM/D365E. This is a popular approach to take when developing a mobile app with a specific function, as it enables you to leverage the full functionality of CRM/D365’s processes as part of your app, whilst ensuring that the data model conforms to a familiar, SQL Server-based model. The analogy I have used before with other developers is that developing for Dynamics CRM is like developing for SQL Server on steroids 🙂

Previously, there were some code examples included as part of the SDK in order to help developers “get started” with developing a Windows Store, iOS and/or Android app that connects to CRM. Now, the Dynamics 365 Toolkit includes a number of Project templates that help with developing a mobile, store and/or universal app:


The only caveat with these templates is that they are designed solely for Windows-based devices; for a truly cross-platform application, then you would need to look at utilising a tool like Xamarin in order to meet your requirements.

Configuring Paths to SDK/Plugin Registration Tool

This is a minor new feature, but something that is important and, arguably, essential if you are frequently developing new CRM/D365E developer solutions. Within the settings page for the toolkit, you can now specify the location for your SDK DLL’s and Plugin Registration tool; which will then be used across all of the projects you create in Visual Studio moving forward:


This is a huge time-saving step and removes a rather tedious task that is often involved when it comes to setting up your Visual Studio projects.

Configure Microsoft Dynamics 365 Solution Wizard

When you now create a new Dynamics 365 solution template in Visual Studio, you are greeted with a simple and clear wizard that helps facilitates the following scenarios:

  • Specification of a persistent connection to CRM/D365E, that can then be re-used across different projects within Visual Studio and provides a familiar UI experience with the existing tools within the SDK (such as the Plugin Registration Tool):




  • The ability to select or create a brand new solution from within Visual Studio (previously, you only had the option of selecting an existing solution):


  • Granular level control of which templates to include in your project – including Plugins, Custom Workflow Assemblies or Web Resources/Assets:



With all these changes put together, the process of setting up new projects that are targeting a single CRM environment is greatly simplified and you can ensure that your project contains just the assets that you need.

Why the Developers Toolkit is important

One of the major hurdles that developers generally face is having to deal with all of the stuff that is non-development related – setting up environments, installing development tools and resolving environment configuration issues, to name but a few. Whilst all of this is useful experience and gives developers a flavour for how a potential application deployment will look, it can often get in the way of a developer’s primary responsibility; to just code. This is one of the reasons why DevOps is becoming an increasingly more important area of focus for businesses who employ developers, as having an effective DevOps strategy, plan and resource will ensure greater productivity from your existing resource and help to foster an environment where projects are being run the “right” way. The Developers Toolkit is an important tool in your DevOps arsenal, as it works towards meeting all of the above objectives and begins to foster an approach where set standards are followed across multiple projects. It also helps take out the administrative effort often involved with, for example, setting up a Plugin class file manually within Visual Studio. Although the Dynamics 365 Developers Toolkit is still in beta, and not ready for Production use, I would very much hope to see a full release in the near future. Tools of this nature (such as XRMToolBox and the Ribbon Workbench) help to encourage greater efficiency, which is often essential for many IT projects these days.