In last week’s post, we took a look at how a custom Workflow activity can be implemented within Dynamics CRM/Dynamics 365 for Customer Engagement to obtain the name of the user who triggered the workflow. It may be useful to retrieve this information for a variety of different reasons, such as debugging, logging user activity or to automate the population of key record information. I mentioned in the post the “treasure trove” of information that the IWorkflowContext interface exposes to developers. Custom Workflow activities are not unique in having execution-specific information exposable, with an equivalent interface at our disposal when working with plug-ins. No prizes for guessing its name – the IPluginExecutionContext.

When comparing both interfaces, some comfort can be found in that they share almost identical properties, thereby allowing us to replicate the functionality demonstrated in last weeks post as Post-Execution Create step for the Lead entity. The order of work for this is virtually the same:

  1. Develop a plug-in C# class file that retrieves the User ID of the account that has triggered the plugin.
  2. Add supplementary logic to the above class file to retrieve the Display Name of the User.
  3. Deploy the compiled .dll file into the application via the Plug-in Registration Tool, adding on the appropriate execution step.

The emphasis on this approach, as will be demonstrated, is much more focused towards working outside of the application; something you may not necessarily be comfortable with. Nevertheless, I hope that the remaining sections will provide enough detail to enable you to replicate within your own environment.

Developing the Class File

As before, you’ll need to have ready access to a Visual Studio C# Class file project and the Dynamics 365 SDK. You’ll also need to ensure that your project has a Reference added to the Microsoft.Xrm.Sdk.dll. Create a new Class file and copy and paste the following code into the window:

using System;
using Microsoft.Xrm.Sdk;
using Microsoft.Xrm.Sdk.Query;

namespace D365.BlogDemoAssets.Plugins
{
    public class PostLeadCreate_GetInitiatingUserExample : IPlugin
    {
        public void Execute(IServiceProvider serviceProvider)
        {
            // Obtain the execution context from the service provider.

            IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));

            // Obtain the organization service reference.
            IOrganizationServiceFactory serviceFactory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
            IOrganizationService service = serviceFactory.CreateOrganizationService(context.UserId);

            // The InputParameters collection contains all the data passed in the message request.
            if (context.InputParameters.Contains("Target") &&
                context.InputParameters["Target"] is Entity)

            {
                Entity lead = (Entity)context.InputParameters["Target"];

                //Use the Context to obtain the Guid of the user who triggered the plugin - this is the only piece of information exposed.
      
                Guid user = context.InitiatingUserId;

                //Then, use GetUserDisplayCustom method to retrieve the fullname attribute value for the record.

                string displayName = GetUserDisplayName(user, service);

                //Build out the note record with the required field values: Title, Regarding and Description field

                Entity note = new Entity("annotation");
                note["subject"] = "Test Note";
                note["objectid"] = new EntityReference("lead", lead.Id);
                note["notetext"] = @"This is a test note populated with the name of the user who triggered the Post Create plugin on the Lead entity:" + Environment.NewLine + Environment.NewLine + "Executing User: " + displayName;

                //Finally, create the record using the IOrganizationService reference

                service.Create(note);
            }
        }
    }
}

Note also that you will need to rename the namespace value to match against the name of your project.

To explain, the code replicates the same functionality developed as part of the Workflow on last week’s post – namely, create a Note related to a newly created Lead record and populate it with the Display Name of the User who has triggered the plugin.

Retrieving the User’s Display Name

After copying the above code snippet into your project, you may notice a squiggly red line on the following method call:

The GetUserDisplayName is a custom method that needs to be added in manually and is the only way in which we can retrieve the Display Name of the user, which is not returned as part of the IPluginExecutionContext. We, therefore, need to query the User (systemuser) entity to return the Full Name (fullname) field, which we can then use to populate our newly create Note record. We use a custom method to return this value, which is provided below and should be placed after the last 2 curly braces after the Execute method, but before the final 2 closing braces:

