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.

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 🙂

Welcome to part 4 of my 5 part series looking at the practical implications surrounding the General Data Protection Regulation (GDPR) in the context of Dynamics CRM/Dynamics 365 for Enterprise (CRM/D365E). The series looks at how some of the features within this application can assist you in your journey towards GDPR compliance. This week’s post will be jumping across to an arguably underrated aspect of the application – Bulk Record Deletion and how it be used to satisfy your organisation’s data retention policy.

All posts in the series will make frequent reference to the text (or “Articles”) contained within Regulation (EU) 2016/679, available online as part of the Official Journal of the European Union – a particularly onerous and long-winded document. If you are based in the UK, you may find solace instead by reading through the ICO’s rather excellent Overview of the General Data Protection Regulation (GDPR) pages, where further clarification on key aspects of the regulation can be garnered.

As we get started, here’s a question for you: Do you know how long your organisation holds personal data for before it is deleted?

Most organisations that you speak to may struggle to provide an answer to the above question. The tendency is very much towards holding data for an indefinite period, with this approach typically being borne out of a lack of understanding of legal/contractual requirements, a result of a genuine oversight or as a necessary evil. The problem with any of these justifications is that, as well as falling foul of GDPR, it more than likely also is a contravention of your countries existing data protection legislation. In the UK, for example, Principle 5 of the Data Protection Act 1998 states clearly that “Personal data…shall not be kept for longer than is necessary…”. Despite being quite broad in its interpretation, it can be inferred very clearly that organisations should be aware of how long all of their data is held for and to have the appropriate documentary evidence to support this, via a policy or similar.

The existence of this principle demonstrates one of the areas where GDPR does not differ greatly from the Data Protection Act 1998. Article 17 covers all aspects concerning when and how data should be removed, under the broad principle of the “right to be forgotten”:

The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies:
(a) the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed;
4.5.2016 L 119/43 Official Journal of the European Union EN
(b) the data subject withdraws consent on which the processing is based according to point (a) of Article 6(1), or point (a) of Article 9(2), and where there is no other legal ground for the processing;
(c) the data subject objects to the processing pursuant to Article 21(1) and there are no overriding legitimate grounds for the processing, or the data subject objects to the processing pursuant to Article 21(2);
(d) the personal data have been unlawfully processed;
(e) the personal data have to be erased for compliance with a legal obligation in Union or Member State law to which the controller is subject;
(f) the personal data have been collected in relation to the offer of information society services referred to in Article 8(1).

To summarise, this means that organisations should remove information pertaining to data subjects when:

  • There is no further requirement to do so, either contractually or legally (i.e. they are no longer required to as part of a statutory instrument)
  • The subject has withdrawn their consent
  • It has been identified that data is being held which is at odds with an organisations policies or primary business activities

Article 5 extends this further by making it clear that data which you are unable to keep sufficiently accurate should be “erased…without delay”. To avoid this scenario would require the need to regularly contact the data subject concerned to verify their details are correct. One of the major “get out of jail free” cards that GDPR provides surrounding data retention is in instances where the data will be used as part of “archiving purposes in the public interest, scientific or historical research purposes or statistical purposes..” (Article 5). The scope of this is, as you can tell, rather limited and most non-governmental organisations/businesses may struggle to demonstrate their data archiving is in line with these broad principals.

The importance of ensuring a clearly defined and structured process for the removal of customer data, therefore, becomes a paramount concern under GDPR. Investigating and defining your organization’s data retention periods is an exercise that should be carried out if it has not been done so already. Once implemented, we can then turn to a component within CRM/D365E to automate and streamline the actual process – the Bulk Record Deletion feature.

In a nutshell, this feature is a really efficient means of deleting large amounts of predefined data within CRM/D365E. Administrators of the application will most often work with them when attempting to reduce the storage footprint of a CRM/D365E instance, via the removal of completed System Job records and other superfluous record types. The ability to define filter criteria, re-occurrence settings and to send out email notifications upon completion of a job, make them an excellent candidate to consider when streamlining your internal processes surrounding data retention.

