Offboarding Watchpoints and Limitations

Offboarding workflows are flexible and customisable, which means misconfiguration or misunderstanding of what a step does can result in failed offboardings and errors. This article covers common watchpoints, known limitations, and recommended use cases to help you get the best results.

Processing times

It is not possible for CloudM Automate to calculate or estimate how long an offboarding will take — there are too many variables on Google's platform. The following factors affect processing time:

• The more steps in a workflow, the longer it will take.
• The Migrate Emails step typically takes the longest. Speed is constrained by Google's Gmail APIs. The number of individual email items has a greater impact on processing time than overall mailbox size.
• The number of target accounts affects speed. Only one offboarding can run to a given target account at a time. Using separate destination accounts for each user allows multiple transfers to run in parallel.
• Steps that require a suspended user to be unsuspended have a 1 hour delay to allow for data propagation.

Configuration issues

• Using an alias as a target account — CloudM Automate does not support account aliases as target accounts. Always use the primary email address of the target user.
• Source account must be active — CloudM Automate requires the source account to be active to access data via Google's APIs. If the account is suspended or archived, the offboarding may fail. If the account has been deleted, offboarding is not possible. Refer to Google's guidance on account status for more information.
• Archived accounts — if an account is set to Archived in Google Workspace, this can cause offboarding to fail. Refer to Google's guidance on archived users.

Limits of using a single generic or archive account

Directing all offboarded data to a single account works for small volumes but does not scale. The following Google limits will be reached over time:

Large numbers of concurrent offboardings

If you offboard a large number of users to a single target account simultaneously, processing is sequential — only one source account can transfer to a given target at a time. For example, if you offboard 1,000 users to the same target and the first user has a 20GB mailbox, no other offboardings to that target can start until it completes.

When large numbers of users are offboarded to one account, the Gmail label, contacts, and storage limits described above can be reached quickly as data from multiple users accumulates.

Google Data Transfer API

For information on using the Google Data Transfer API within offboarding, refer to the Google Data Transfer API use case and limitations article.

Metadata changes

When transferring data to another account, CloudM Automate preserves original metadata where technically possible. For email transfers, the following fields are modified to prevent emails being matched to existing threads in the target account: Message-ID, References, In-Reply-To, and Subject (the destination label is appended). An X-Migrated-By header is also added. Metadata changes for Drive, calendar, and contacts items are covered in the individual step articles.

Recommended use cases

• Offboarding a leaver by securing their account and transferring data to a manager's or colleague's account.
• Offboarding a leaver's data into CloudM Archive for data retention.

Use cases to avoid

Step retries

If a step fails, it will automatically retry up to 5 times. There may be exceptions where a NON_RETRYABLE message is returned, in which case the step will not be retried automatically.