Table of contents
Intro to workspace consolidation
Our workspace consolidation functionality allows Enterprise workspace owners to consolidate a
source
workspace into a target
workspace by migrating users, page content, permissions, and relations. source workspace
— the workspace to be consolidated into another workspace (and then deleted 30 days post-consolidation)
target workspace
— the Enterprise plan workspace where other workspaces are consolidated.Rules of Engagement
- Customer requests a workspace consolidation from their dedicated Account Management team at Notion
- Customer reads this guide
- Customer signs the Acknowledgement Form
- Notion Account Management team schedules the workspace consolidation(s)
Why consolidate?
There are 2 key benefits of consolidating workspaces:
- For end users: It improves the information discovery and team collaboration experience when users are all in the same workspace
- For administrators: It reduces the administration overhead of managing multiple workspaces and empowers administrators to enforce company security and compliance policies more effectively
Which customers are eligible?
- Workspace consolidation is available to customers on the Enterprise plan through their Notion Account Managers or Customer Success Manager. The following criteria apply:
- The person making the request must have
workspace owner
access to the customer’s primary (target
) Notion workspace stated in their Enterprise Master Service Agreement (MSA) - The customer must have a good billing standing with Notion. This means that there should be no billing issues, such as unpaid invoices. This applies to both the
source
and thetarget
workspaces
Which source
workspaces are eligible?
- A workspace that (1) has been claimed as owned by the customer; and (2) the workspace is billed through the customer’s main billing account is eligible for consolidation
Example (1)
A workspace that was previously claimed via
domain management
(Help Center link) and added to the customer’s enterprise MSA is eligible for consolidation.Example (2)
A workspace that is already included under the customer’s Enterprise MSA is eligible for consolidation
- If a workspace is not yet listed in the customer’s enterprise MSA, it must be a
claimable
workspace for the customer. - Single-member workspace is a claimable workspace if
- The workspace creator’s email belongs to the verified corporate domain
- Multi-member workspace is a claimable workspace if
- The workspace creator’s email belongs to the verified corporate domain (the creator does not need to be a current member of the space)
- At least one current workspace owner (either the creator or someone else) is using the verified corporate email address
- and Workspace is not on the Enterprise plan
Expand toggle to review the claimable
workspace definition
- If a paid plan workspace is not yet listed in the customer's enterprise MSA, it must go through the
domain management
process to resolve any potential billing implications before becoming eligible for consolidation
You can use the
domain management
dashboard to view the list of claimable workspaces. Please visit the help center article to learn more. If you have any questions, please reach out to your account team.For the
source
workspace to be eligible for consolidation, it must contain less than 4M blocks.
The consolidation tool will have a threshold limit of 4M blocks. We will further investigate improvements to the consolidation tool to support larger workspaces for consolidation. In the meantime, please work with your Account Manager or Customer Success Manager on consolidation requests larger than this 4M block limit.
How it works
Before the consolidation
Workspace consolidation will consolidate a
source
workspace into a target
workspace by migrating users, page content, permissions, and relations.
The following is a list of known elements of the
source
workspace and indications about whether they are known to carry or not carry over to the target
workspace. If the element does not carry over to the target workspace, that means the source
settings or data will not be found in the target
workspace following consolidation.
Workspace consolidation is an irreversible action. Once the users and pages are carried to the
target
workspace, it cannot be undone or reverted back to the previous state. Because the consolidation tool will duplicate the content in the source
workspace into the target
workspace, there is no risk of data loss. If you are not comfortable with the listed or potentially unknown impacts, do not proceed with Workspace Consolidation.Feature | Supported with consolidation | Other information to note |
MEMBERSHIP | ㅤ | ㅤ |
Workspace Members | ✅ | All workspace members will enter the target workspace in the role member |
Teamspace Members and their access levels | ✅ | ㅤ |
Guests | ✅ | Only if the target workspace allows guests.
If Allow members to request adding guests is turned on → the setting is still considered to be Disable guests and guests from the source workspace will not move over |
Teamspace access levels (open/closed/private) | ✅ | ㅤ |
Permission groups | ✅ | ㅤ |
CONTENT | ㅤ | ㅤ |
All pages | ✅ | Include pages in teamspaces, shared pages, private pages, pages in trash, and unowned pages |
Page content & permissions | ✅ | ㅤ |
Page mentions & backlinks | ✅ | ㅤ |
Page metadata, e.g. created_by and last_edited_by properties | ✅ | ㅤ |
Synced blocks | ✅ | ㅤ |
Comments | ✅ | ㅤ |
Database views, templates, relations and rollups | ✅ | ㅤ |
Favorite pages (on a per-user basis) | ✅ | ㅤ |
Internal page links | ✅ | Internal page links, including block level links will get remapped into the target workspace |
Public page links | ❌ | Public page links will point to read-only content in the source workspace and will need to be manually updated to point to the target workspace. After 30 days, these links will stop working — as the source workspace will be deleted. |
Notifications | ❌ | Any notifications on page comments will be reverted to default settings ( only replies and mentions ) post consolidation |
Page history | ❌ | Page history will be reset for any migrated pages. |
Page updates (events you see in the Clock icon sidebar) | ❌ | Page updates will be reset for any migrated pages. |
Page analytics | ❌ | Page analytics will be reset for any migrated pages. |
SETTINGS | ㅤ | ㅤ |
Security settings (Public page sharing, Guests, Duplicating pages, Exports) | ❌ | All workspace security settings will default to the target workspace settings. |
Domain verification and management settings | ❌ | ㅤ |
SAML SSO configuration | ❌ | Customer needs to ensure SAML SSO configuration of the target workspace is applicable post consolidation |
SCIM API tokens | ❌ | Membership changes in the source workspace (e.g. as a result of SCIM operations) will fail once consolidation begins. Same with SAML SSO based just-in-time-provisioning.
Disabling the SCIM token and the SCIM app associated with this workspace in your identity provider is recommended. |
Just-in-Time (JIT) Provisioning | ❌ | Disabling JIT is recommended. If a new user attempts to join the source workspace via JIT, they will see an error message since the source workspace will be in a read-only state during post consolidation 30 day period. |
Audit Log | ❌ | ㅤ |
Notification settings | ❌ | ㅤ |
Private pages of de-provisioned members in the source workspace | ❌ | Workspace Owner should ensure they transfer this content before the consolidation process. |
Integrations (link previews, connected properties, synced databases, AI connectors) | ❌ | All connections will need to be re-established in the target workspace. Including: link previews, connected properties, synced databases, and AI Connectors |
Automations (databases & buttons) | ❌ | All automations will need to be re-established in the target workspace. Including: Slack notifications, Slack/Gmail automations, webhook actions, buttons, and recurring templates/automations. |
Workspace Analytics | ❌ | ㅤ |
In order to move forward with a workspace consolidation request, customers must sign this Acknowledgement Form
Initiating the consolidation
- Customers will provide a day & time for the start of consolidation and a Notion employee will schedule accordingly
- It is generally recommended to schedule the migration during off-peak hours to minimize disruption to users
- Customers will prepare the
target
andsource
workspace for consolidation - best practices found here - Before consolidation
- Otherwise, your next sync in the IdP might remove these incoming members from the
target
workspace - After consolidation
- After double checking these incoming members exists in the Notion SCIM app in the IdP
- If Guests are disabled in the
target
workspace → Consider converting guests in thesource
workspace to members and add them to your Notion SAML app (if you want them consolidated into thetarget
workspace) - If Public page sharing is disabled in the
target
workspace → The content will be consolidated, but the permissions will not carry over
High-level checklist
Note: this is not an exhaustive list and this list alone cannot guarantee a successful consolidation
target
workspace preparation
Review and confirm the workspace security settings that will override the settings in the
source
workspaceNote: Do not make changes to the workspace security settings during the consolidation
We rely on the
target
workspace security settings to determine if certain page permissions should be removed from the consolidated contentSee FAQ for more detail
Follow the steps below if you’re using the SCIM API in your
target
workspaceTemporarily turn off “Just-in-time provisioning” and SCIM provisioning
Add incoming users from your
source
workspace to your IdPRe-enable “Just-in-time provisioning” and SCIM provisioning
Note: Do not make changes to members or groups via SCIM during the consolidation
We rely on the
target
workspace’s member list to determine page permissions for GuestsSee FAQ for more detail
source
workspace preparation
Confirm all members that will be consolidated into the
target
workspace have been added to your Notion SAML app in your IDPDisable
Automatic account creation
in the Identity & provisioning
tab Follow the steps below if you’re using the SCIM API in your
source
workspaceTurn off “Just-in-time provisioning”
Disable the SCIM provisioning in your IdP temporarily during the consolidation
Review and confirm the workspace security settings that will be overridden by the settings in the
target
workspaceDuring the consolidation:
- Members of the
source
workspace will get an email notification when the consolidation process starts. This email copy will include: - Contact info of the workspace owner of the
target
workspace who triggered the consolidation action - Date & time when the consolidation process started
- Workspace members of the
source
workspace can continue to access the workspace. However, thesource
workspace will be in a read-only state where users can read/access existing content but can’t modify or create new content. - Nothing in the
source
workspace can be updated during this time — no changes to settings, permissions, or the members list. - When first logging into/accessing the
source
workspace during, or at any point after the consolidation has occurred and before the workspace is deleted the consolidation process, users will see a warning dialog and a persistent banner to inform them about the consolidation read-only state.
Target
workspace will be available for full use during the consolidation process.
Post consolidation:
- The
source
workspace will continue to be read-only. - If users visit the
source
workspace within the next 30 days, they will see a red banner redirecting to thetarget
workspace. - 30 days after consolidation, the
source
workspace will be deleted and users won’t be able to access it anymore.
- An email will be sent to the workspace owner who requested the consolidation, notifying them that the workspace has been successfully consolidated and will be in a read-only state until deletion in 30 days
- Subject to the limitations and impacts above, all teamspaces, users, guests (if allowed), and content from the
source
workspace will be fully accessible in thetarget
workspace.
- Notion will share a high level summary report once the consolidation process is over
- The workspace consolidation status (started and completed/failed) will be recorded in the Audit Log for both the source and target workspace. For example —
- Started workspace consolidation into {
target
workspace name} - Completed workspace consolidation into {
target
workspace name} - Started workspace consolidation from {
source
workspace name} - Completed workspace consolidation from {
source
workspace name}
Audit log in the source
workspace (if it’s on the Enterprise plan)
Audit log in the target
workspace
Best Practices
Workspace Consolidation Prep GuidanceFrequently Asked Questions
Are there any best practices for time to run the consolidation process? How long will the workspace consolidation take?
- While the specific timing of any data consolidation/migration for an enterprise SaaS tool will depend on a variety of factors, including the amount of data being migrated and the complexity of the system, it is generally recommended to schedule the migration during off-peak hours to minimize disruption to users.
- For workspaces within the tool limits (10K pages, 150K blocks) → each consolidation should complete in 30 mins or less
- For workspaces larger than the tool limits (10K pages, 150K blocks) → please work with your dedicated Account Manager or Customer Success Manager to discuss options
What do you recommend if my workspace has more than the 500k block volume limit?
- Large consolidations above the tool limit (150K blocks) will be reviewed by the Notion Engineering team and approved on an individual basis. Please work with your dedicated Account Manager or Customer Success Manager to learn more about submitting a request
Can you run multiple workspace consolidations at once? B and C together into A?
- We are able to schedule batches of workspace consolidations to run in quick sequence, which is often functionally at the same time. In this example, B into A followed by C into A.
What happens to the source
workspace after the consolidation is complete?
- Post consolidation, if users visit the
source
workspace within the next 30 days, they will see a red banner redirecting them to thetarget
workspace.
- 30 days after consolidation, the
source
workspace will be deleted and users won’t be able to access it anymore.
What happens to the target
workspace after the consolidation is complete?
- For members of the
target
workspace post consolidation — there will be no apparent changes to their workflows. - In the
All teamspaces
workspace settings, they’ll be able to see the Open and Closed teamspaces that have been consolidated over from thesource
workspace - They will be able to collaborate business as usual with new members from the
source
workspace - The migrated teamspaces will have the
source
workspace name prepended to the teamspace name. Page names will not be altered.
- For members consolidated over from the
source
workspace post consolidation — they should be able to continue their workflows business as usual - They’ll inherit permissions to the general teamspaces and retain all existing teamspaces and page permissions
- Links to Notion from other apps and public page links in Notion will continue to point to the read-only content in the
source
workspace and will need to be manually updated to point to thetarget
workspace
What information should you backup from the source
workspace before it’s deleted?
- The following data from the source workspace will not be available post-consolidation. Therefore, we encourage you to export the following from the source workspace, if applicable:
- Audit log: Export the
source
workspace audit log as a CSV - Workspace analytics: Export each tab of workspace analytics data
- Admin Content Search: For each Audience filter, export the results as CSV
- Bulk workspace export to generate a back up of the workspace content
- Workspace Members CSV export
Do pages that are shared to the web carry over?
If sharing pages to web is disabled in the
target
workspace, any pages in source
workspace that are shared to web will have their sharing forced off when they enter the target
workspaceHow can I audit the pages that have been shared to the web in the source
workspace?
- Public pages that are consolidated into the target workspace will have a new URL. As a result, any Notion page links that pointed to the source workspace will continue to point to the source workspace (read-only) until the source workspace is deleted (30 days after consolidation), at which point the page links will result in a 404 error.
If you have a concern about having two instances of public pages during that 30-day duration, we recommend using Content Search to locate your published pages in the
source
workspace, then unpublish them before consolidation. Once consolidation is complete, you will need to manually publish each page again in the target
workspace after the consolidation, and update all instances of the link accordingly.How do permissions carry over?
Workspace Members and their access levels, permission groups, page permissions, and guests of the
source
workspace will be retained and carry over into the target
workspace.Teamspaces
- All teamspaces from the
source
workspace will be carried over into thetarget
workspace. The naming convention will be [SourceWorkspaceName TeamspaceName]. The access level (open | closed | private) will remain the same in thetarget
workspace.
- All teamspaces from the
source
workspace will retain their full list of members. Teamspaces will retain their guests if allowed.
- Default teamspace(s) (ie - “General”) from the
source
workspace will be downgraded to open teamspace(s) in thetarget
workspace. All members from thesource
workspace will continue to be in all default teamspace(s) migrated from thesource
workspace.
- All members from the
source
workspace will be added to all default teamspace(s) in thetarget
workspace.
Members and access levels
- Members:
Source
workspace members will carry over intotarget
workspace. The list will be deduplicated if the member exists in thetarget
workspace.
- User role types (workspace owner, membership admin, member):
- If a user exists in both workspaces: Retain the role type in the
target
workspace - If not: User role is downgraded to member in the
target
workspace
- Recently left members and their private pages will not be carried over during the consolidation. Be sure to manually address any Recently Left members before consolidation.
Guests
- If
target
workspace disabled guests: All page-level guests from thesource
workspace will be removed during consolidation.
- If
target
workspace allows guests: Page-level guests and their permissions will be unchanged in thetarget
workspace.
Permission Groups
source
workspace permission groups will carry over into thetarget
workspace
- All permission groups that are the result of consolidation will have a prefix to indicate that they came from the
source
workspace. Ex: [source
WorkspaceName] permissionGroupName
Security settings (e.g. Disable guests or public sharing)
- The most restrictive security setting between both the
source
andtarget
workspaces will be retained during the consolidation. - Ex: If guests are disabled in the
target
workspace but allowed in thesource
workspace → guests will be disabled for the “source
workspace” teamspace in thetarget
workspace post consolidation - Ex2: If guests are allowed in the
target
workspace but disabled in thesource
workspace → guests will be disabled for the “source
workspace” teamspace in thetarget
workspace post consolidation
Page permissions
- Apply the
target
workspace security settings related changes first (e.g. more restrictive settings about guests or public page sharing), and then retain the remaining page permissions in the new Teamspace. Page-specific permissions will be retained, if not otherwise prevented by security settings.
Will guests be moved over as well?
- If
target
workspace disabled guests: Removesource
workspace guests from page permission during consolidation. - Note: If
target
workspace has enabledAllow members to request adding guests
→ the setting is still considered to beDisable guests
and guests from thesource
workspace will not move over
- If not: Retain page level guests and their permissions
What are the consequences of making changes to Guests in the workspace security settings of the target
workspace during consolidation
- If guests are enabled in the
target
workspace at the start of the consolidation, but disabled during the consolidation → there’s risk that content with guest permissions has already been consolidated over
- If guests are disabled in the
target
workspace at the start of the consolidation, but enabled during the consolidation → there’s a risk that content with guest permissions has been removed from the consolidation already
What are the consequences of making changes to members in the target
workspace during consolidation
- (If a
target
workspace has disabled guests) For a user who is a guest of thesource
workspace, but a member of thetarget
workspace → the content consolidation will initiate with the user’s permissions intact. - If the user is later removed from the
target
workspace during consolidation, there’s a risk that the content with that user’s permissions has already been consolidated over intact
- (If a
target
workspace has disabled guests) For a user who is a guest of thesource
workspace, but not a member of thetarget
workspace → the content consolidation will initiate with removing this user’s permissions - If this user is later added to the
target
workspace as a member during the consolidation, there’s a risk that the content has already been consolidated without this user’s permissions
How does this impact integrations, aka. connections (custom apps, bots or automations)? Will those need to be reconfigured?
- Connections, aka integrations (bot and previous user authentications for integrations) from the
source
workspace will not carry over intotarget
workspace.
- Existing integrations such as link previews and embeds will remain in the page content and carry over to the
target
workspace. However, workspace members will have to reauthenticate again in thetarget
workspace.
- Recurring template configurations will not carry into the
target
workspace. Users will need to reconfigure the recurrence in thetarget
workspace.
Will end-users be redirected to the new links in the target
workspace if they try to use an old link from the source
workspace?
Users will not be redirected to new links in the
target
workspace. If they click on a link from the source
workspace, it will still take them to the source
workspace page if the source
workspace is not yet deleted.