For part 8 of this blog series, I want to talk a little bit about Email governance in Dynamics 365. This is not specific to the App for Outlook, however, with tracking and promoting Outlook data into Dynamics 365 comes additional consideration around security of who should see the tracked data. I will not be going in depth to the solutions, but providing a high-level overview of options I have encountered. If you are using or have seen something different, feel free to share in the comments section.
The business and security requirements should always be reviewed within your organization so that you can assess all available options. The options around email governance are not limited to this list, however, these are some of the scenarios I have seen tested or put in place to assist with meeting different business requirements.
What options do I have for Email Governance to restrict or filter email information from being seen within Dynamics?
In most cases I have seen, this is tied to the content of the email or appointment, but sometimes extends to the attendees of a meeting as well.
The first option that should be evaluated is using the standard security structure within Dynamics, using business units, security roles, teams and sharing. This includes Owner Teams, Access Teams, and cascading shares through relationships. Hierarchy security is another option that should be considered. This could be based on Managers or Positions. Remember that team access and sharing can also be done programmatically, so this can become considerably complex if the requirements call for it.
The second option, which is still part of basic out-of-box functionality is Field Level Security. In this case, enabling Field Level Security on the Description field. By creating a field security profile for this field, you can specify which users can see or edit the data. If they are not added to a profile, the data will be masked completely and it will not be accessible through reports or Advanced Find. However, this does not change visibility on the Exchange/Outlook side
Field Security is enabled on the field definition:
In the Field Security Profile, you must add a user to the profile and give them access to Read the field. The default is No.
The Description field of the email would appear masked for users that do not have Read access, as you see below:
The data is not available through Advanced Find either:
As a user with the System Administrator role or a user that has been given Read access, you would see the following:
The third option is using workflows. You could use a simple workflow to remove the body of the email on incoming emails. You could also do this for Sent emails, but the logic in the workflow would have to be different, so it is cleared after it is sent.
I have also seen a custom workflow used to archive the email data in a separate entity that is only accessible by administrators or a group of users specified. In this case, a workflow would copy the email body from the original email to a new record and field in a custom entity, and then would delete the Description content on the original email. You may also need to copy other data on the email to correlate back for any audit purposes. This process does not remove the body of the email in Outlook.
The email in Dynamics would appear with a blank Description field like below:
I would not recommend doing this for appointments due to multiple moving pieces with synchronization. Many will use Field Security or other features such as a related appointment notes entity restricted with security.
The fourth option also includes using a workflow along with a custom sensitivity field and business rules. You would create a sensitivity field on the email or appointment form with values that match the business needs and requires. Based on the values selected, use a workflow, business rule, or JavaScript to display, hide, remove content as needed
Another example, is where there may be scenarios where the content can only be visible to specific users based on who is in the To or From lines (sender and recipients).
For this, one could use JavaScript to validate the sender and recipients and determine the fields to hide.
A more simple way to do this is to:
- Create a workflow that validates the sender or recipients and incoming direction
- If it meets certain criteria, change the email status to draft
- Copy the email description field into a separate field that is Field Security enabled
- Then clear the content of the default description field
- Flip a custom flag on the record and use a business rule to show the new field and hide the old field if that flag is marked
The only issue with this is when you copy from the description field on an email, it will copy all of the HTML tags along with it. So a custom workflow would have to be used here to strip out the HTML characters.
An example of a workflow, without removing the HTML characters would look like below.
Here, we check the Sender and if it matches a certain user or contact and it is an incoming email, then we change the status to draft, update the email and change the status back to Received.
Here is the update of the email, where we set the Sensitivity, copy the Description value to the new Field Security Enabled field, and clear the default Description field.
This is the outcome without using a business rule to hide the original description field. You can see the characters that would need to be stripped out, as highlighted below:
Again, these are just some options I have seen put in place to get you thinking of the different ways you can control email visibility within Dynamics.
Check out the rest of the series below:
Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7
Thank you for reading!
Aaron Richards