Offboarding workflows and steps are designed to be customizable and flexible so that each customer can set up suitable workflows for their needs.
However, this means that any misconfiguration, or misunderstanding of what the step is set to perform, can result in failed offboardings and errors.
It also means that it can be difficult to accurately predict how long each offboarding process will take.
Processing times
It’s important to understand the constraints when it comes to processing an offboarding workflow for a user.
- The more steps in a workflow, the longer it will take to process.
- The Email transfer usually takes the longest because CloudM Manage is copying data from a source user account to a target user account. The bandwidth available to do this is limited by Google’s Gmail APIs
- If the source email account has a large number of email items and attachments, then it can take a considerable amount of time to complete this onboarding step.
- The number of target accounts can have an effect on processing times.
- For example, if you offboard user data to one “archive” account, then this severely limits the speed at which offboardings can run as only one offboarding can be done at a time. If you set up multiple “archive” accounts, then CloudM Manage can process offboardings to each of them simultaneously. i.e Source A to Target A, Source B to Target B. We don’t recommend you use the "Migrate Emails" step for the purposes of archiving users' data.
- We have CloudM Archive as a dedicated Archive solution for data retention compliance
- Unfortunately, it’s not possible for CloudM Manage to calculate or estimate how long any one offboarding will take as there are many variables on Google's Cloud Platform upon which CloudM Manage is built and Google Workspace.
- As a guide, we conducted a test of two accounts - one with a larger mailbox but lower number of items, and one with a smaller mail but with a lot of individual items. As you can see below, the larger mailbox took less time due to having less individual items.
- 20GB mailbox with over 40K emails took around 13 hours
- 9GB over 141k emails took around 44 hours
- When a step calls for a suspended user to be unsuspended (so the action can take place on the account), there will be a delay of an hour to allow for data propagation.
Configuration issues
As mentioned above, offboarding workflows can be flexible and customizable, but this can lead to configuration issues that result in errors.
- Using an alias as a target account - Currently CloudM Manage does not support using an account alias as the target account. Therefore, ensure that the target account set is using the primary email address of the user you want to use.
- Ensure the status of an account in Google is active. Cloud M requires the source account to be active so that it can access data via Google’s APIs. If an account is in a suspended or archived state, this can result in a failed offboarding state. If an account has been deleted, an offboarding won’t be possible.
- An account is set to Archive in Google.
Limits of using one user account as a generic or archive account
Using a generic or “archive” account, where you offboard all your data to, will ultimately result in reaching a limit and cause errors. This practice is possible for low number of users and volume of data but does not scale for the following reasons:
- Google Gmail inbox size - Depending on your workspace SKU, you will hit the maximum amount of data that can be stored in any one mailbox. For example, on a Business start plan, the cloud storage is 30GB.
- Google Gmail label limit - The maximum number of labels any one account can have is 10,000.
- Google contacts limits - Any one account has a limit of 25,000 contacts or 20MB (excluding profile images).
- Google bandwidth and rate limits - CloudM Manage can only go as fast as Google allows within their defined API rate limits. For example, migrating email from a source account to a target account copies data. Therefore, the larger the source mailbox, the longer it will take to complete this step.
Using the Google Data Transfer API
Please refer to the Google Data Transfer API use case and limitations article for more detail.
Large number of concurrent offboardings
- If you try to offboard a large number of source accounts to one target account in one go this will take a considerable amount of time as only one account can be processed at a time. For example you offboard 1000 users at the same time, and the first account that gets processed has 20GB of mail, and the second account has 1GB of mail. The first account has to finish before the second account can start.
- You are likely to run into the limitations of using one account outlined above very quickly. This is because the source accounts will have different Gmail labels, Contacts and Calendar items that will start to add up when combined into one account.
Metadata
When offboarding users and transferring data to another account, certain changes are made to the metadata. CloudM Manage will always preserve original metadata where technically possible.
For example, when we transfer email from one account to another, changes are made to Message-ID/References/In-Reply-To and the Subject (appending the destination label) to prevent the emails getting matched up to others in the target account, and we also add an X-Migrated-By header.
Other transferred data like drive items, calendars and contacts have metadata changed, which is explained in each onboarding step.
Recommended use cases
- Offboarding a leaver by securing their account and transferring their data to a manager or colleagues account.
- Offboarding a leavers data into CloudM Archive for data retention.
Use cases to avoid
- Offboarding a leavers data to a generic account for data retention, or eDiscovery/SAR/FOI, or other legal reasons. There are specialist tools, including Google Vault, for companies that need eDiscovery for regulatory compliance.
Offboarding step retries
- If a step fails, it will retry a maximum of 5 times automatically. There may be exceptions where the process returns a "NON_RETRYABLE" message.
Comments
0 comments
Please sign in to leave a comment.