Migrating to v3

Summary

All Spaces now behave like My Space: they get their own collections, groups, and assistants. Existing items stay in My Space; new Spaces start empty. You can create collections and assistants directly in any Space.

Items always live in exactly one Space and cannot be combined across Spaces. You can move existing items from My Space to other Spaces; see Migration steps.

How Spaces, groups, and collections fit together

Access always stays inside a single Space. Your group memberships in a Space decide which of that Space’s collections you can see, and you attach those collections to a chat to use them as context. Nothing crosses a Space boundary — a group in one Space can never grant access to a collection in another, and the same group name in two Spaces means two entirely separate groups.

In this example, Nico is a member of Group Y in Space A and Group Z in Space B:

• In Space A, he sees Collections 2 and 3, because Group Y has access to them. Collection 1 is only shared with Group X — which Nico is not in — so he cannot see it.
• In Space B, he sees only Collection 4, because Group Z has access to it. Collection 5 is not shared with any group, so no one reaches it through a group.
• Access never crosses Spaces. Group Z can never be granted access to Collections 1–3, and vice versa. Dashed items are the ones Nico cannot access.

New: assistants, collections, and prompt templates in every Space

Previously, assistants, collections, and prompt templates were only available in My Space. With v3, every Space has its own. You can create them directly in the respective Space and combine them with the Space’s data. The workspace view always shows only the elements of the currently selected Space.

New: “{Space Name} - General” collection

Each Space with pre-existing synced data (e.g. from Confluence or S3 AutoSync) gets a special “{Space Name} - General” collection. It contains all the data that was in the Space before the update. Previously this data was automatically available as context; now you need to attach the collection explicitly via # or the + icon.

Since assistants can now be created in the Space, you can also attach this collection to an assistant. This means assistants can access synced Space data for the first time.

Space-level data sync continues to operate as before; only the delivery side changed.

New: custom sync targets

AutoSync (Confluence, S3, etc.) can now also be pointed at other collections in the same Space, not just the default “{Space Name} - General” collection. This lets you organize synced data into separate, topic-specific collections within a Space.

What changed

	Before	After
Workspace items (collections, assistants, prompt templates)	Only in My Space	In every Space; each Space has its own isolated set
Item portability between Spaces	N/A (only My Space had them)	Items don’t cross Space boundaries, only through migration
RAG / Confluence-synced data	Auto-loaded as context on Space switch	Must be manually attached via # and the {Space Name} - General collection
File upload (drag & drop)	Only in My Space	Available in all Spaces
Groups	One group per Space synced into My Space (so you saw membership there)	Synced into both My Space and the respective Space
Group identity	Same group name → same group everywhere	Same group name in different Spaces = different groups, with different permissions

For end users

• Your chats are untouched. Chat history is preserved as-is; the chat list shows chats from all Spaces mixed together. Opening a chat automatically switches the active Space to the one the chat belongs to.
• You can now upload files in any Space, not just My Space.
• You can now create assistants, collections, and prompt templates in any Space. They stay in the Space where you create them and won’t follow you across Spaces.
• If you used an assistant in My Space and want it in another Space, you’ll need to recreate it there — or use the migration tooling once we release it. Same for collections and prompt templates.
• In Spaces with synced data (e.g. Confluence), RAG content no longer attaches automatically. In each new chat, add the relevant collections (e.g. {Space Name} - General) via # or the + icon to make the synced data available as context.
• Sharing is per Space. A workspace item shared in one Space isn’t visible in another, even if both Spaces have a group with the same name. Items don’t move between Spaces; sharing applies only within the Space they live in.

Pick the right Space first

Before creating a workspace item, think about what other data you want to combine it with. Items can only reference other items in the same Space — an assistant in Space A can’t use a collection from Space B. Items don’t move between Spaces, so picking the right one up front saves rework.

If neither applies, just use My Space. Items are private by default regardless of Space; the choice mainly affects what you can combine and your maximum sharing scope.

For Space Owners and admins

Compliance: bounding the sharing scope

The choice of Space also bounds the maximum possible sharing scope of an item: an item in My Space can in principle be shared with every user of the system, while an item in a regular Space can only be shared with that Space’s members. This is a compliance feature — admins and Space Owners should give end users guidance on which Space to use for which kind of content. End users should not need to reason about this on their own.

Groups and permissions

• Groups are now scoped per Space. A group with the same name in two Spaces is treated as two completely separate groups, each with its own membership and permissions. Sharing config you set in Space A does not apply in Space B, even if both have a group called engineering.
• A user can be in groups of the same name in multiple Spaces and have different permissions in each — the permissions you see depend on the active Space.
• Groups are synced into both My Space and the respective Space. The previous behavior (sync only into My Space) has been extended; groups now also appear in the Space they belong to.

Sharing

Review your sharing config (which groups can see which workspace items) in each Space you own — sharing rules are now scoped per Space and need to be set up there.

What didn’t change

• Login, SSO, and user accounts
• Chat history (preserved across the migration; mixed view across all Spaces in the sidebar)
• The list of available LLMs in each Space
• Per-Space Confidentiality and other Space-level configuration
• Roles (User, Space Owner, Application Owner, Data Scientist, OpenWebUI-Admin)

Migration steps

Now that every Space supports collections, assistants, and prompt templates, you can build assistants directly in a Space using the Space’s data. Previously this was only possible in My Space, so it’s likely that data which logically belongs to a Space was kept in My Space to be used with assistants.

We recommend two migration paths to align your data with the new model:

1. Moving elements out of My Space

If you have collections, assistants, or other items in My Space that logically belong to a specific Space, move them there. Now that each Space has its own workspace items, there is no reason to keep Space-related data in My Space.

You have two options:

• Self-service: move individual elements yourself from My Space into the target Space.
• Bulk migration: contact us and we can move all elements that belong to a specific Space for you in one go.

2. Merging Spaces

With the introduction of collections, there is no longer a need to maintain multiple Spaces that are accessed by the same set of users. Data that was previously separated across Spaces can now be organized using collections within a single Space.

We recommend merging Spaces whose members are identical (or nearly identical) into one Space. This simplifies administration and makes it easier to combine data in assistants and chats. AutoSync configurations (S3) and data connections (Confluence) are migrated along with the Space merge.

Contact us to request a Space merge.