private string GetUserDisplayName(Guid userID, IOrganizationService service)
    {
        Entity user = service.Retrieve("systemuser", userID, new ColumnSet("fullname"));
        return user.GetAttributeValue<string>("fullname");
    }

Deploy to the application using the Plug-in Registration Tool

The steps involved in this do not differ greatly from what was demonstrated in last week’s post, so I won’t repeat myself 🙂 The only thing you need to make sure you do after you have registered the plug-in is to configure the plug-in Step. Without this, your plug-in will not execute. Right-click your newly deployed plug-in on the main window of the Registration Tool and select Register New Step:

On the form that appears, populate the fields/values indicated below:

  • Message: Create
  • Primary Entity: Lead
  • Run in User’s Context: Calling User
  • Event Pipeline Stage of Execution: Post-Operation

The window should look similar to the below if populated correctly. If so, then you can click Register New Step to update the application:

All that remains is to perform a quick test within the application by creating a new Lead record. After saving, we can then verify that the plug-in has created the Note record as intended:

Having compared both solutions to achieve the same purpose, is there a recommended approach to take?

The examples shown in the past two blog posts indicate excellently how solutions to specific scenarios within the application can be achieved via differing ways. As clearly evidenced, one could argue that there is a code-heavy (plug-in) and a light-touch coding (custom Workflow assembly) option available, depending on how comfortable you are with working with the SDK. Plug-ins are a natural choice if you are confident working solely within Visual Studio or have a requirement to perform additional business logic as part of your requirements. This could range from complex record retrieval operations within the application or even an external integration piece involving specific and highly tailored code. The Workflow path clearly favours those of us who prefer to work within the application in a supported manner and, in this particular example, can make certain tasks easier to accomplish. As we have seen, the act of retrieving the Display Name of a user is greatly simplified when we go down the Workflow route. Custom Workflow assemblies also offer greater portability and reusability, meaning that you can tailor logic that can be applied to multiple different scenarios in the future. Code reusability is one of the key drivers in many organisations these days, and the use of custom Workflow assemblies neatly fits into this ethos.

These are perhaps a few considerations that you should make when choosing the option that fits the needs of your particular requirement, but it could be that the way you feel most comfortable with ultimately wins the day – so long as this does not compromise the organisation as a consequence, then this is an acceptable stance to take. Hopefully, this short series of posts have demonstrated the versatility of the application and the ability to approach challenges with equally acceptable pathways for resolution.

When it comes to technology learning, it can often feel as if you are fighting against a constant wave of change, as studying is outpaced by the introduction of new technical innovations. Fighting the tide is often the most desirous outcome to work towards, but it can be understandable why individuals choose to specialise in a particular technology area. There is no doubt some comfort in becoming a subject matter expert and in not having to worry about “keeping up with the Joneses”. However, when working with an application such as Dynamics 365 for Customer Engagement (D365CE), I would argue it is almost impossible to ignore the wider context of what sit’s alongside the application, particularly Azure, Microsoft’s cloud as a service platform. Being able to understand how the application can be extended via external integrations is typically high on the list of any project requirements, and often these integrations require a light-touch Azure involvement, at a minimum. Therefore, the ability to say that you are confident in accomplishing certain key tasks within Azure instantly puts you ahead of others and in a position to support your business/clients more straightforwardly.

Here are 4 good reasons why you should start to familiarise yourself with Azure, if you haven’t done so already, or dedicate some additional time towards increasing your knowledge in an appropriate area:

Dynamics 365 for Customer Engagement is an Azure application

Well…we can perhaps not answer this definitively and say that 100% of D365CE is hosted on Azure (I did hear a rumour that some aspects of the infrastructure were hosted on AWS). Certainly, for instances that are provisioned within the UK, there is ample evidence to suggest this to be the case. What can be said with some degree of certainty is that D365CE is an Azure leveraged application. This is because it uses key aspects of the service to deliver various functionality within the application:

  • Azure Active Directory: Arguably the crux of D365CE is the security/identity aspect, all of which is powered using Microsoft’s cloud version of Active Directory.
  • Azure Key Vault: Encryption is enabled by default on all D365CE databases, and the management of encryption keys is provided via Azure Key Vault.
  • Office 365: Similar to D365CE, Office 365 is – technically – an Azure cloud service provided by Microsoft. As both Office 365 and D365CE often need to be tightly knitted together, via features such as Server-Side Synchronisation, Office 365 Groups and SharePoint document management, it can be considered a de facto part of the base application.