For example, let’s assume your business has implemented a data retention policy that states Contact entity data that has not been updated or changed within 12 months should be deleted from the system. Setting up a Bulk Record Deletion Job within the application to assist with this task is remarkably straightforward, as the step-by-step guide below indicates:

  1. Within the application, navigate to Settings -> Data Management on the Sitemap and click the icon to navigate to the Data Management page:
  2. On the Data Management page, click on the Bulk Record Deletion icon to open the All Bulk Deletion Systems Jobs view. Once this has loaded, click on the New icon:
  3. The Bulk Deletion Wizard will open a pop-up window. Click Next on the first screen to move to the Define Search Criteria window. Modify the settings as follows:
    • Look for: Contact
    • Search Criteria: Modified On Older Than 365 Days

An example of how this looks can be seen below:

   

  1. Click Next when you are ready to navigate to open the Select Options page. Give the Bulk Record Deletion Job a descriptive name and then ensure that the following settings are configured:
    • Specify whether the Job should run immediately or in the future. It is recommended to schedule Jobs out of peak hours to prevent any performance detriment to other users.
    • Ensure that the Run this job after every box is ticked and then select an appropriate time period. I would recommend 30 days.
    • Ensure that the Send an email to me… box is ticked. You can also (optionally) specify additional email recipients, but note that these have to be valid application users (i.e. not any other email enabled entity such as Contact, Account etc.)

The screenshot below indicates how this should look. Click Next when you are ready to proceed:

  1. The final step in the wizard gives you the opportunity to review all configured settings. Press Submit to create the Job in the system and, if specified to start immediately, begin running it in the background. You can also navigate to the Recurring Bulk Deletion System Jobs view at any time to review the current status of a job, check to see when it is next scheduled to run or even modify its properties to suit your requirements:

 

The example above is a simplified one but could be extended further in conjunction with other features in the application to suit specific requirements. For example:

  • Create a custom entity to store contractual/statutory data retention limits and link these to your common entities within the application via a 1:N relationship. Once selected when a record is created, you can then define a workflow with a wait condition that updates a Two Option custom field on the entity as a flag for a Bulk Delete Job to remove from the system.
  • Using a custom field on your entity to indicate that a customer has expressed their “right to be forgotten”, define a workflow that sends a customer confirmation that their details will be removed from the system within 30 days and then use this same field as a flag for a Bulk Record Deletion Job.
  • Define a workflow that sends an email to owners of records that have not been modified within a set period (i.e. are inaccurate), prompting them to speak to the customer to update their details. Records that are not updated would then be deleted, using a Job similar to the one above.

Application features, such as the one discussed in this week’s post, really start to come into their element when you combine them with other tools found within the application. With this in mind, I would encourage you to roll up your sleeves to see what you can “cook” up 🙂

Thanks for reading! Be sure to check out the other posts in this series if you haven’t already using the links below. Part 5 next week will look at Subject Access Requests and how these can be processed more efficiently using CRM’s/D365E’s Word Template feature.

Part 1: Utilising Transparent Database Encryption (TDE)

Part 2: Getting to Grips With Field Security Profiles

Part 3: Implementing & Documenting A Security Model

This is part 3 of a 5 part series, where we take a closer look at the practical implications the General Data Protection Regulation (GDPR) has upon organisations/businesses in Europe and some of the ways Dynamics CRM/Dynamics 365 for Enterprise (CRM/D365E) can assist you as part of the transition. Last week, we saw how Field Security and Field Security Profiles can be utilised to protect sensitive data categories, complementing any existing security model you may have in place. In this week’s post, we are going to discuss the concepts that will enable you to utilise CRM’s/D365E’s security features to their fullest extent, as well as how this can be documented.

All posts in the series will make frequent reference to the text (or “Articles”) contained within Regulation (EU) 2016/679, available online as part of the Official Journal of the European Union – a particularly onerous and long-winded document. If you are based in the UK, you may find solace instead by reading through the ICO’s rather excellent Overview of the General Data Protection Regulation (GDPR) pages, where further clarification on key aspects of the regulation can be garnered.

