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 🙂

We saw previously on the blog some of the great features that you have at your disposal when using Office 365 Groups in conjunction with Dynamics CRM/Dynamics 365 for Enterprise. When deployed prudently, they can massively enhance what is traditionally possible via distribution groups and give internal/external users a better way to collaborate with content, as opposed to a mountain of email attachments. As I cautiously hinted towards in the above post, some thought should go into how you go about rolling out Office 365 Groups across your organisation, which should inevitably include internal testing. By doing this, you can highlight a particular functionality quirk that you will more than likely need to address before issuing a general rollout.

When you first go to create an Office 365 Group, you will notice that the domain address of the newly created group mailbox has defaulted to the onmicrosoft.com domain for your Office 365 tenant, instead of any bespoke domain you may have setup on your tenant:

You would think that this is caused by the fact that the Default Domain for the tenant is still set to the onmicrosoft.com domain, as we can see below:

However, after changing this accordingly, we are still forced to create a Group email address that utilises the onmicrosoft.com domain:

Rather frustrating! Fortunately, there is a way in which we can get around the issue, which involves two steps if you have existing Office 365 Groups that need renaming:

  1. Modify the Email Address Policy for your tenant via PowerShell to force new Groups to use your desired domain.
  2. Update the SMTP address of all existing groups via PowerShell.

Both of these steps will now be demonstrated, but be sure to have PowerShell installed on your machine first before you begin.

Connecting to your Office 365 tenant

Start your PowerShell client as an Administrator (Run as Administrator option on Windows) and execute the following command first to ensure all subsequent scripts run correctly:

Set-ExecutionPolicy RemoteSigned

You should receive a prompt similar to the below:

Press to proceed

Now we are ready to connect to Exchange Online, using the following cmdlets:

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session

You’ll be prompted to enter credentials to authenticate:

Make sure the credentials used have the relevant privileges on Office 365 and then hit OK. After a few moments, you should see a window similar to the below, which indicates that you have successfully connected and have all the Exchange Online cmdlets at your disposal:

Set Default Email Policy for Office 365 Groups

Modifying Office 365 to use a different domain when creating Office 365 Groups requires invocation of the New-EmailAddressPolicy cmdlet, a broad brush command that is useful for a number of different Exchange management scenarios. The command can be specifically tailored to create a policy applicable to Office 365 Groups, basically telling your tenant which SMTP domain to use when creating new Groups:

New-EmailAddressPolicy -Name Groups -IncludeUnifiedGroupRecipients -EnabledEmailAddressTemplates "SMTP:@mydomain.com" -Priority 1

You can tell if the command has executed successfully if you see something similar to the below in your PowerShell window:

Next, we can then verify that Office 365 has detected the change by creating a new Group and verifying that the Email address value reflects our desired domain:

Rename Existing Office 365 Group

Assuming you are just starting out with Office 365 Groups, the simplest way of renaming your existing groups would be to recreate them. This may not work if they are already being utilised, given the level of effort involved in migrating existing content across to a new group. In this scenario, there is an additional cmdlet we can rely upon to change the SMTP address of our group to our desired domain:

Set-UnifiedGroup -Identity "Test Office 365 Group" -PrimarySmtpAddress test@mydomain.com

PowerShell will only return a message in case of an error, so to verify our changes have taken place, we must again return to Office 365 to confirm that the new SMTP address is in place:

With this now updated, email messages should flow successfully to the new Group SMTP address.

Conclusions or Wot I Think

It is rather strange that there are no obvious means of specifying which default domain should be used with newly created Office 365 groups, nor at the fact that there is any way for the user to override their choice so they can select a domain that is available on the tenant. As discussed at the start of this post, this situation provides an excellent argument for ensuring that proper processes are followed for the introduction of all new technologies within the business. Whilst exciting and innovative solutions should always be duly considered and not hampered from being rolled out, it is crucial that an appropriate amount of time is allocated for thorough testing. The last thing you want to do, in reference to this situation, is to cause irritation to end users by not giving them the ability to present a professional and correct domain name for their Office 365 Groups; by running through some test scenarios and involving end users as part of this process, where possible, you can help to prevent issues resulting from a roll out and (hopefully!) enthuse colleagues within your organisation at the new piece of technology that is being introduced.

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