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)
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
  1. Customer requests a workspace consolidation from their dedicated Account Management team at Notion
  1. Customer reads this guide
  1. Customer signs the Acknowledgement Form
  1. 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 the target 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.
    • Expand toggle to review the claimable workspace definition
      • 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
  • 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.
      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.
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
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 and source workspace for consolidation - best practices found here
    • High-level checklist
Note: this is not an exhaustive list and this list alone cannot guarantee a successful consolidation
      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 workspace
      Note: Do not make changes to the workspace security settings during the consolidation
      Note: 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 content
      See FAQ for more detail
      Follow the steps below if you’re using the SCIM API in your target workspace
      • Before consolidation
        • Temporarily turn off “Just-in-time provisioning” and SCIM provisioning
          Add incoming users from your source workspace to your IdP
          • Otherwise, your next sync in the IdP might remove these incoming members from the target workspace
      • After consolidation
        • Re-enable “Just-in-time provisioning” and SCIM provisioning
          • After double checking these incoming members exists in the Notion SCIM app in the IdP
      Note: Do not make changes to members or groups via SCIM during the consolidation
      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 Guests
      See 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 IDP
      Disable Automatic account creation in the Identity & provisioning tab
      Follow the steps below if you’re using the SCIM API in your source workspace
      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 workspace
      • If Guests are disabled in the target workspace → Consider converting guests in the source workspace to members and add them to your Notion SAML app (if you want them consolidated into the target workspace)
      • If Public page sharing is disabled in the target workspace → The content will be consolidated, but the permissions will not carry over
 

During 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, the source 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 the target 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 the target 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 —
    • Audit log in the source workspace (if it’s on the Enterprise plan)
      • Started workspace consolidation into { target workspace name}
      • Completed workspace consolidation into { target workspace name}
      Audit log in the target workspace
      • Started workspace consolidation from { source workspace name}
      • Completed workspace consolidation from { source workspace name}
 

Best Practices

Workspace Consolidation Prep Guidance
Workspace Consolidation Prep Guidance

Frequently 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 the target 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 the source 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 the target 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 workspace
How 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.
      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 the target workspace. The naming convention will be [SourceWorkspaceName TeamspaceName]. The access level (open | closed | private) will remain the same in the target 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 the target workspace. All members from the source workspace will continue to be in all default teamspace(s) migrated from the source workspace.
  • All members from the source workspace will be added to all default teamspace(s) in the target workspace.
Members and access levels
  • Members: Source workspace members will carry over into target workspace. The list will be deduplicated if the member exists in the target 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
Guests
  • If target workspace disabled guests: All page-level guests from the source workspace will be removed during consolidation.
  • If target workspace allows guests: Page-level guests and their permissions will be unchanged in the target workspace.
Permission Groups
  • source workspace permission groups will carry over into the target workspace
  • All permission groups that are the result of consolidation will have a prefix to indicate that they came from the source workspace. Ex: [sourceWorkspaceName] permissionGroupName
Security settings (e.g. Disable guests or public sharing)
  • The most restrictive security setting between both the source and target workspaces will be retained during the consolidation.
    • Ex: If guests are disabled in the target workspace but allowed in the source workspace → guests will be disabled for the “source workspace” teamspace in the target workspace post consolidation
    • Ex2: If guests are allowed in the target workspace but disabled in the source workspace → guests will be disabled for the “source workspace” teamspace in the target 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: Remove source workspace guests from page permission during consolidation.
    • Note: If target workspace has enabled Allow members to request adding guests → the setting is still considered to be Disable guests and guests from the source 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 the source workspace, but a member of the target 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 the source workspace, but not a member of the target 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 into target 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 the target workspace.
  • Recurring template configurations will not carry into the target workspace. Users will need to reconfigure the recurrence in the target 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.

Loading...