Offboarding Policy and Process for Microsoft 365

From 1st August 2023 due to Microsoft deprecating Remote PowerShell (RPS) Protocol in Exchange Online we can no longer support the following steps: Delegate Access; Hide User; Assign Allias; Convert to Shared Mailbox. If you add these steps into your workflow after 1st August 2023 it will cause offboarding to fail.

One of the biggest concerns when users are leaving the business is the retaining of data that could be sensitive or crucial to upcoming events.

CloudM Automate provides a customisable offboarding policy and process which can be applied to your entire domain and using Smart Teams individual groups of users to match your business structure.

The workflow is a total of 21 steps that can be enabled or disabled as you require.

1. Request Approval
2. Prompt for Resource Allocation
3. Change Password
4. Revoke Application User's Accounts
5. Revoke OAuth Tokens
6. Set Out of Office Messages
7. Delegate Access
8. Hide User
9. Rename User
10. Assign Alias
11. Archive
12. Transfer Ownership of Documents
13. Migrate Calendar Events
14. Transfer Ownership of Groups
15. Transfer Contacts
16. Remove from Groups
17. Migrate Emails
18. Convert to Shared Mailbox
19. Unassign Licenses
20. Suspend User
21. Delete User

In this guide, we're going to go over each step and discuss the use and impact of each.

To navigate to the Offboarding Workflow screen and process

1. Click on Administrate > Offboarding Workflow
2. Select the Root OU (listed at the top of the list and denoted with an office block icon) or a child OU listed below the Root OU, or select the required Smart Team (from the Smart Teams tab).
   • All child OUs will automatically inherit the policy set from for the Parent OU unless you set an explicit Offboarding Policy.
   • All Smart Teams will automatically inherit the policy set for the Root OU unless you set to Enable. If a user is in multiple Smart Teams, the Offboarding Workflow for the user will be taken from the Smart Team set highest (in priority) on the Smart Team screen.
3. Where the OU is not the Root OU, select Explicitly set Offboarding Policy to edit the process for the selected Organizational Unit.
4. Select the Workflows settings tab.

or

1. Click Directory > Org Units or Smart Teams
2. Find and select the required OU or Smart Team to prompt the informational panel to be displayed
3. Click on the Configure button
4. Click on the Offboarding option
5. You will be taken to the Workflows actions tab (on Administrate > Offboarding Workflow) with the selected OU or Smart Team pre-selected.
6. Select the Workflows settings tab.
7. Where the OU is not the Root OU, select Explicitly set Offboarding Policy to edit the process for the selected Organizational Unit. Select Enable to edit the process for the selected Smart Team.

Workflow Settings

When configuring your Offboarding policy,  the first option in Workflow settings that you have available for selection is the ability to 'Automatically Offboard Suspended Accounts'. If this option is selected, as stated, any account within the OU where this option is active that is set to a 'suspended' state will be automatically offboarded in line with the rest of the defined policy steps. Accounts currently in a suspended state when this setting is enabled will not be offboarded. You will be required to offboard these accounts manually using the normal steps. 

During the offboarding process, we are required to remove the suspended state from an account to allow the system to process documents (e.g. transfer ownership of documents). When these steps are complete, we will automatically re-apply the suspended status to any account offboarded using this method. However, it is important to remember that if you have a large account, the period of time when the account is unsuspended maybe lengthy whilst documents and email are transferred. You must take steps to secure the account to ensure no unauthorised use.

Next, you must set the Executor. This is the person / account that will be required to make decisions during the offboarding process

The Executor can be set to one of the following:

• User's Manager or Domain Admin
• User's Manager or Specified
• User's Manager or Error
• Domain Admin
• Specified

After setting the executor, you will see several text fields that can be edited. These fields are the email subject lines that will be received when a user goes through the offboarding process. You can alter these so you can more easily setup a filter, or ensure the language is tailored to your organization. It does not have any impact on the offboarding process itself. 

Workflow Actions

At this point, you will then be able to specify which steps you want on your Organizational Unit's policy. Select the Workflow actions tab to see the actions that have already been inherited from the Parent OU. You can quickly remove steps from the current workflow (by selecting the Trash Can icon at the end of the row) and just as easily add steps by selecting the Add offboarding step button.

This will prompt a panel to slide in (replacing the Org Units list) from which you can select the required steps and they will automatically be placed in your current workflow in the required order. Select Save to confirm any changes.

The Offboarding steps are:

1. Request Approval - This is a basic Yes / No request of the Executor. The purpose is to ensure manual approval is given before the process begins.

