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 Manage 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 18 steps that can be enabled or disabled as you require.
- Request Approval
- Prompt for Resource Allocation
- Change Password
- Revoke OAuth Tokens
- Delegate Access
- Hide User
- Rename User
- Assign Alias
- Transfer Ownership of Documents
- Transfer Ownership of Calendars
- Transfer Ownership of Groups
- Transfer Contacts
- Remove from Groups
- Migrate Emails
- Convert to Smart Mailbox
- Unassign Licenses
- Suspend User
- 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
- Click on Administrate > Offboarding Workflow
- 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.
- Where the OU is not the Root OU, select Explicitly set Offboarding Policy to edit the process for the selected Organizational Unit.
- Select the Workflows settings tab.
- Click Directory > Org Units or Smart Teams
- Find and select the required OU or Smart Team to prompt the informational panel to be displayed
- Click on the Configure button
- Click on the Offboarding option
- You will be taken to the Workflows actions tab (on Administrate > Offboarding Workflow) with the selected OU or Smart Team pre-selected.
- Select the Workflows settings tab.
- 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.
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.
It is important to remember that when this option is a selected account set to 'suspended' by any method will be offboarded. This included accounts set via an external system e.g. via Office 365 Admin or an other HR system, accounts set to suspended via CSV import or accounts set via CloudM Manage itself.
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
The user's manager is the one specified on their CloudM Manage user profile. If this is not set and you select this option, the process may error.
In any setting of "Specified", you will be presented with a text box beneath the drop down allowing you to pick the email of the user you want to use. In cases where there are more than 1 potential executor (the top 2 settings), then a workflow is sent to both. However, as soon as one starts the workflow, it is assigned to them.
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.
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:
- 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.
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.
- 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.
- Revoke OAuth Tokens - Revokes all OAuth tokens issued for the user. This prevents applications from accessing the user account on their behalf.
- Delegate Access - The executor will be given delegation access so they can read/send/delete messages on behalf of the user.
- Hide User - This moves the user to a specific OU, and also hides them from the global address list so no other user can find them.
- Rename User - This renames the primary email address of the user, meaning it can be reused by another user (see step 7). 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.
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.
- 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.
Ownership of Calendars - This moves all calendars over to the new owner. If Calendar is not selected, they will be lost when the user account is deleted.
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.
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.
- 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).
- 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.
- 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.
- Unassign License - Unassign all of the licenses from the user so that they are returned to the pool.
- Suspend User - This prevents the user from logging in and accessing any services in Microsoft 365.
- Delete User - This finally deletes the profile in full. You can provide a delay and also set reminder email delay values.