CloudM Glossary

When a user is offboarded from their organization, we can add a step in their workflow to migrate all of their user data (Drive items, Emails and Chat) to a Storage Bucket.

This allows an organization to keep data for a specific amount of time before deleting it, in accordance with data retention regulations, whilst freeing up licences. Additionally, Archive allows you to easily restore data from Storage back into CloudM Manage.

Only on Google domains.

Groups that can be set up in a branching hierarchy (e.g. your company structure with each OU representing a department).

They can be organized into Parent and Child OUs, so that some aspects of the Parent are (or can be enabled to be) inherited by any Child OU under them, and you can provide users in each OU with the correct access and permissions to do their role (e.g. Email Signature Management).

A good example would be a company that has multiple brands, with each brand having their own Sales, Marketing, Development and Support teams.

You can set your OU structure so that, at the top (or root), is your company OU. Underneath the root OU, you would create an OU for each brand. They would act as Child OUs to your Company OU and would inherit certain properties as default, which can be edited if required.

Now, you can create OUs for each department under each brand. These would act as Child OUs to the brand OU.

A platform is either the domain that you are migrating from (Source) or migrating to (Destination).

This is different from the CloudM Platform, which is the overall name for our CloudM product set, combining the Migrate, Manage and Archive applications.

For example, we can set up our offboarding workflows so that, when a user is offboarded, a command is sent to another software application (e.g. Slack) that automatically deactivates the user's access to that application.

Other integrations (such as Bamboo HR) will send commands to CloudM when an action occurs in that application (e.g. a job title change). This can trigger a range of processes in CloudM, such as updating profile fields, email signatures, Smart Team functionality and Offboarding Workflows.

A group of users that can be grouped either manually or dynamically (based on meeting certain criteria).

Smart Teams can be given access to specific calendars and documents, roles, different email signatures, security policies and onboarding / offboarding workflows.

In Google Workspace domains, Smart Teams are used to create bespoke groups without breaking your hierarchy (which is set in the Organizational Units / OUs).

In Microsoft 365 domains, Smart Teams are used to create a hierarchy (as OUs do not exist).

A good example would be a user being promoted to a Manager position within your company.

They need access to certain calendars and files (without losing the ones they already have as part of their Organizational Unit) and you may have set up specific policies to secure Manager passwords and how the are offboarded.

You can create a dynamic Smart Team that automatically adds any user to the group who meets a certain criteria (in this instance, they could have a "Manager" tag added to their profile).

They would automatically receive all the privileges required for their new role, without losing their existing permissions and access, but with policies that overwrite their current policies, where appropriate. 

You can set up Virtual Machines using GCP or Microsoft Azure so that you can create multiple secondary servers without needing the physical architecture.

This always you to speed up migrations by increasing the number of items being processed simultaneously.