2. Prompt for Resource Allocation - Since we allow you to reallocate items to default values (which can be changed in this workflow from the Executor), we also allow you to change who this is going to be at the last second, without having to go into the workflow and altering the policy for everyone. This is useful if a colleagues files or alias could be better suited to someone else's account, such as a team member or an archive account. It's important to note that there are sub-components that can be disabled if you don't want to give the option to reassign specific items, i.e. you could have it so that only drive could be re-assigned but all other items will always abide by the workflow.

3. Change Password - Changes the user's password to a random 16 character alphanumeric one to prevent log-in and clears their password reset question answers.

4. Revoke Application User's Account - Revokes access to user's accounts in other applications (e.g. Slack). This prevents the user from logging into the application. All installed integrations are selected by default, or you can specify which applications to apply the workflow to.

5. Revoke OAuth Tokens - Revokes all OAuth tokens issued for the user. This prevents applications from accessing the user account on their behalf.
   

6. Set Out of Office Message - Sets the Out of Office message for the user. The Out of Office message is a template that can include profile attribute placeholders just like email signatures. The email address of the specified Out of Office Contact user can be included in the message with $contact.
7. Delegate Access - The executor will be given delegation access so they can read/send/delete messages on behalf of the user.
8. Hide User - This moves the user to a specific Organizational Unit, and also hides them from the global address list so no other user can find them. 
9. Rename User - This renames the primary email address of the user, meaning it can be reused by another user. By default, the new email address is random, but it can be changed to something as simple as "old.$mailPrimary" so that you can still identify the user should you need to intervene or stop the workflow later. 

10. Assign Alias - This option is only available if 'Rename user' is enabled. Reassign the leaving users primary email to the new owner. A label can then be specified and this will be applied to all emails coming into the new owners mailbox but when using the old users primary email as it's now an alias. This helps avoid disruption of the new owners workflow within mail and means they can easily find and update any and all clients emailing an invalid address. 

11. Archive - Archives the user's data to long term storage which can be restored to another user account at a later date.
    • Fair use policy - Each user (identified by the User ID) can only be archived for a maximum of 5 times, by default. CloudM Archive will display an error if this level is exceeded. The Fair Use Policy is an existing part of the terms and conditions for CloudM Archive.
12. Transfer Ownership of Documents - This moves over all documents from the leaving user to the new owner and puts it all under a root level folder in their MyDrive as specified under the new owner setting. This means your MyDrive structure is unaffected but can now find all files of the leaving user easily.

13. Migrate Calendar Events - The user's primary calendar will be cloned and migrated with a name based on the template below which can include profile attribute placeholders just like email signatures. Any secondary calendars will be cloned and migrated with the offboarded users email address appended to the name. Events in the cloned calendars are disconnected from the originals, meaning changes by attendees are not reflected in the cloned event and vice versa. In addition, recurring events in the cloned primary calendar are expanded into individual events, meaning changes in one will not be reflected in the other occurrences. Without this step any calendars the user has created will be lost. Ownership of the user’s secondary calendars will be transferred.

14. Transfer Ownership of Groups - This moves all groups over to the new owner. If Groups is not selected, they will be lost when the user account is deleted.

15. Transfer Contacts - This will move all contacts over to the new owner and place them under a name you can specify under the new owner setting, If Contacts is not selected, they will be lost when the user account is deleted. 

16. Remove From Groups - This will remove the user from any groups they're a member of, but it's important to note with any smart groups they may be re-added if they still fall under the search query the group is based on. That is why it can be useful to move the user to another OU (under Hide user step).
17. Migrate Emails - Migrates the user's emails to the specified user. The migrated emails will be given a label based on the template below which can include profile attribute placeholders just like email signatures. The original labels of the migrated emails will be re-created under this new label.
18. Convert to Shared Mailbox - Convert the mailbox of the profile into a shared mailbox. When selecting this step for offboarding both the 'Delete' and 'Migrate Emails' steps will not be selectable.
19. Unassign License - Unassign all of the licenses from the user so that they are returned to the pool.
20. Suspend User - This prevents the user from logging in and accessing any services in Microsoft 365.
21. Delete User - This finally deletes the profile in full. You can provide a delay and also set reminder email delay values. 

You can add a custom delay to any step (except where the step requires manual input) so that steps do not automatically start after the previous one has finished, and can be more inline with your offboarding timelines.

To add a custom delay:

1. Add the step to your Offboarding Workflow,
2. In the row for the required step, click on the Clock icon.

3. Configure the delay (in days) before the offboarding step is executed.
   • The value must be a full integer (e.g. 1, 2, 3 etc.), and cannot be a part number (e.g. 1.25, 1.5, 1.75 etc.)
   • Entering a value of 0 will remove the delay.

4. Select Apply.