It’s fairly evident, therefore, that D365CE can be considered as a Software as a Service (SaaS) application hosted on Azure. But why is all this important? For the simple reason that, because as a D365CE professional, you will be supporting the full breadth of the application and all it entails, you are already an Azure professional by default. Not having a cursory understanding of Azure and what it can offer will immediately put you a detriment to others who do, and increasingly places you in a position where your D365CE expertise is severely blunted.

It proves to prospective employers that you are not just a one trick pony

When it comes to interviews for roles focused around D365CE, I’ve been at both sides of the table. What I’ve found separates a good D365CE CV from an excellent one all boils down to how effectively the candidate has been able to expand their knowledge into the other areas. How much additional knowledge of other applications, programming languages etc. does the candidate bring to the business? How effectively has the candidate moved out of their comfort zone in the past in exploring new technologies, either in their current roles or outside of work? More importantly, how much initiative and passion has the candidate shown in embracing changes? A candidate who is able to answer these questions positively and is able to attribute, for example, extensive knowledge of Azure will instantly move up in my estimation of their ability. On the flip side of this, I believe that interviews that have resulted in a job offer for me have been helped, in no small part, to the additional technical skills that I can make available to a prospective employer.

To get certain things done involving D365CE, Azure knowledge is a mandatory requirement

I’ve talked about one of these tasks before on the blog, namely, how to setup the Azure Data Export solution to automatically synchronise your application data to an Azure SQL Database. Unless you are in the fortunate position of having an Azure savvy colleague who can assist you with this, the only way you are going to be able to successfully complete this task is to know how to deploy an Azure SQL Server instance, a database for this instance and the process for setting up an Azure Key Vault. Having at least some familiarity with how to deploy simple resources in Azure and accomplish tasks via PowerShell script execution will place you in an excellent position to achieve the requirements of this task, and others such as:

The above is just a flavour of some of the things you can do with D365CE and Azure together, and there are doubtless many more I have missed 🙂 The key point I would highlight is that you should not just naively assume that D365CE is containerised away from Azure; in fact, often the clearest and cleanest way of achieving more complex business/technical requirements will require a detailed consideration of what can be built out within Azure.

There’s really no good reason not to, thanks to the wealth of resources available online for Azure training.

A sea change seems to be occurring currently at Microsoft with respect to online documentation/training resources. Previously, TechNet and MSDN would be your go-to resources to find out how something Microsoft related works. Now, the Microsoft Docs website is where you can find the vast majority of technical documentation. I really rate the new experience that Microsoft Docs provides, and there now seems to be a concerted effort to ensure that these articles are clear, easy to follow and include end-to-end steps on how to complete certain tasks. This is certainly the case for Azure and, with this in mind, I defy anyone to find a reasonable enough excuse not to begin reading through these articles. They are the quickest way towards expanding your knowledge within an area of Azure that interests you the most or to help prepare you to, for example, setup a new Azure SQL database from scratch.

For those who learn better via visual tools, Microsoft has also greatly expanded the number of online video courses available for Azure, that can be accessed for free. There are also some excellent, “deep-dive” topic areas that can also be used to help prepare you for Azure certification.

Conclusions or Wot I Think

