Deployment Best Practices Guide

Best Practices When Deploying Safeguard Send for Microsoft 365

Safeguard Send for Microsoft 365 is a powerful tool that helps you secure your emails, protect against data loss (DLP), and avoid disclosing sensitive information (spills), especially when sending emails to external domains. The tool uses rules to capture your conditions and to provide the warning prompt text. You can have multiple different rules for different scenarios. The tool can warn you about various issues, such as sending to restricted domains, sending social security numbers or other personally identifiable information (PII), or sending emails with sensitive or classified keywords. If you are migrating from the original desktop version of Safeguard Send to the new version, here are some best practices that you can follow.

Plan Your Rules

Plan ahead – before migrating to the new version of Safeguard Send for Microsoft 365, it’s important to plan ahead. You should begin by deciding which rules you are going to implement along with the actions. The new version of Safeguard Send for Microsoft 365 comes with a dashboard that allows you centralized control over the add-in for yourself or your entire company. You can also customize the text of the warning prompt, add a BCC recipient, or prevent the email from being sent until the user corrects the mistake. A vision for what you want to accomplish with the add-in is important in this step.

Plan Your Deployment

You will also want to consider when to uninstall the original desktop version, keeping in mind that if both the desktop version and the new Microsoft 365 version are installed, then the users will see two warning prompts. At the same time, be aware that deployment from the Microsoft Admin Center can take anywhere from 24-48 hours before users begin seeing the warning prompt according to this article from Microsoft.

In general, it’s best to uninstall the traditional desktop add-in on say, a Friday afternoon, and then begin the deployment of the new version that same afternoon. This way, the cache has the entire weekend to propagate it’s changes. It doesn’t matter that it’s over a weekend, just as long as users are aware that there may be gap wherein the warning prompts do not occur while the rollover from the old version to the new version occurs.

One caveat to the above plan – it is now possible to run both the desktop version of the add-in (Safeguard Send) alongside the newest version of the add-in (Safeguard Send for Microsoft 365). The idea is that desktop Outlook will look for the traditional Safeguard Send add-in first to see if it is installed and if so, will use that. If it is not found, then it will fall back to the new version of the add-in. In this case, if using Outlook on the Web or if you are on a Mac, then the new version of the add-in will always take precedence. If you prefer this scenario, please contact us so that we can create a custom manifest file for you, which is required to take advantage of this feature.

Plan Your Communications

Next you will want to identify the users who will be affected by the migration and begin to communicate with them about the changes. What are you going to tell your users

In general, like all good communication, you will want to let them know about changes that are coming (and when) and what to expect (like side by side screenshots of the original Safeguard Send prompt and a sample of the new Safeguard Send for Microsoft 365 prompt), then let them know about what’s currently happening (as it is deployed), and a final communication after deployment to let them know that it is now deployed, what to expect when they send an email and how to handle any issues going forward.

These three communications (before, during and after deployment) serve as important training for your users on how to use the add-in. Most of your users will already be used to the original warning prompt so while the new prompt will look different, the purpose remains the same. Nonetheless it can be useful to provide users with a link to a corporate page that has helpful information like what to do if you can’t send an email, what to do if you were (or were not) prompted when you supposed to be (or not), and how to get in touch with IT regarding issues with the add-in.

Sample Deployment Email Templates

To help get you started, we have sample email templates for all three phases that cover the who, what, when, where, and why that users will need to know.

As discussed, there are three emails you can send to your users to help ease their transition and communicate to them.

The first email is one for IT managers to send to their users regarding the migration announcement and when it is expected to occur.

The second email can be sent as a reminder to users about what is going to happen and what to expect.

Finally, the third email can be sent to let the intended audience know that it has been deployed, what to expect when sending an email, and how to handle any issues going forward.

Which of the below sets of emails you use as a template depends on whether you have an existing Windows desktop version of the add-in installed already, as these emails also discuss the termination of that older add-in to the new version of the add-in.

If this is a brand new deployment:
Email 1: Upcoming Changes To Your Email Process
Email 2: Reminder: Upcoming Changes To Your Email Process
Email 3: Email Changes Complete

If you already have an existing installation:
Email 1: Upcoming Email Migration
Email 2: Reminder: Upcoming Email Migration
Email 3: Email Migration Complete

Test, Test, Deploy

Before deploying the new version of Safeguard Send for Microsoft 365, it’s important to test it in a non-production environment. This will help you identify any issues or conflicts that may arise during deployment. In fact, in general it’s best to implement a three phase deployment.

In the first phase, start with a small team of users who are well versed in what to expect when using the new version of the add-in so that if anything unexpected occurs, they will be able to notice and have the ability to take action. If you are planning on using the reporting feature, it is during this phase that you would want to check the reports being generated in the dashboard to make sure that you are getting good actionable results.

After a time, the testing team can be expanded to include even more users or even a single department or branch in a second phase. It is during this second phase that you will want to identify any potential areas of concern for example, departments using a different domain or anyone using any in-house macros or other vendor add-ins (especially when sending emails).

Finally in the third phase, the deployment to all users can occur (keeping in mind the communications to all users in the Plan Your Communications step above).

Other Deployment Considerations

By default, once the add-in rolls out to everyone Outlook prevents any emails from being sent if there are any network issues or other problems reaching the add-in. However, this behavior can be changed to still allow the email to be sent by following the Microsoft provided instructions at On-send feature for Outlook add-ins – Office Add-ins | Microsoft Learn.

You might want to consider this option carefully. Deciding which option to default to (either allow the Send to occur or block the Send until the issue is resolved) is a function of the importance of getting your emails sent versus the risk of sending that email without being fully vetted.

Conclusion

Although deploying the Safeguard Send for Microsoft 365 firm wide can seem like a daunting task, breaking it down into manageable steps and planning each step along the way can take the hassle out of deployments.

Now that you have a plan, you can take concrete steps to deploy the add-in.