Even with the best will in the world, objects that we own or operate will sometimes break down completely. In these occasions, after typically spending an inordinate amount of time attempting to resolve things ourselves, we refer to others who have the expertise and ability to provide a fix. Often, this will come at a price and, depending on the nature of the issue and how it’s ultimately resolved, you will walk away happy as Larry or anything but.

Dynamics 365 for Enterprise (D365E) applies very much to the scenario illustrated above. As an application system developed and, in most cases, hosted by Microsoft, you will occasionally come across issues that cause the application to be inoperable or prevent you from carrying out a specific task. In these instances, we generally need to raise our hands and get someone from Microsoft involved to help out. The routes available to do this can vary, meaning you have to consider carefully which option is best for your business.

In this week’s post, we will take a closer look at the different support offerings that are available to D365E customers, what you get as part of each one and the pros/cons of each offering. If you are currently in the process of evaluating which support option is best for you, then this post will (hopefully!) leave you much better equipped to determine the best option for your /organisation.business

Standard Support

All subscriptions on Office 365 include access to Standard Support, generally amounting to the ability to open support requests on the portal and getting assistance to resolve issues with a particular application/service. D365E is no exception to this rule, and organisations can be comforted in knowing that they are covered from a support perspective the second after they purchase their subscription. However, unless you already have dedicated expertise within your business on how to operate the application, do not expect this service to be an effective hand-holder through your early days with the application. The priority level for Standard Support requests is low and will generally be routed to Microsoft affiliates as opposed to dedicated support professionals within Microsoft itself. Nevertheless, Standard Support does provide you with the ability to get your critical issues with D365E resolved.

Pros

  • Included in your subscription.
  • Guaranteed resolution for all break/fix issues.

Cons

  • Responses are only guaranteed within 24 hours of first raising the case.
  • Support provision can generally be lacklustre and cumbersome to deal with.

Enhanced Support

For smaller businesses, often the cost of obtaining more streamlined support provision for internal applications can be prohibitively expensive. Enhanced Support attempts to try and overcome this by providing a very cost effective means of putting in place a 2-hour SLA response time for any support requests raised involving D365E. This is definitely a huge improvement over what is offered as part of Standard Support. If your business has made a firm commitment not to align yourself with a Partner, then I would strongly recommend looking at Enhanced Support to keep you afloat while using D365E.

Pros

  • 2 hour response time guaranteed for all service requests.
  • Grants access to CustomerSource, an online repository of training resources to help you brush up on your D365E expertise.

Cons

  • As a paid offering, each user in your organisation will require the appropriate add-on subscription to ensure compliance. The additional cost (amounting to a few extra £’s per month) will, therefore, need to be factored into your monthly budget.
  • Provides in-hour support only, with no guarantee of a response/action outside of normal business hours.

Professional Direct Support

Professional Direct Support is best geared towards medium to large size organisations or those that require the peace of mind of having speedy responses to any problems. The 1 hour SLA represents the pinnacle response time that Microsoft customers can receive and the offering is also enhanced further via access to a dedicated person within Microsoft who will look after you and ensure your requests are being dealt with effectively. Unlike Enhanced Support, you also have explicit access to 2nd line support professionals within Microsoft, with a commitment towards priority escalation to engineers when a serious problem is identified. Professional Direct Support is the best support offering to go for if you place significant value within your D365E investment and want to align your support provision very closely with Microsoft.

Pros

  • 24×7, 1 hour guaranteed response for all of your issues
  • Access to a Service Delivery Manager within Microsoft, as a point of contact for all support requests and to provide ongoing review of your support experience.

Cons

  • Costs an additional £6.80 per month on top of your existing D365E subscriptions
  • Cannot be relied upon to provide in-application support (e.g. entity customisations, plugin development etc.)

Working with a Partner