I use the term “D365CE professional” a number of times throughout this post. This is a perhaps unhelpful label to ascribe to anyone working with D365CE today. A far better title is, I would argue, “Microsoft cloud professional”, as this gets to the heart of what I think anyone who considers themselves a D365CE “expert” should be. Building and supporting solutions within D365CE is by no means an isolated experience, as you might have argued a few years back. Rather, the onus is on ensuring that consultants, developers etc. are as multi-faceted as possible from a skillset perspective. I talked previously on the blog about becoming a swiss army knife in D365CE. Whilst this is still a noble and recommended goal, I believe casting the net wider can offer a number of benefits not just for yourself, but for the businesses and clients you work with every day. It puts you centre-forward in being able to offer the latest opportunities to implement solutions that can increase efficiency, reduce costs and deliver positive end-user experiences. And, perhaps most importantly, it means you can confidently and accurately attest to your wide-ranging expertise in any given situation.

Dynamics CRM/Dynamics 365 for Customer Engagement (CRM/D365CE) is an incredibly flexible application for the most part. Regardless of how your business operates, you can generally tailor the system to suit your requirements and extend it to your heart’s content; often to the point where it is completely unrecognisable from the base application. Notwithstanding this argument, you will come across aspects of the application that are (literally) hard-coded to behave a certain way and cannot be straightforwardly overridden via the application interface. The most recognisable example of this is the Lead Qualification process. You are heavily restricted in how this piece of functionality acts by default but, thankfully, there are ways in which it can be modified if you are comfortable working with C#, JScript and Ribbon development.

Before we can start to look at options for tailoring the Lead Qualification process, it is important to understand what occurs during the default action within the application. In developer-speak, this is generally referred to as the QualifyLead message and most typically executes when you click the button below on the Lead form:

When called by default, the following occurs:

  • The Status/Status Reason of the Lead is changed to Qualified, making the record inactive and read-only.
  • A new OpportunityContact and Account record is created and populated with (some) of the details entered on the Lead record. For example, the Contact record will have a First Name/Last Name value supplied on the preceding Lead record.
  • You are automatically redirected to the newly created Opportunity record.

This is all well and good if you are able to map your existing business processes to the application, but most organisations will typically differ from the applications B2B orientated focus. For example, if you are working within a B2C business process, creating an Account record may not make sense, given that this is typically used to represent a company/organisation. Or, conversely, you may want to jump straight from a Lead to a Quote record. Both of these scenarios would require bespoke development to accommodate currently within CRM/D365CE. This can be broadly categorised into two distinct pieces of work:

  1. Modify the QualifyLead message during its execution to force the desired record creation behaviour.
  2. Implement client-side logic to ensure that the user is redirected to the appropriate record after qualification.

The remaining sections of this post will demonstrate how you can go about achieving the above requirements in two different ways.

Our first step is to “intercept” the QualifyLead message at runtime and inject our own custom business logic instead

I have seen a few ways that this can be done. One way, demonstrated here by the always helpful Jason Lattimer, involves creating a custom JScript function and a button on the form to execute your desired logic. As part of this code, you can then specify your record creation preferences. A nice and effective solution, but one in its guise above will soon obsolete as a result of the SOAP endpoint deprecation. An alternative way is to instead deploy a simplistic C# plugin class that ensures your custom logic is obeyed across the application, and not just when you are working from within the Lead form (e.g. you could have a custom application that qualifies leads using the SDK). Heres how the code would look in practice:

public void Execute(IServiceProvider serviceProvider)
    {
        //Obtain the execution context from the service provider.

        IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));

        if (context.MessageName != "QualifyLead")
            return;

        //Get a reference to the Organization service.

        IOrganizationServiceFactory factory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
        IOrganizationService service = factory.CreateOrganizationService(context.UserId);

        //Extract the tracing service for use in debugging sandboxed plug-ins

        ITracingService tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService));

        tracingService.Trace("Input parameters before:");
        foreach (var item in context.InputParameters)
        {
            tracingService.Trace("{0}: {1}", item.Key, item.Value);
        }

        //Modify the below input parameters to suit your requirements.
        //In this example, only a Contact record will be created
        
        context.InputParameters["CreateContact"] = true;
        context.InputParameters["CreateAccount"] = false;
        context.InputParameters["CreateOpportunity"] = false;

        tracingService.Trace("Input parameters after:");
        foreach (var item in context.InputParameters)
        {
            tracingService.Trace("{0}: {1}", item.Key, item.Value);
        }
    }