Before we jump in further, let’s set the scene by looking at the importance of security and documentation towards achieving GDPR compliance

Article 5 of GDPR clearly states that all personal data must be “processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing…using appropriate technical or organisational measures“. This principle is embellished further by Article 24, which states:

Taking into account the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons, the controller shall implement appropriate technical and organisational measures to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation. Those measures shall be reviewed and updated where necessary.

The final sentence links in nicely with the requirements for clearly auditable and documented processes under GDPR (more on this shortly). Finally, Article 25 – which is subtitled Data protection by design and by default – places a clear onus on Processors to implement systems that “ensure by default personal data are not made accessible…to an indefinite number of natural persons“. In summary, clear thought and effort must be borne out to ensure that application systems not only restrict access to personal data on a “need to know” basis but also that these systems are reviewed and updated regularly; with, invariably, documentation forming an important bedrock towards this.

The need for clear documentation under GDPR is emphasised further over multiple articles in the Regulation:

  • If you are processing data on behalf of a controller, you must only do so based “on documented instructions from the controller” (Article 28).
  • Organisations can opt to become “GDPR accredited” to demonstrate compliance with the regulations (Article 24, 25, 28, 32 & Section 5). Such accreditations will likely require sufficient documentary evidence to successfully attain.
  • In situations where data is being transferred “to a third country or an international organisation“, all “suitable safeguards” must be clearly documented (Article 30 & 49).
  • All data breaches must be clearly documented (Article 33).

To summarise, it can be inferred, but not definitively said, that the documentation of security models and user access to data is a broad requirement to satisfy compliance with the Regulations. By comparison, sufficient organisational security measures, both physical and technical, are mandatory requirements under GDPR.

With all this in mind, let’s take a look at the four cornerstones of CRM/D365E security and some of the things to think about from a GDPR perspective: Users, Teams, Business Units and Security Roles

Users

There are no prizes for guessing what this is 🙂 Like with any application system, Users in CRM/D365E are the mechanism through which you log on, interact with and access partial or whole areas of the application. Users utilise the existing identity provider, Active Directory. The benefits of this are that a consistent end user experience can be assured from a login perspective (enhanced further via the implementation of Single Sign On solutions) and there is less management required within CRM/D365E. This is because key information will be synchronised from your Active Directory accounts, such as job title, email address and telephone number. Users begin to come into their element when used in conjunction with the three other “cornerstones” mentioned above, so will be referenced again shortly.

Key GDPR Takeaways
  • Users of your CRM/D365E should be reviewed regularly to verify that access is still required to information within the application.
  • As Users do technically contain personal data relating to employees, all sufficient measures should be taken to ensure that the data that is held within them is kept up to date (Article 5).
  • Appropriate organisational security measures should be put in place to ensure Users are protected against malicious access (e.g. scheduled password resets, multi-factor authentication etc.).
Teams

Teams provide a mechanism for grouping together multiple users under a clearly defined label. For example, you could have a Team called Sales Team that has the account manager Users Bob, Alice and Steve as members. There are two types of Teams that can be setup in the application – Owner Teams, which operate much the same way as a Users (e.g. records can be assigned to them) and Access Teams, which provide specific permissions/access to records. More information about both types can be found on this useful MSDN article.

Key GDPR Takeaways
  • Structuring Teams correctly in conjunction with Security Roles can provide a more streamlined means of managing appropriate levels of access for teams, departments or other groups within an organisation. This is due to the fact that Security Roles can be assigned to Owner Team records, similar to Users.
  • Access Teams require a much higher degree of ongoing management, as you will need to constantly review their membership to verify that only approved Users are members.
  • Reports can be quickly generated for records that are owned by a Team and/or which Users are part of a particular Access Team record via the applications Advanced Find feature. This can assist greatly in satisfying any ongoing documentation requirements.
Business Units