Partners are perhaps a natural choice for medium to large size organisations who cannot afford to have the dedicated expertise in-house to manage their D365E deployment, but are looking for a cost-effective way of having this knowledge at their disposal. Dynamics 365 partners are plentiful, and many of them can prove to be a lot less daunting to deal with day-to-day compared with Microsoft directly. They will likely have lots of combined expertise across different areas of the product and will be able to tailor a support offering that suits your requirements more neatly than Microsoft can. The key thing to remember when choosing your partner is to ensure that they have an Advanced Support for Partners (ASfP) or Premier Support for Partners (PSfP) agreement in place with Microsoft. Why is this important? By being enrolled within one of these offerings, the partner has the ability to log support requests relating to your subscription with enhanced routing/SLA’s in place, meaning your request will be dealt with faster – in some cases, a 1-hour response is guaranteed for critical issues. The partner will also, arguably, be in a much better position to support you more generally, as both of these schemes afford ample opportunity for the partner to keep up to speed with everything that is happening with D365E.

Pros

  • Excellent resource to have in place for in-application issues (i.e. problems that don’t require escalation to Microsoft).
  • Low month-on-month investment, anywhere from £200-£700 or more per month, depending on the size or your organisation.

Cons

  • For any issues that require customisation/developer expertise to resolve, expect some punishingly expensive day rates for the work; in some cases, I have seen prices going up to £950 a day for a junior consultant(!!)
  • Does not benefit from any of the above offerings to help you as a business maximise your investment in D365E. You will be reliant solely on your partner of choice to provide this as part of the service (if in fact, they do at all).

Conclusions or Wot I Think

The myriad of support options presented as part of this post are very much designed to cater for organisations of different sizes, agendas and visions of how they see their D365E system at a strategic level. The list is by no means exhaustive too, as enterprise organisations can look at Premier Support as well. As this kind of support offering would generally involve provision for multiple Microsoft/Microsoft Online Services products, I have deliberately left it out this list, due to it very much being “overkill” for supporting a single application. What you are left with as part of this list is arguably 3 viable support options that can be recommended depending on which boat you are sitting in:

  • If you are a small business with sufficient technical expertise in-house, then the Enhanced/Professional Direct Support options are best.
  • If you are a larger organisation looking to very closely align yourself with Microsoft and are confident in your in-house technical ability, then Professional Direct Support is the one for you.
  • If you are a business of any size and very much don’t want to worry about managing and supporting your D365E system, then the Partner route is a very sensible approach.

The implication with all of the above is that the Standard Support option is not one that I would recommend you have in place. Whilst you can be assured that your critical issues will ultimately get looked into and resolved, you may find yourself waiting days and weeks for a resolution and not necessarily be afforded the most technically accomplished support professionals to assist you in resolving your case.

In the early days of working with Azure Virtual Machines, there was generally some effort involved in provisioning and maintaining storage for your machines, and a number of considerations that would need to be taken into account. Choosing the most appropriate storage type (Blob, File etc.), its location on the Azure network and the type of resiliency behind the data stored within…all questions that can leave you muddled and confused! What’s more, depending on which type of setup opted for, you could find yourself having to maintain a complex storage solution for what is ultimately a simplified deployment/workload.

The introduction of Managed Disks earlier this year is designed to solve these problems and provide a simplistic, easy-to-scale solution that does not require a high-degree of knowledge of Storage Accounts to successfully maintain. Upon creation of your virtual machine, a VHD disk is created for you; after that time, the only management you need to worry about is in specifying the size of the disk, which can be scaled to suit your requirements. Copies of the disk can be quickly created via snapshots as well, and these (and indeed the disks themselves) can be straightforwardly migrated to other Virtual Machines at a few clicks of a button. Definitely a much nicer and compact solution. 🙂

I was recently working with Managed Disks when deploying out a new Virtual Machine onto Azure. I like to follow a consistent naming convention for resources on Azure, so I was a little frustrated to see that the platform had opted to name the resource for me:

The values used are anything but “friendly” and appear to be the GUID for the object in the backend database! What’s that all about?!?

One of the things you have to remember with Azure resources is that the names cannot be adjusted once a resource is created; the only recourse in this scenario is to recreate the resource from scratch with the desired name. What’s worse is that you have no option as part of the Azure interface when creating your VM to specify a name for your Managed Disk. You only have the single option indicated below – Use managed disks:

So is there any way of being able to manually specify a disk name when creating a new Virtual Machine on Azure? If you don’t mind working with JSON, deployment templates and the currently in-preview Templates feature, then keep reading to see how to achieve this using an, admittedly, rather convoluted workaround.

To begin with, start creating your Virtual Machine as you would normally via the interface. When you get to the final screen (4 – Purchase), click on the Download template and parameters hyperlink that sits next to the Purchase button:

This will then open up the entire code-based template for your deployment settings – basically, a large JSON file with all of the settings that you have just selected through the interface. Click on the Add to library button at the very top of the window:

Selecting this will now enable you save this into your Azure account as a Template, thereby letting you open, modify and deploy it again in future – very handy features if you find yourself deploying similar resource types often. Specify a Name and Description for the Template and then click on Save:

Once saved, the Template can then be accessed via the Templates area on Azure, which can be searched and (optionally) pinned to your favourites:

After opening the Template, you then have the option to Edit it – this includes both the Name/Description values already specified and also the ability to modify the JSON file in-browser by selecting the ARM Template setting below:

Scroll down the JSON file until you get to the key/value pairs for osDisk. There should be two pairs existing there already: createOption and managedDisk . There is an additional setting that can be specified in this area to let you define the resource name. No prizes for guessing what this is called 🙂 By adding this key/value pair into the JSON file, as indicated below, we can ensure our preferred name is utilised when the resource is created:

 

Click Save on the Edit Template window and then verify that your changes have been accepted by the portal:

Now, by going back to the first window for the Template, we can deploy the VM and all its constituent components to the platform. One downside with this is that you will need to specify all of the other settings for your Virtual Machine, such as Location, Size, and names, again:

Once all your values have been validated and accepted, you can then click on Purchase to submit the deployment to the platform. After this completes successfully, we can then verify that our preferred Managed Disk name has been saved along with the resource:

It is nice to know that there is a workaround to enable us to specify a name for Managed Disks in our preferred format, but I would hope in future that functionality is added to the portal that lets you specify the name from within there, instead of making an arbitrary assumption on what the resource is called. Managed Disks are still very much in their infancy within Azure, so I am confident that this improvement will be implemented in future and that the feature is constantly reviewed to ensure the pain of provisioning Virtual Machine storage is almost non-existent.

This is the final post in my 5 part series focusing on the practical implications surrounding the General Data Protection Regulation (GDPR) and how some of the features within Dynamics CRM/Dynamics 365 for Enterprise (CRM/D365E) can be utilised to smooth your organisations transition towards achieving compliance with the regulation. In this week’s post, we will be delving deep into the murky world of Subject Access Requests (SAR’s) (a process that already exists within existing E.U. Data Protection legislation), some of the changes that GDPR brings into the frame and the capabilities of the Word Template feature within CRM/D365E in expediting these requests as they come through to your organisation.

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 jumping into the fun stuff, it’s useful to first set out the stall of what SAR’s are and to highlight some of the areas to watch out for under GDPR

A SAR is a mechanism through which an individual can request all information that a business or organisation holds on them. Section 7 of the UK’s Data Protection Act 1998 sets out the framework for how they operate and they are applicable to a wide variety of contexts – from requesting details from an Internet Service Provider regarding your account through to writing to an ex-employer to request what details of yours they hold on file. The types of information covered under a SAR can be quite broad:

  • Documents containing personal details
  • Emails
  • Call Recordings
  • Database Records

The effort involved in satisfying a SAR can be significant, typically due to the amount of information involved, and time will need to be put aside compiling everything together. You will also need to ensure certain types of information are redacted too, to prevent against an inadvertent data breach by revealing other data subjects details. It is for these reasons why SAR’s are typically seen as the bane of IT support personnel’s existences!

Be Aware Of The Implications Of Ignoring A SAR

Article 12 provides a broad – but nonetheless concerning – consequence should you choose to disregard or not process a SAR within the appropriate timeframes:

If the controller does not take action on the request of the data subject, the controller shall inform the data subject without delay and at the latest within one month of receipt of the request of the reasons for not taking action and on the possibility of lodging a complaint with a supervisory authority and seeking a judicial remedy.

Under current guidelines issued by the ICO for the Data Protection Act, the type of enforcement action include being mandated to process a SAR via a court order and even compensation for the data subject, if it can be proven that the individual has suffered personal damage through your lack of action. Whilst GDPR makes it unclear at the stage whether these consequences will remain the same or beefed up, organisations can make an assumption that there will be some changes under the new state of play, particuarly given that enforcement actions have been developed significantly in other areas (e.g. data breaches).

Overrall, SAR’s remain largely the same under GDPR, but there are a few subtle changes that you should make note of:

  • Most organisations currently will charge an “administration fee” for any SAR that is sent to them. GDPR does not specifically mandate that organisations can levy this charge anymore, so it can be inferred that they must now be completed free of charge. An organisation can, however, charge a “reasonable fee” if the data subject requests additional copies of the data that has already been sent to them (Article 15) or if requests are deemed to be “manifestly unfounded or excessive” (Article 12).
  • All information requested as part of an SAR must now be supplied within 1 month (as opposed to 40 days under existing legislation) of the date of the request. This can be extended to a further 2 months, subject to the organisation in question informing the data subject of the extension and the reason for the delay. Delays should only be tolerated in instances where the “complexity and number of the requests” exceeds normal situations (Article 12).
  • Organisations are within their right to request documentary evidence that the individual who has sent the SAR is the person they claim to be, via official identification or similar. This is useful in two respects: it enables an organisation to mitigate the risk of a potential data breach via a dishonest SAR and also affords the organisation additional time to process the request, as it can be inferred that the request can only be reasonably processed once the individual’s identity is confirmed.

The ability to expedite SAR’s in an efficient and consistent manner becomes a significant concern for organisations who are aiming to achieve GDPR compliance. But if you are using CRM 2016 or later, then this process can be helped along by a feature that any application user can quickly get to grips with – Word Templates

This feature, along with Excel Templates, is very much geared towards bridging the gap for power users wanting to generate reports for one or multiple record types, without having to resort to more complex means (i.e. SQL Server Reporting Services reports). I looked at the feature a while back on the blog, and it is very much something I now frequently jump to or advise others to within the application; for the simple reasons that most people will know how to interact with Word/Excel and that they provide a much easier means of accessing core and related entity records for document generation purposes.

To best understand how Word Templates can be utilised for SAR’s, consider the following scenario: ABC Company Ltd. use D36E as their primary business application system for storing customer information, using the Contact entity within the application. The business receives a SAR that asks for all personal details relating to that person to be sent across via post. The basic requirements of this situation are twofold:

  • Produce a professional response to the request that can then be printed onto official company stationary.
  • Quickly generate all field value date for the Contact entity that contain information concerning the data subject.

Both requirements are a good fit for Word Templates, which I will hopefully demonstrate right now 🙂

In true Art Attack style, rather than go through the process of creating a Word Template from scratch (covered by my previous blog post above), “here’s one I made earlier” – a basic, unskinned template that can be uploaded onto CRM/D365E via the Settings -> Templates -> Document Templates area of the application:

Subject Access Request Demo – Contact

When this is uploaded into the application and run against a sample record, it should look similar to the below:

Once deployed, the template can then be re-used across multiple record types, any future SAR’s can be satisfied in minutes as opposed to days and (hopefully) the data subject concerned is content that they have received the information requested in a prompt and informative manner.

Thanks for reading and I hope that this post – and the others in the series – have been useful in preparing your for GDPR and in highlighting some excellent functionality contained within CRM/D365E. Be sure to check out the other posts in the series if you haven’t done so already using the links below and do please leave a comment if you have any questions 🙂

Part 1: Utilising Transparent Database Encryption (TDE)

Part 2: Getting to Grips With Field Security Profiles

Part 3: Implementing & Documenting A Security Model

Part 4: Managing Data Retention Policy with Bulk Record Deletion

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