Offboarding Policy and Process for Google Workspace


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 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 34 steps that can be enabled or disabled as you require.

    1. Request Approval
    2. Preemptively Suspend User
    3. Assign Google Workspace License
    4. Prompt for Resource Allocation
    5. Wipe Mobile Devices
    6. Wipe Chrome OS Devices
    7. Change Password
    8. Revoke 2-Step Verification
    9. Remove Recovery Methods
    10. Revoke Application Specific Passwords
    11. Revoke Application User's Accounts
    12. Revoke OAuth Tokens
    13. Remove or Replace User as Manager
    14. Revoke Existing Delegate Access
    15. Set Out of Office Message
    16. Remove Email Forwarding Settings
    17. Delegate Access
    18. Move User
    19. Hide User
    20. Rename User
    21. Assign Alias
    22. Archive
    23. Archive Vault
    24. Purge Backup
    25. Transfer Ownership of Documents
    26. Migrate Calendar Events
    27. Transfer Ownership of Groups
    28. Transfer Contacts
    29. Transfer Shared Drives
    30. Transfer Looker (Google Data) Studio
    31. Remove from Groups
    32. Migrate Emails
    33. Unassign Licenses
    34. Suspend User
    35. Apply Google Archived User (AU) license
    36. Delete User

Please note: Not all of these steps may be applicable to your workflow, depending on the module(s) you have purchased. If you find a step that you wish to include but are unable to do so, please feel free to contact your Customer Success or Account Manager for assistance.


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. 

  • If the Automatically Offboarded Suspended Accounts option is enabled, the option to Only offboard if suspended by a user on a known domain is displayed. This will prevent a user from being offboarded if they are suspended by Google for security reasons (like multiple password retries, suspicious account activity etc.). This option does not affect suspension triggers from integrations (such as Bamboo HR).

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.


Automatic Offboarding

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 Automate 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
  • Specified
  • User's Manager

The user's manager is the one specified on their CloudM Automate user profile.  If this is not set and you select this option, the process may error.

To start offboarding a user now requires 'Automate Users' AND 'Offboard Users' permissions.

To delete a user account, 'Automate Users' AND 'Delete Users' are required.


Multiple Executors

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. 