To work correctly, you will need to ensure this is deployed out on the Pre-Operation stage, as by the time the message reaches the Post-Operation stage, you will be too late to modify the QualifyLead message.

The next challenge is to handle the redirect to your record of choice after Lead qualification

Jason’s code above handles this effectively, with a redirect after the QualifyLead request has completed successfully to the newly created Account (which can be tweaked to redirect to the Contact instead). The downside of the plugin approach is that this functionality is not supported. So, if you choose to disable the creation of an Opportunity record and then press the Qualify Lead button…nothing will happen. The record will qualify successfully (which you can confirm by refreshing the form) but you will then have to manually navigate to the record(s) that have been created.

The only way around this with the plugin approach is to look at implementing a similar solution to the above – a Web API request to retrieve your newly created Contact/Account record and then perform the necessary redirect to your chosen entity form:

function redirectOnQualify() {

    setTimeout(function(){
        
        var leadID = Xrm.Page.data.entity.getId();

        leadID = leadID.replace("{", "");
        leadID = leadID.replace("}", "");

        var req = new XMLHttpRequest();
        req.open("GET", Xrm.Page.context.getClientUrl() + "/api/data/v8.0/leads(" + leadID + ")?$select=_parentaccountid_value,_parentcontactid_value", true);
        req.setRequestHeader("OData-MaxVersion", "4.0");
        req.setRequestHeader("OData-Version", "4.0");
        req.setRequestHeader("Accept", "application/json");
        req.setRequestHeader("Content-Type", "application/json; charset=utf-8");
        req.setRequestHeader("Prefer", "odata.include-annotations=\"OData.Community.Display.V1.FormattedValue\"");
        req.onreadystatechange = function () {
            if (this.readyState === 4) {
                req.onreadystatechange = null;
                if (this.status === 200) {
                    var result = JSON.parse(this.response);
                    
                    //Uncomment based on which record you which to redirect to.
                    //Currently, this will redirect to the newly created Account record
                    var accountID = result["_parentaccountid_value"];
                    Xrm.Utility.openEntityForm('account', accountID);

                    //var contactID = result["_parentcontactid_value"];
                    //Xrm.Utility.openEntityForm('contact', contactID);

                }
                else {
                    alert(this.statusText);
                }
            }
        };
        req.send();
        
    }, 6000);     
}

The code is set to execute the Web API call 6 seconds after the function triggers. This is to ensure adequate time for the QualifyLead request to finish and make the fields we need available for accessing.

To deploy out, we use the eternally useful Ribbon Workbench to access the existing Qualify Lead button and add on a custom command that will fire alongside the default one:

As this post has hopefully demonstrated, overcoming challenges within CRM/D365CE can often result in different – but no less preferred – approaches to achieve your desired outcome. Let me know in the comments below if you have found any other ways of modifying the default Lead Qualification process within the application.

When Server-Side Synchronization (Server-Side Sync) was first introduced in Dynamics CRM 2013, I imagine that lots of application and email server administrators breathed a huge sigh of relief. The feature greatly simplified the amount of effort involved in integrating On-Premise/Online CRM instances with their equivalent Exchange Server versions. Previously, the only way of achieving such an integration was via the E-mail Router, a cumbersome application that provided limited integration between email servers and CRM (i.e. no synchronization of items such as Tasks, Appointments, and Contacts). Granted, the E-mail Router was desirable if you were running a non-Exchange based Email Server, but having to provision a dedicated computer/server as the “intermediary” for all email messages to flow through could start to make a simple application deployment grow arms and legs very quickly.

Since the addition of Server-Side Sync, the feature has been continually updated to make it more versatile and the de facto choice for getting your emails tagged back into CRM & Dynamics 365 for Enterprise (D365E) – to the extent that the Email Router will shortly be extinct. Server-Side Sync now supports hybrid-deployments (e.g. D365E Online to Exchange On-Premise and vice-versa), has been expanded to include other Email protocol types and is now tailored to provide easier mechanisms for diagnosing mail flow issues from within the application itself. The last of these developments is best epitomised by the introduction of the Server-Side Synchronization Monitoring dashboard, introduced in CRM 2016 Update 1:

