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 customizable offboarding policy and process which can be applied to your entire domain and, where required, specifically to different Organizational Units.
The workflow is a total of 30 steps that can be enabled or disabled as you require.
- Request Approval
- Prompt for Resource Allocation
- Wipe Mobile Devices
- Wipe Chrome OS Devices
- Change Password
- Revoke 2-Step Verification
- Remove Recovery Methods
- Revoke Application Specific Passwords
- Revoke Application User's Accounts
- Revoke OAuth Tokens
- Set Out of Office Message
- Delegate Access
- Move User
- Hide User
- Rename User
- Assign Alias
- Archive Vault
- Transfer Ownership of Documents
- Transfer Ownership of Sites
- Migrate Calendar Events
- Transfer Ownership of Groups
- Transfer Contacts
- Transfer Shared Drives
- Remove from Groups
- Migrate Emails
- Unassign Licenses
- Suspend User
- Apply Google Archived User (AU) license
- Delete User
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 selected, accounts set to 'suspended' by any method will be offboarded. This included accounts set via an external system e.g. via Google 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
- User's Manager
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 Gmail 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.
- Wipe Mobile Devices - This clears any corporate data connected to the user account on any devices owned by this domain. The mobile devices must be configured through device management in Google Workspace Admin portal.
- Wipe Chrome OS Devices - Remotely wipes user accounts from any Chrome OS devices owned by the user. Please note that this step does not support Enterprise controlled Chrome OS devices.
- To remove user data from a Chrome device, the 'WIPE_USERS' command needs to be invoked from the ChromeOS API.
- 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 2-Step Verification - If the user has configured two form authentication for their user account, this option will revoke any of this data upon offboarding as an added layer of security
- Remove Recovery Methods - Removes the Recovery Methods (recovery email and phone number) currently setup for the user so they cannot change the password back and gain access to their account.
- Revoke Application Specific Passwords - Revokes all application specific passwords created for the user's account. This prevents applications from accessing the user account on their behalf.
- 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.
- Revoke OAuth Tokens - Revokes all OAuth tokens issued for the user. This prevents applications from accessing the user account on their behalf.
- 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.
- Delegate Access - The executor will be given delegation access so they can read/send/delete messages on behalf of the user.
- Move User - This moves the user profile to a specified OU.
- Hide User - This hides the user profile 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 Gmail and means they can easily find and update any and all clients emailing an invalid address.
- Archive - Archives the user's data to long term storage which can be restored to another user account at a later date. If the offboarded user does not have any mail services enabled, such as a Google Cloud Identity Account, this step will be skipped. The step will only be visible if Archive has been enabled on the domain (refer to Adding the Archive step to an Offboarding Workflow for more information).
- 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.
- Archive Vault - Archives the user's Vault data to long term storage which can be restored to another user account at a later date. The step will only be visible if Archive has been enabled on the domain (refer to Adding the Archive step to an Offboarding Workflow for more information).
- 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.
Transfer Ownership of Sites - This moves all sites over to the new owner. If Google Sites is not selected, they will be lost when the user account is deleted.
- 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. Incoming events in the cloned primary calendar 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.
If the offboarded user does not have any mail services enabled, such as a Google Cloud Identity Account, this step will be skipped.
- The Migrate Calendar Events step now includes a Remove Resources from Migrated Events check box which allows the administrator to decide to remove resources or retain resources during migration (such as Meeting Rooms, Jamboards etc), freeing them up for use.
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.
- Transfer Shared Drives - This will transfer the ownership of any Shared Drive where the offboarded user is deemed the owner to a new owner. By default, the new owner is set as the Executor, but you can specify a different owner within the policy.
- 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.
- Unassign Licenses - Unassign all Google licenses from the user so that they are returned to your license pool. This prevents offboarded users from using up a valid license that could be assigned to an active user, helping you to keep your license costs under control.
- If the user has auto-licensing enabled, the license will not be removed using this step.
- Suspend User - This prevents the user from logging in and accessing any services in Google Workspace.
- Apply Google Archived User (AU) license - Switches the license on the account to a Google Archived User (AU) license.
- 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:
- Add the step to your Offboarding Workflow,
- In the row for the required step, click on the Clock icon.
- 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.
- Select Apply.