Additionally, you can set whether to "Show the user who started the offboarding in the notification emails" and Add additional recipients to the notification emails.


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 to the Executor. The purpose is to ensure manual approval is given before the process begins.
  2. Preemptively Suspend User - This step will allow you to suspend the user at the start of the offboarding process, preventing them from logging in and accessing any services from the account. This step is ideal for workflows that include custom delays between steps.
  3. Assign Google Workspace License - Ensures a user has an appropriate Google Workspace license to prevent certain steps in the workflow that require mail services or drive services enabled from failing. If a user has a Google Archived User license assigned this will automatically be removed and the user will be unarchived in Google if you have the step included in your workflow. If a user has a Cloud Identity license and you wish to assign them a Google Workspace license please use the "Assign Google Workspace" license checkbox and select the relevant license from the list.
    Please note: The user will be assigned a Google Workspace license in this step, you must include the relevant step at the end of the workflow if you would like the license to be removed. 
  4. 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.

    • Check the Specific Step Executor box and specify a different executor (the person that will confirm or deny the request) if you want to assign the request to a user not specified as an Executor in the Workflow Settings section.

    • To send periodic reminders to the executor and the user's manager if a request has been ignored, check the Alert executor / manager if request has not been reviewed after a set number of days box.

      • Period between reminders (Days) - Set the number of days between the original request email and the first reminder email.

      • Reminder Count - Set the number of reminders that will be sent, each sent at the interval set above.

      • Reminder Subject - Set the subject header that will be displayed on the reminder emails. Please note that you can add variables (such as $personalName) to the header.

      • Email template - Set the email template from your Workflow Template library to be sent out as part of the reminder emails.
    • It's important to note that there are options 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. The options are:

      • Allow Override of Alias New Owner

      • Allow Override of Documents New Owner

      • Allow Override of Calendars New Owner

      • Allow Override of Groups New Owner

      • Allow Override of Contacts New Owner

      • Allow Override of Migrate Emails Recipient

      • Allow Override of Delegate Access Recipient

      • Allow Override of Out of Office Contact

      • Allow Override of New Shared Drive owner

      • Allow Override of Transfer Looker (Google Data) Studio reports owner

  5. 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.
  6. 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.
  7. 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.
  8. 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. This includes turning off 2 Factor Authentication if enabled in Google.
    • If a user is suspended and this step is triggered, the user is unsuspended and an hour wait is triggered before the step is done. Then. the user will be suspended again once the step is completed.
    • If the user's 2-step verification is managed by a Google policy, such as at OU level, then the step will not error but CloudM will be unable to disable their 2-step verification.
  9. 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.
  10. 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.
  11. 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.
  12. Revoke OAuth Tokens - Revokes all OAuth tokens issued for the user. This prevents applications from accessing the user account on their behalf.
  13. Remoke or Replace User as Manager - If the offboarding user is a manager this step will remove or replace them from the 'Manager' field of any associated user profiles. If you click the 'Replace manager' checkbox you can pick who you'd like the offboarding Manager to be replaced with.
  14. Revoke Existing Delegate Access - Revokes access for any users who have delegated access to the offboarding user's mailbox. 
  15. 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.
  16. Remove Email Forwarding Settings - Remove the Email Forwarding settings configured for the user. Emails sent to the email address will no longer be forwarded.
    • For example, this step would stop a leaver from being able to set up forwarding to a personal account.
  17. Delegate Access - The specified recipient will be given delegation access so they can read/send/delete messages on behalf of the user. 
  18. Move User - This moves the user profile to a specified OU.
  19. Hide User - This hides the user profile from the global address list so no other user can find them. 
  20. Rename User - This renames the user's primary email ID, first and/or last name.
    • Renaming the user's primary email ID allows the same email address to be re-used by another user immediately. The user's new primary email ID / first name / last name is based on a template which can include profile attribute placeholders just like email signatures. The primary email ID template can be a full email address (e.g. old.$mailPrimary) or just the username part. If any template is empty, a random ID is generated.
  21. 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. 

  22. 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.
  23. 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).
  24. Purge Backup - Triggers a purge of backed up data for a user x days after they've been offboarded. By default the number of days we wait before the purge will happen is set to 30 days but this can be configured in the step. The step triggers purge of both Mail and Drive data for the user. If a customer also has an Archive step we will make sure Archive happens first before the Purge Backup step.
  25. 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.
    • Enforce Only Transfer Shared Documents - Only transfer items that have been shared with other users.
    • Use Data Transfer Api - Use the Google Data Transfer API to transfer the ownership of the documents instead of the existing CloudM method. Please note that the Google Data Transfer API will not grant the same level of error logging or statistic reporting fidelity as the CloudM method. Please refer to the Google Data Transfer API use case and limitations article for more details on differences and limitations.
  26. Migrate Calendar Events - To migrate a user's calendar events you need to check the 'Transfer Calendars' step. 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 Calendar Events check box which allows the administrator to decide to remove resources or retain resources during offboarding for a leaver (such as Meeting Rooms, Jamboards etc), freeing them up for use. You do not need to be migrating the calendar to perform this action. If you are performing a migration of the calendar AND removing resources please note that the resources are only removed from the offboarding user's calendar and NOT the target user's calendar. 
  27. 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.

  28. 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. 

  29. 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.
  30. Transfer Looker (Google Data) Studio -  This step will transfer the ownership of Looker Studio (previously known as Google Data Studio) data to a specified user. 
  31. 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).
  32. 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.
      • When enabled, the Disallow Label Truncation setting will fail the step if a label is too long. When disabled, the step will not fail but will use the label of the closest parent instead.  
  33. 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.
  34. Suspend User - This prevents the user from logging in and accessing any services in Google Workspace.
  35. Apply Google Archived User (AU) license - Switches the license on the account to a Google Archived User (AU) license.
  36. 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.


  1. 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.
    • Place a check in the Send email notification before delay end checkbox to trigger a reminder email (that the specific step delay is coming to an end) to be sent to the notification email recipients set in the Workflow settings section. The notification will be sent 24 hours before the end of the delay.


  1. Select Apply.


Was this article helpful?
0 out of 0 found this helpful