Dify Enterprise workspace management for multi-team organizations
Workspace management in Dify Enterprise covers creating workspaces for each team, assigning owners, archiving and deleting workspaces, and moving people between them from the admin panel. It matters once several teams build apps on one self-hosted Dify, because the Community edition is limited to a single workspace. Every team would then share one set of apps, knowledge bases, model settings and members, so ownership and data separation have to be handled by convention rather than by the product. The pricing page lists the self-hosted Enterprise edition as adding multiple workspaces, SSO, advanced security, a commercial license and professional support, so multi-workspace administration is one of the reasons an organization moves off Community. Confirm the exact admin screens and role names against the Enterprise documentation for your version before you write procedures around them.
Before creating the first workspace, decide what a workspace boundary means for your organization. Map each workspace to a team, business unit or data domain, and record who owns it, who may invite or remove members, and who approves archiving. The license also matters here: the Dify Open Source License forbids using the source code to operate a multi-tenant environment, where one tenant is one workspace, without written authorization. Ask your licensing contact to confirm in writing how many workspaces your Enterprise agreement covers and whether any internal arrangement, such as a shared environment for external partners, could be read as multi-tenant operation. Plan for that conversation before the workspace count grows.
Which admin actions change which workspace
Creating a workspace sets the boundary for the data, apps and credentials that team will use, and several of those choices are hard to undo later. A new workspace should start with no apps, knowledge bases or logs carried over from another workspace. Confirm that in a test workspace before the team relies on it, and settle naming, ownership and credential scope before anyone builds on the workspace.
- Apps and data: Confirm that a new workspace contains no apps, knowledge bases or invocation history from other workspaces.
- Credentials: Decide which model and tool credentials the team may use, and whether each one is managed inside the workspace or centrally from the admin dashboard.
- Encryption keys: The Dify environment reference says workspace encryption keys can be stored locally or in Azure Key Vault. Confirm which store your deployment uses before the workspace holds sensitive data.
- Members: Confirm whether creating a workspace adds any users automatically, and which SSO access scope controls entry.
Check the exact menu path for creating a workspace in your Enterprise version, because admin panel layouts change between releases.
The owner is the person accountable for a workspace's apps, members and credentials, so the assignment should match a named individual who is provisioned through your identity provider. Assigning an owner in the admin panel changes what that person can administer, but it does not move existing app ownership or data. Confirm the permission model before you grant the role, because owner rights can reach credentials and logs.
- Identity: Use an account that comes from your SSO provider, such as Microsoft Entra ID or Okta, so that access follows your joiner, mover and leaver process.
- Permissions: Confirm what owner rights include in your version, such as editing apps, managing members, viewing logs and changing credentials.
- Apps: Confirm whether apps created by a previous owner keep their original creator and remain editable after the change.
- Continuity: Name a second owner so the workspace always has an administrator, even when the first owner changes roles or leaves.
Before assigning an owner, check the role names and the menu path for the change in the admin panel of your release, and record the approval in your change log.
Archiving is the reversible option for a workspace that should stop being used but whose history may still be needed. What archiving freezes, hides or keeps running depends on your version, so the reader should not assume any of these effects. Test the behavior in a non-production workspace and write down what you observed before archiving a workspace that serves a live product.
- Running apps: Confirm whether published apps and their API endpoints stop answering requests after archiving, since downstream products may depend on them.
- Logs and data: Confirm whether invocation logs, knowledge base content and uploaded files remain readable, and for how long.
- Credentials: Confirm whether workspace credentials stay active. Live model or tool keys in an archived workspace still carry spend and data access risk, so plan their revocation as a separate step.
- Members and restore: Confirm whether members lose access immediately and whether an owner or admin can restore the workspace.
Record the archive date, the approver and the expected restore conditions in your change log, and check the menu path against your Enterprise version.
Deleting a workspace is the action most likely to be irreversible and the one that touches the most data. Treat it as a data disposal event: export what must be kept, confirm retention obligations with the data owner, and delete only after written sign-off. The Dify environment reference lists separate stores for metadata, files and vectors, so confirm which of them the deletion purges.
- Data stores: Confirm whether deletion removes records in the metadata database, files in object storage and embeddings in the vector store, or whether any of those need separate cleanup.
- App definitions: Export apps before deletion. The app management docs say DSL exports include app configuration, workflow nodes, prompts and knowledge base connections, and they state that third-party API keys, knowledge base content and usage logs are excluded.
- Backups: Confirm whether backups taken before deletion still contain the workspace, who may restore them and how long they are kept.
- Third-party keys: Revoke model and tool API keys in the provider console. Do not assume that deleting the workspace revokes them.
Confirm the confirmation steps and menu path for deletion in your Enterprise version before anyone starts the process.
Moving a person between workspaces changes what they can see, so the order of steps matters. Add the person to the destination first, then remove them from the source, and confirm that access in the old workspace ends when you intend. Access is usually governed by identity provider groups and workspace roles, so check both before the move.
- Access scopes: The Dify Enterprise SSO documentation describes separate SSO scopes for workspace access and web app access. Confirm which scope governs the move.
- Roles: Confirm the role the person receives in the destination and whether it differs from the role in the source.
- Apps they created: Confirm whether apps created by the person stay with the source workspace and who owns them afterward. Reassign ownership if the team needs them.
- Sessions and credentials: Confirm whether active sessions end when access is removed and whether any personal credentials move with the person.
Test the move with a test account first, and check the menu path and the order of operations against your version.
Workspace layout options and when each fits
This table compares four ways to divide Dify Enterprise into workspaces, with the condition that favors each one, the main trade-off and what to confirm before you commit. Read it as a planning checklist: pick the layout that matches how your teams own data and apps, then test the assumptions in the last column against your own environment.
| Layout | Fits when | Main trade-off | What to confirm |
|---|---|---|---|
| One workspace per department | Each department owns its own apps, model credentials and knowledge bases, and few apps need to be shared across departments | Shared knowledge bases and reusable apps end up duplicated, and cross-department reporting needs extra work | Whether any knowledge base or app must be visible to more than one department, and who approves cross-workspace sharing |
| One workspace per product line | Teams build and ship a product with its own release cycle and customer-facing AI features | Platform-wide standards for models, prompts and data handling must be repeated in each workspace | Which admin owns each product workspace and how credential and member changes are reviewed |
| One workspace per environment | You want a hard boundary between development and production apps and credentials | Promoting apps between workspaces adds steps, and people may need access to several workspaces at once | How app versions move between environments and which environment features your license covers |
| Shared workspace with role-based access | A small group builds a few apps and the organization needs few boundaries between teams | Access rules rely on roles inside one workspace, so mistakes in role assignment reach every app and dataset | Which roles Dify provides for your edition, and whether your identity provider can map groups to them |
| Hybrid of product and environment workspaces | Large product teams need both isolated delivery stages and clear ownership per product | More workspaces to name, staff and audit, and a larger set of owners to keep in sync | A written naming scheme, an owner for each workspace and a review schedule for membership |
Setting up workspaces from the admin panel
This sequence takes an Enterprise administrator from an agreed workspace model to a tested state where each team's members see only their own workspace. It produces a signed-off ownership record, working workspaces with named owners, and sign-in through your identity provider.
Agree the naming and ownership model
Before anyone creates a workspace, the platform team and business owners agree how workspaces map to teams, how they are named and who owns each one. Write the decisions down: one workspace per team or product, a naming convention, one accountable owner and a named backup for each, and which platform administrators may create or delete workspaces. This step is done when the record is signed off and every planned workspace has an owner entry.
Confirm the Enterprise license is active
The Dify pricing page lists multiple workspaces as part of the self-hosted Enterprise edition, while the Community edition is limited to a single workspace. In the admin panel, confirm that the edition and license status match what procurement agreed, and that workspace creation is available to your admin account. If creation is blocked, resolve licensing before continuing, because every later step depends on it.
Create the first workspaces
Create the pilot workspaces from the admin panel using the names from your convention. Start with two teams so you can test separation early, and keep the first set small so mistakes are cheap to correct. Confirm what a new workspace contains before you add apps, knowledge bases or credentials. This step is done when the workspace list shows exactly the planned names and no extra workspaces exist.
Assign a named owner to each workspace
Add one named owner per workspace, using an individual account from your identity provider and avoiding shared logins. Owners approve membership changes and manage their team's apps, so choose people who are likely to stay in that role. Confirm which roles your version offers and what each one can change before you assign them. This step is done when every workspace has an owner who can sign in and open it.
Connect identity so members can sign in
Connect Dify Enterprise to your identity provider so members sign in with their corporate accounts. The Enterprise SSO documentation lists OpenID Connect, SAML and OAuth2, with providers such as Microsoft Entra ID, Okta and GitHub. Keep workspace access and web app access as separate SSO scopes, and confirm which group or attribute claims map to each workspace in your version. This step is done when a test user from the provider signs in and reaches only the workspace mapped to that user.
Add and move members between workspaces
Add each person to their team's workspace. When someone changes teams, add them to the new workspace first and remove them from the old one second, so they do not lose access to work they still need during the change. Confirm what happens to apps and content a person created when they leave a workspace, because that behavior should be checked in your version. This step is done when both workspaces' member lists match the approved roster.
Verify access with a test account
Create a non-owner test account in one team and sign in as that user. Confirm it cannot see another team's apps, knowledge bases, members or settings, and that it can open its own team's workspace. Repeat the test from the other team's side, and run it again after any move or role change. Name the test accounts clearly so they can be removed later. This step is done when the results are recorded and a non-owner cannot see another team's apps in either direction.
Archiving versus deleting a workspace without losing evidence
Decide whether a workspace must be kept before anyone clicks delete. Keeping a workspace for audit or reuse preserves its apps, knowledge bases, logs and membership history in one place, while deletion removes the workspace and the artifacts inside it. Before choosing, confirm with the Dify Enterprise admin panel and your Enterprise documentation what the archive state does, whether an archived workspace still appears in organization-wide views, and who can restore it. Do not assume the behavior matches the Community edition, which is limited to a single workspace and therefore gives you no comparable admin workflow.
Treat deletion as irreversible until your own testing shows otherwise. Confirm in a staging copy what is removed with the workspace: apps, knowledge bases and their indexed content, member assignments and the workspace's logs. Then take a database and file storage backup before any destructive step, since the Dify Docker Compose upgrade guidance makes the same point about backups before changes. Exporting app DSL files is useful for reuse, but the Dify app management documentation describes exports as excluding third-party API keys, knowledge base content and usage logs. Those items must be recorded or preserved by other means.
Write down the evidence you must keep before the change. For a regulated team this usually means the app configurations, the prompt and workflow versions in use, the model and knowledge base connections, the member roster with roles at the time of deletion, and the invocation records your auditors may request. Ask your auditors which of these they need and for how long, and confirm with your records team where exported files and backups will be stored and who may access them. Only then should the workspace be archived or deleted, and the change should be logged with the approver's name.
Access and data risks when workspaces change
Creating, archiving and moving people between workspaces touches access, credentials, evidence and the admin plane at once. The cards below cover the risks that show up most often when a workspace changes hands, and the control to plan for each before the admin panel is used in production.
Owner sprawl and orphaned workspaces
Every workspace needs a named owner who can approve access, rotate credentials and answer for the apps inside it. When a team reorganizes, workspaces can outlive the people who created them, and apps keep running with nobody accountable for them. Before rollout, assign an owner and a backup owner to each workspace, record them in your register, and set a recurring review that flags workspaces whose owner has left. Confirm with DeployOpen's plan how ownership transfers when someone leaves the organization.
Members keeping access after moves
Moving a person from one team workspace to another does not automatically remove the access they held in the old one. A member who keeps prior access can still open apps, review data and run workflows that belong to a team they no longer work with. Treat every move as two changes: add to the new workspace and remove from the old one. Check the member list of each affected workspace after the move and compare it with your identity provider groups.
Credentials tied to a workspace
Model and tool API keys configured inside a workspace stop working when that workspace is archived or deleted, and apps that depend on them fail without warning. Keys may also be copied into several workspaces, so a single rotation can miss some of them. Inventory which credentials each workspace holds, decide which ones belong to the organization rather than a team, and plan rotation as one operation so no app is left on an old key.
Deleting logs needed for investigation
Deleting a workspace removes the apps, runs and records that an incident review may need to reconstruct what a model was asked and what it returned. Archiving a workspace is a reversible step that keeps that evidence available, while deletion is not. Before any deletion, export the relevant run history and configuration, confirm with your security and records owners what they must retain, and document the decision. Check Dify's current retention behavior for your version with the vendor.
SSO scope mismatch between workspace and web app access
Dify Enterprise SSO defines separate scopes for workspace access and web app access, so a user can sign in successfully to the console yet still lack rights to a published app, or the reverse. When a workspace is restructured, these two scopes can drift apart and produce access that is wider than the team intended. Map each identity provider group to both scopes on purpose, and test one user from each group against the console and a published web app after every change.
Admin account protection
Admin accounts can create, archive and delete workspaces and move any member, so a compromised admin login affects the whole organization. The risk grows when several people share one admin account or when admin rights are granted to people who only need workspace owner rights. Limit admin roles to a small named group, require strong sign-in through your identity provider, keep at least two admins so no single departure locks the platform, and review admin activity on a schedule.
Questions teams ask before changing workspaces
What does a workspace setup project cost and what drives it?
Cost depends on how many teams need their own workspace, how much identity integration is involved, and whether existing apps must move into the new layout. Each team adds ownership decisions, role mapping and access testing, so the number of teams is usually the largest driver. Identity integration adds work when workspace access must follow groups in your directory rather than manual invitations. Migrating existing apps adds export, review and re-testing of apps, credentials and knowledge base connections. DeployOpen does not publish prices, so ask for a quote built from a written scope that lists each team, each identity source and each app set to move. Ask which items are one-time setup and which recur, such as support or upgrades under a retainer.
How long does workspace restructuring take and what does it depend on?
Duration depends on the number of teams, the state of your identity groups and how many apps and credentials need to move. Planning and approvals usually take as long as the technical changes, because owners for each workspace must be named before anyone is moved. Dependencies include access to the Enterprise admin panel, a current backup, agreement on naming and a test workspace where changes can be checked first. Ask any partner to state the timeline in the written scope with its assumptions, and confirm the dependencies with your own platform team before work starts.
What does the client team need to provide for this work?
You need a named executive sponsor, a platform owner who can approve admin panel changes, and a business owner for each team workspace. Your identity team must confirm how users and groups are managed, and your security team should review who may hold workspace owner or admin roles. You also need a list of existing workspaces, their apps and their members, plus a current backup of the Dify database and file storage. Before any change, confirm the Dify version and the Enterprise license status with your vendor contact, since these determine which admin features are available in your deployment.
Can an internal team set up workspaces without a partner?
Yes, if the team has Kubernetes and Dify administration experience and can test changes outside production. Creating workspaces, assigning owners and adjusting membership are admin panel tasks that do not require code. The harder parts are designing the ownership model, aligning access with identity groups and proving that apps and credentials still work after a move. Internal teams often underestimate the testing and documentation effort. Consider a partner when many teams change at once, when audit evidence must be prepared, or when the internal team lacks time to run the change in a staging environment first.
How do you move a person from one workspace to another?
Add the person to the destination workspace with the role they need, confirm they can open the apps they require, then remove their membership from the original workspace. Do the steps in this order so the person is never left without access during a handover. Record the change with the requester, the approver and the date. If the person's access is driven by directory groups, change the group membership in your identity provider instead of editing the workspace by hand, because manual edits will be overwritten or drift over time. Check that app owners in the old workspace have reassigned any apps the person maintained.
What happens to apps when a workspace is deleted?
Deleting a workspace removes the apps, knowledge bases and data it holds, so treat deletion as irreversible unless your backup process proves otherwise. Before deleting, export app configurations as YAML DSL files, which include workflow nodes, model parameters, prompts and knowledge base connections. Note that exports do not include third-party API keys, knowledge base content or usage logs, so you must record and re-enter credentials separately and keep the logs under your retention rules. Archive first where possible, confirm with the Dify docs for your version how deletion behaves, and retain a restorable backup for the period your records policy requires.
Does moving people or apps between workspaces affect security controls?
It can. A new workspace may inherit different owners, model credentials or sign-in scopes, so review access after every move. Confirm which credentials the destination workspace can use, because credentials in one workspace should not be assumed to be available in another. Verify that the destination workspace's SSO access settings match the people who joined it, and that former members no longer hold owner or admin roles. Keep a short checklist for each change so reviewers can see that access was reduced as well as granted.
How DeployOpen scopes workspace management work
DeployOpen plans and implements Dify Enterprise workspace structures inside your own infrastructure, whether that is your cloud accounts, data centers or an air-gapped network. The first step is a written scope that names the workspaces to create, the owner of each one, the members who move in and out, and the archive or deletion rules that apply. Most engagements of this kind are fixed-scope, so the deliverables and the timeline are agreed in writing before any change is made to the admin panel. Your team receives the owner register, the workspace naming convention and the change record that shows who was moved, when and under which approval.
Ownership is documented as part of the build, not left to memory. For each workspace, the scope records the accountable owner, the team that operates the apps inside it, and the person who approves moves between workspaces. Archiving and deletion are handled as separate, reviewed changes, with a check that no production app still depends on the workspace and that the backup taken before the change can be restored. The Enterprise scope also covers how workspace access lines up with your identity provider groups, so that a membership change in the directory is not the only record of who can reach an app.
DeployOpen can continue after the initial change under a retainer, which covers ongoing workspace requests, owner reviews and changes that follow Dify release upgrades. Before you request a quote, ask for the workspace inventory you need to start, the approval path for member moves, the rollback steps for a failed change and the exact deliverables and dates listed in the written scope. Confirm with your Dify Enterprise representative which admin panel functions and roles are available in the version you run, because the options depend on your licensed edition and release.