With this Dashboard, Administrators now have a simplified means of monitoring the health of their Server-Side Sync settings, facilitating the easy identification of problematic mailboxes, mailboxes that have failed a Test & Enable and those that have a recurring error being generated on them. Having all of this information at our fingertips enables CRM administrators to much more proactive in managing their health of their instance.

When recently working within some D365E organizations, which were originally provisioned as Dynamics CRM Online 2015 instances on the same Office 365 tenant, I noticed that the above Dashboard was missing:

Therefore, when clicking on the appropriate button in the sitemap area, an alternative Dashboard is loaded instead (either the user’s favorite Dashboard or a random one instead). So the question was – where has the Dashboard gone?

It turns out that the reason for its absence is down to an error as part of a previous major version upgrade, and is an issue that may be encountered by CRM Organisations provisioned a few years back. After escalating to Microsoft Support for further assistance, we were able to find a workaround to make the Dashboard available on the instances that were missing it. The steps involved are relatively straightforward, but in our case, we did have to resort to a spare trial/demo instance available that had the Dashboard installed successfully. The workaround steps are as follows:

  1. Log into an instance that contains the Dashboard. Go into Customizations and rename the Dashboard (doesn’t matter what you call it, as long as it’s not the same as the default name).
  2. Create a new unmanaged Solution and add in the renamed Dashboard. Export the solution as an Unmanaged Solution.
  3. Import the Solution into the instance that is missing it.
  4. Attempt to access the Dashboard and verify that it loads successfully.

You may be wondering why the Dashboard needs to be renamed before exporting. When attempting to import this Dashboard into any target instance with its default name, the component is automatically skipped during the import process. A Microsoft engineer advised that this is because an instance with the missing Dashboard actually thinks it is there and therefore does not try to import and overwrite a system component with the same name.

For the benefit of those who may also be experiencing the same issue and do not readily have access to another CRM/D365E instance, I have uploaded below two unmanaged solution files for the previous two versions of the application:

Version 8.1 (Dynamics CRM Online 2016 Service Pack 1)

Version 8.2 (December 2016 update for Dynamics 365)

The solution is a simple 1 component solution, containing a renamed version of the Server-Side Synchronization Monitoring Dashboard:

Once you have downloaded your Solution of choice above, follow steps 3-4 above and then go into Solution and the Dashboard to rename it from Copy of Server-Side Synchronization Monitoring -> Server Side Synchronization Monitoring. The application will accept the changes and it will be as if you always had the Dashboard there in the first place 🙂

It seems strange that this issue occurred in the first place, and I suspect I may not be the only one who has faced it recently. The Microsoft engineer I spoke to seemed to confirm that they’ve had this type of issue crop up several times previously, which makes it strange that this has not been acknowledged as a bug, either within the application itself as part of the twice-yearly upgrade processes. Notwithstanding this fact, it is good that an established workaround can be applied to fix the issue.

With the dizzying array of cloud-hosted applications and database systems available to IT system administrators today (often deployable at a few button clicks), you may be forgiven for thinking that Microsoft Access has joined the ranks of InfoPath, Visual FoxPro and other semi-legendary deprecated applications. Far from it – Access is still a mainstay within most Office 365 subscriptions today, alongside Word, Excel etc. What’s more, if you are looking to develop a very simple application to be utilised within your organisation, you would be hard-pressed to find an equivalent product at the same price point that would do the job as well. Here are just a few reasons on why Access is great.

  • It has the ability to connect to a wide variety of data sources – SQL, SharePoint and others – as well as letting you store data within Access itself.
  • The application contains rich customisation options for forms, buttons and other controls, enabling you to tailor the interface to suit a wide variety of business requirements.
  • Access has full support for Visual Basic for Applications (VBA), giving you the further potential to integrate complex logic when building your Access application.