Getting to grips with how Business Units operate can be one of the major challenges when first learning about CRM/D365E. They provide a means of segregating data within your instance so that only Users that are part of a particular “unit” can interact with the records that most directly concern them. Business Units can be best understood and utilised when thinking about your organisation in the following terms:

  • Business Departments
  • Subsidiaries/Parent Companies
  • Regions

Taking the third of these examples, you could, therefore, look at having a “root” Business Unit, with “child” Units for each region that your organisation operates within. Users can then be moved into the appropriate Business Unit for their locality and, as a consequence, only have access to Account records that are situated within their location. Business Units are anything but an exhaustive subject, so I would strongly recommend reading up on the topic separately to gain a fuller understanding of what they are.

Key GDPR Takeaways
  • Business Units provide an effective means of satisfying Article 5’s requirements for data protection “by design and by default”.
  • Remember that Users may still be able to see records that do not exist in their current Business Unit if they have been assigned a security role that gives them Parent:Child or Organization privilege on the entity in question (more on this in the next section).
  • Each Business Unit will also have a corresponding Team created for it. These can be utilised to segregate out security permissions in a more centralised manner, as discussed above.
Security Roles

The most important cornerstone of security within your CRM/D365E instance and the “glue” that holds all other components together, Security Roles define the permissions for every feature and entity within the application, giving you the opportunity to fine tune access privileges on a granular basis. For example, you can grant a user permission to read all records within their current Business Unit, but only allow them to modify records that they directly own. Privileges are structured very much in line with how Business Units operate, with each individual permission (Read, Create etc.) having the following “levels” of access:

  • No Access
  • User Level – Can only perform the specified action on records owned by the User.
  • Business Unit Level – Can only perform the specified action on records within the same Business Unit as the current User.
  • Parent:Child Business Unit Level – Can only perform the specified action on records within the same or all child Business Units as the current User.
  • Organization Level – Action can be performed against any record on the system.

The potential is limitless with Security Roles and, if mastered correctly, they can satisfy a lot of the problems that GDPR may bring to the table.

Key GDPR Takeaways
  • Microsoft provides a number of default Security Roles out of the box with the application and it may be tempting to utilise these directly instead of modifying or creating new ones specific to your needs. I would caution against this, particularly given that the roles may end up having excessive privilege levels on certain record types and could, by implication, fall foul of several articles within GDPR.
  • Similar to how Teams can be used to represent teams or departments within an organisation, Security Roles can be best utilised when they are broadly structured to provide the minimum level of privileges needed for several Users or more. This can also reduce any a headache when it comes to documentation of these roles as well.
  • New versions of the application (which come out twice each year) generally introduce new functionality and – as a result – new permissions required to successfully utilise them. Assuming you are updating your application in line with Microsofts recommended approach, these opportunities can be the best time to review your existing security roles, to verify that they are current and do not contain incorrect privileges.

Quickly Generating Documentation of your Security Model

To assist you in gaining a “bird’s eye” view of your users and their access privileges, the application provides a means of achieving this – the User Summary report:

This report has been tucked away inside the application from many years, a fact that can be attested to below with its rather archaic look. Regretfully, it hasn’t received any love or attention as part of recent updates 🙁

Having said that, the report does have some nice features:

  • It can be configured to run on a specific Business Unit, thereby providing a more closely defined list of the Users/Security Roles.
  • Can be exported to PDF, Excel and other common file formats.
  • Provides full information about each User, including their job title (make sure you are populating this field on your Active Directory first to ensure this appears!).

If you have never run the report before, then I would strongly recommend that you check it out to determine whether it satisfies your documentation requirements around GDPR.

Hopefully, this post has given you a good flavour of what can be achieved within the application to fully build out a suitable security model within CRM/D365E. In next week’s post, we’ll look more carefully at the implications GDPR has surrounding data retention and how the Bulk Delete feature can be configured to automate this process. In the meantime, be sure to check out the other posts in the series if you haven’t already using the links below:

Part 1: Utilising Transparent Database Encryption (TDE)

Part 2: Getting to Grips With Field Security Profiles