Although there was some concerning news recently regarding Access within SharePoint Online, that looked like the writing on the wall for Access, quite the opposite effect seems to be happening. The application is being continually updated within Microsoft, with one of the latest of these updates catching my attention:

Last November, we shared our plan to add a set of modern data connectors that will enable Office ProPlus customers to expand what is possible in their organizations.

Today, we are pleased to announce the addition of two new connectors in our portfolio: Microsoft Dynamics and Salesforce. These two connectors are rolling out to customers with Office 365 ProPlus, E3, or E5 plans.

To clarify, Microsoft Dynamics in this context refers to the Dynamics 365 for Customer Engagement (Dynamics CRM) application, and not any other product within the newly revamped Dynamics 365 family. Getting started with the new data connectors is fairly easy, and may be useful for your business to look at more closely. With this in mind, let’s take a look at how to setup a straightforward Access application that links with Dynamics 365.

Before we begin…

At the time of writing, the new data connectors are only available for those who on the First Release branch of Office ProPlus, something which has to be explicitly enabled on the Office 365 Admin centre. As part of this, you may need to reinstall your Office applications (like I did) to ensure that this kicks in correctly.

Once you’ve verified that you’re on the correct Access version, you can then proceed to create your Dynamics 365 “powered” Access app…

Open up Access and create a brand new Blank database app called Contact Management.accdb, saving it in a location of your choosing:

A blank Access app will be created with an empty Table (this can be safely deleted). Navigate to the External Data tab on the Ribbon and select the From Dynamics 365 (onlineexternal data source:

A pop-up will appear, asking for your Dynamics 365 application URL and how you want to store the data within Access – take a one-time copy of it (Import the source data into a new table in the current database) or connect directly (Link to the data source by creating a linked table). Select the 2nd option, which I would always recommend to select:

Access will then attempt to retrieve a list of the Entities within the application. You may also be asked to log in using your Office 365 credentials, but based on my testing, it seemed to automatically pick these up from my currently logged in Office 365 account for activation – which is nice 🙂

The Link Tables window will then return a list of the entities that you are able to select. In this example, select Contacts and then press OK.

Access will then begin importing the table definitions and the underlying data, which can take a few moments. It is worth noting that Access will also automatically import tables for each N:1 entity relationship for your chosen Entity. This is to allow you to effectively query for “friendly name” information, as opposed to returning the rather ugly looking Globally Unique Identifier (GUID) values for each relationship:

With our data successfully imported, we can then start to build out a Form to enable users to interact with and change records. The quickest way of doing this is via the Form Wizard, which can be found on the Create tab:

By following the Wizard’s instructions. we can select the fields we want on our new form…

…our preferred layout…

…and then, finally, our form name:

Clicking on Finish will load up our newly created Form. From there, we can run a test by adding a Mobile Number value to the Marissa Burnett sample Contact record and then verify this appears successfully on Dynamics 365 after saving:

Conclusions or Wot I Think

The role of Access within the wider context of Microsoft’s offerings is one that has been increasingly open to question in recent years. The debut of exciting new solutions such as PowerApps and Dynamics 365 for Business, does make you start to think whether Access will be for the “chop” in the near future. By adding the new Dynamics 365 for Customer Engagement and Salesforce connectors, along with the other updates that are continually being rolled out for the application, Microsoft makes it clear that for, the time-being, Access is very much here to stay. The reasons for this can be perhaps garnered from my opening comments – it still remains a very versatile way of building quick to deploy, database vendor agnostic solutions that are tailored for desktop use within businesses of any size globally. Another reason for its mainstay – and the release of these new connectors – could be seen as a stealthy means of getting organisations slowly moved across to solutions like Dynamics 365, without the need of moving everything across in one go.

Whatever the reason(s), we can be encouraged by the fact that Access is very much being actively developed, even within the current landscape of varying CRM/ERP solutions. And, what’s more, it’s very cool to be able to say that Dynamics 365 for Customer Engagement is Access compatible 🙂