How Dify workspace roles and member management fit a regulated team
A team about to give several people access to a self-hosted Dify workspace needs to decide three things before the first invitation goes out: who can edit apps, who can only use published apps, and who owns the workspace. Dify answers this with four built-in Community roles: Owner, Admin, Editor and Normal. Each workspace has exactly one Owner, so ownership is a single accountable position rather than a shared one. Admins manage members and settings, Editors build and change apps, and Normal members can only use apps that have already been published. For a regulated team, the practical split is usually a small set of Editors who build and change workflows and a larger group of Normal users who run approved apps.
Plan the Owner account with the same care as a privileged administrator account, because the Owner holds the highest level of control in the workspace and only one person can hold it at a time. Confirm with your own environment how ownership transfers before someone leaves the team, and record who holds the role and who is the backup. Invitation links expire after 72 hours by default, controlled by the INVITE_EXPIRY_HOURS setting, so check that value in your deployment and decide whether that window suits your onboarding process. Also confirm in the Dify member management documentation how knowledge base visibility behaves for each role before you grant anyone Editor access.
Custom roles with granular app and knowledge access are an Enterprise feature, not part of the Community edition. If your governance requires that a specific group can edit only certain apps or see only certain knowledge bases, that requirement is a signal to compare the Community roles against the Enterprise edition, which the Dify pricing page describes as custom priced. Write that requirement down early, because it changes the licensing conversation and the workspace layout, and it is far harder to retrofit after many apps and members exist.
Which Dify role fits each kind of member
This table compares the four built-in Community roles by what each can change, who should hold it and how it touches published and draft apps. Read it as a starting point for least privilege: give the Owner role to one accountable person, and default most people to Editor or Normal. The main takeaway is that Normal members only see published apps, so draft work stays with the people who build.
| Role | What it can change | Who should hold it |
|---|---|---|
| Owner | Everything in the workspace, including ownership transfer. Only one Owner exists per workspace. | One accountable administrator, such as the platform owner. Keep a named backup who knows the transfer process. |
| Admin | Manages members and workspace settings, and can work on apps. Confirm the exact permissions in the member docs for your version. | Platform engineers who run day-to-day administration, kept to a small group. |
| Editor | Builds and edits apps and knowledge bases, working on draft versions before publishing. | Developers, prompt engineers and knowledge owners who build workflows. |
| Normal | Uses only published apps. Cannot see or edit drafts. | Business users, reviewers and staff who consume finished apps. |
| Draft apps | Visible and editable by Owner, Admin and Editor roles, not by Normal members. | Limit draft access to people who are accountable for changes that reach production. |
| Published apps | Available to Normal members once published, so publishing is the release gate. | Require a review step before anyone publishes to a shared workspace. |
| Custom roles | Granular app and knowledge access is an Enterprise feature, not part of Community roles. | Consider Enterprise when you need per-app or per-knowledge-base separation inside one workspace. |
How invitation links expire and what to do about it
Dify invitation links expire after 72 hours by default, a window controlled by the INVITE_EXPIRY_HOURS environment variable. Confirm both the default and the variable name in the environment variable reference for the release you run, because operators should not plan around a figure they have not checked against their own version. The expiry matters most during rollout waves, when a batch of invitations goes out on a Friday and a share of recipients open them the following week. Decide before go-live whether 72 hours fits your onboarding pattern, and whether your administrators will be available to re-issue links quickly.
Expired links are a routine event, not an incident. A new member who opens an old link will be turned away, and the fix is to re-issue an invitation from the workspace member management page, which requires an Owner or Admin account. Plan who holds that permission and document the request path so a help desk can handle it without asking an engineer. Misaddressed invitations need the same attention: an invitation sent to the wrong mailbox can sit unclaimed until it expires, and anyone who can read that mailbox could claim the seat. Check the spelling of addresses in bulk imports, and remove stale invitations rather than leaving them open.
Time zones add friction. A link sent at the end of one administrator's working day may expire while staff in another region are still asleep, and a 72-hour window can close over a weekend. Ask each team to name a local contact who can trigger re-issue, and schedule invitation batches for times when an administrator is online to respond. Confirm the exact behavior with the Dify member management documentation, including whether an expired invitation can be resent, so your runbook matches the version you deploy.
How to set up roles and members in a self-hosted workspace
This sequence gives a self-hosted Dify workspace a confirmed owner, deliberate invitation settings, tested role boundaries and a written role map that the team can audit later.
Confirm the owner account and recovery path
Identify the single Owner account for the workspace, since Dify allows one Owner per workspace. Confirm who holds the credentials, where recovery material is stored and who can reset access if that person leaves. Because SECRET_KEY signs session cookies and JWTs, make sure the team knows that changing it after deployment logs out all users, so it is not changed casually during recovery work. The step is done when a named person can sign in as Owner from a second approved route and the recovery steps are written down.
Set the invitation expiry deliberately
Review the INVITE_EXPIRY_HOURS setting in the environment file. Dify's default for invitation links is 72 hours, so decide whether that window fits your onboarding process or whether a shorter value is needed, then record the chosen value and the reason in your deployment notes. Check that the value in the running container matches the value in the file after any restart. The step is done when the configured value is confirmed in the running instance and the team agrees on it.
Invite members by role
Invite each person with the role their job requires: Admin for workspace administration, Editor for building and changing apps and knowledge bases, and Normal for people who should only use published apps. Keep the Owner role for the single accountable owner. Record each invitation in your access register with the requester, approver and date, so that later reviews can match accounts to approvals. The step is done when every invited account appears in the workspace member list with the intended role and no role was assigned by default without review.
Test the Normal role against unpublished work
Sign in with a Normal test account and try to open an app that is still in draft. A Normal user should only be able to use published apps, so the draft should not be reachable for normal use. Repeat the check with an Editor account to confirm it can edit drafts but cannot perform administrator tasks. Use a test app that you create for this purpose, not a production app. The step is done when each test account reaches only the screens and apps the role map allows, and any surprise is logged for correction before users arrive.
Verify knowledge base visibility for each role
Check which knowledge bases each role can see and use, and confirm that a Normal account cannot reach knowledge content it should not read. Dify's built-in roles do not provide granular per-app or per-knowledge-base access control, which is an Enterprise feature, so any restriction you need beyond role boundaries must be handled by separating workspaces or by limiting what is placed in the shared workspace. Ask your Dify contact or review the member documentation to confirm what the Community edition does before relying on it. The step is done when the team has a written statement of what each role can see in knowledge bases.
Document the role map and review cadence
Write a role map that lists each role, the people or groups assigned, the screens and apps each role can reach, the test results from the earlier steps and the approver for each change. Store it in the document system your auditors and operators already use, and name the owner who keeps it current. Set a review point, and revisit the map after each Dify upgrade, since release notes can change behavior. The step is done when the map is stored, approved and linked from the operations runbook.
Transferring ownership without locking yourself out
A single Owner is a continuity risk. Dify allows one Owner per workspace, so whoever holds that role controls the workspace's most sensitive settings, and if that person leaves, changes roles or loses access, nobody else may be able to make the decision. Before you transfer ownership, make sure the new owner is a named person you trust, and confirm that a second trusted Admin already exists who can manage members and reach the console if the primary account is unavailable. Treat that Admin as part of the plan, not an afterthought.
Three checks belong in the change plan before anyone clicks anything. First, the incoming Owner or the second Admin should sign in with their own credentials and confirm they can open the workspace, view members and reach the settings they will need, so the transfer is not the first login test. Second, record the change in your own change log with the date, the outgoing and incoming accounts, the approver and the reason, since Dify's role history will not give you the context auditors and your own team will ask for. Third, agree who holds the instance-level access, such as the server, Docker host and .env file, because workspace ownership does not grant control of the underlying deployment.
The exact transfer steps depend on the Dify version you run, and the member management interface has changed over time. Check the current member management documentation for your installed release before you plan the sequence, and run the procedure first on a non-production workspace if you have one. Confirm with your own environment whether the outgoing Owner's sessions and invitations need attention afterward. Where your Dify edition or identity setup differs, confirm that behavior with the vendor rather than assuming it carries over.
How knowledge base visibility interacts with roles
Role assignment in Dify also decides who can reach the documents behind an app. The decisions below connect member roles to knowledge base access, so a team can confirm what each role exposes before inviting people.
Normal role reach into source documents
A Normal member can only use published apps, so the first question is whether that use exposes source material. An app that answers from a knowledge base can return passages to any user who can run it. Check which knowledge bases each published app references, and whether the answers quote or cite documents that the member should not read directly.
Editor access to knowledge bases
Editors can build and change apps, and in a shared workspace that can extend to the knowledge content those apps use. Decide whether editors should add or replace documents, or only change prompts and workflow logic. Confirm in the docs how knowledge base editing permissions are scoped for Editors, because this boundary determines who can alter the data behind answers.
Admin reach across the workspace
Admins manage members and most workspace settings, so an Admin account effectively sees the whole workspace configuration. Limit the number of Admins, and keep the Owner role for a single accountable person. Review who holds Admin during each access review, since broad administrative rights are the easiest path to exposing documents.
Knowledge base scope in Community
The Community edition runs a single workspace with the four built-in roles, and custom roles with granular app and knowledge access are documented as an Enterprise feature. Ask the vendor to confirm in the current member docs whether knowledge bases can be restricted per member in Community, rather than assuming one shared visibility level for all non-admin roles.
Granular knowledge access in Enterprise
Where teams need different members to see different knowledge bases or apps, the custom role model is the reason to evaluate Dify Enterprise. Ask for a written list of which permissions custom roles control, including knowledge base read, edit and use, before deciding. Treat that list as the basis for the quote, not the marketing summary.
Testing visibility before go-live
Create one test account per role and attempt each action against a sample knowledge base, including viewing source documents through an app and exporting app configuration. Record the results and repeat the test after each upgrade, since role behavior can change between releases. Keep the evidence with the access review record.
When custom roles push a team toward Dify Enterprise
Do custom roles in Dify require the Enterprise edition?
Yes. Dify's member documentation lists four built-in roles in the Community edition: Owner, Admin, Editor and Normal. Custom roles with granular access to individual apps and knowledge bases are an Enterprise feature. If your team needs a role that, for example, can edit one knowledge base without seeing others, the built-in roles will not cover it. Confirm the exact role permissions in the current member documentation before you finalize a design, because the role matrix is the detail most likely to change between versions.
Why does the Community edition limit how many workspaces I can run?
The Dify pricing page describes the self-hosted Community edition as free and limited to a single workspace, while the self-hosted Enterprise edition adds multiple workspaces. This matters for role design because teams that want to separate business units, environments or customers often use separate workspaces to keep members and knowledge apart. If one shared workspace cannot express your boundaries, you are deciding between a single workspace with coarse roles and an Enterprise license. The Dify Open Source License also prohibits operating a multi-tenant environment without written authorization, so running several Community workspaces to imitate tenancy is not a route to take without that permission.
When does SSO push a team toward Dify Enterprise?
SSO is the second common driver. The Dify Enterprise SSO documentation lists OpenID Connect, SAML and OAuth2, with identity providers such as Microsoft Entra ID, Okta and GitHub, and separate SSO scopes for workspace access and web app access. If your workforce signs in through a central identity provider and access must end when someone leaves, manual invitations and local accounts become an audit gap. Check which login options the Community edition supports for your identity provider before assuming Enterprise is required, since login options and sign-up policy are separate settings.
Does Dify Enterprise provide SCIM provisioning for workspace members?
Confirm this with Dify before you plan around it. SCIM provisioning is a driver teams often raise because it automates joiners, movers and leavers from the identity provider. The researched material supports the SSO protocols and scopes described above, but it does not settle the SCIM details for your version. Ask the vendor whether SCIM is included in the edition you are quoting, which identity providers it supports, how deprovisioning removes app and knowledge access, and whether role mapping from groups is available. Get the answer in writing rather than inferring it from marketing pages.
How much does Dify Enterprise cost?
Dify does not publish a price for the self-hosted Enterprise edition. The pricing page describes it as custom priced and includes SSO, multiple workspaces, advanced security, a commercial license and professional support. The Community edition is free, but it is not a like-for-like comparison. The cost difference depends on the license scope, the number of workspaces, your support expectations and the deployment target. For reference, the same page lists Dify Cloud plans at 590 US dollars per year for Professional and 1,590 US dollars per year for Team, but those are cloud subscriptions and do not price a self-hosted Enterprise license.
What should we ask Dify for in an Enterprise quote?
Ask for a written quote that lists the edition, license term, and what the license covers, including workspace count and whether it is a commercial license for your use case. Ask which features are included: custom roles, SSO protocols and scopes, SCIM, advanced security settings and multi-workspace management. Ask about professional support scope, response expectations and how upgrades are handled. Also ask what the Enterprise deployment requires, which the resources checklist describes as Kubernetes, Helm, PostgreSQL, Redis, a vector database and object storage, and whether those are your responsibility. Recurring and one-time costs should be separated in the quote.
Can a partner help us design roles before we decide on Enterprise?
Yes. DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure, so role design can be scoped as its own piece of work. Typically that means mapping who needs to build apps, who needs to publish them, who should only use published apps and which knowledge bases must stay restricted. The output is a written role matrix you can test against the built-in roles and the Enterprise feature set. The scope, deliverables and timeline are agreed in writing before work starts, and the price follows from that scope.
What breaks if we stay on built-in roles but grow the team?
The main risk is over-permissioning. With four built-in roles, teams often give Editor access to people who only need to test one app, or they share a single Owner account. Owner is limited to one per workspace, so ownership transfer becomes a planned step, not an afterthought. Invitation links expire after 72 hours by default, controlled by INVITE_EXPIRY_HOURS, which limits exposure from unused links but does not replace an offboarding process. Review membership on a schedule, record who holds Admin and Owner, and decide early whether that operating model is acceptable for your audit scope.
Limits to confirm in your environment
Dify's role model and member handling are documented, but several details depend on the release you install and on your edition. The cards below list what to confirm against your own version and environment before you write an access policy, so the design does not rest on assumptions.
Role matrix for your version
The four built-in roles are Owner, Admin, Editor and Normal, and Normal users can only use published apps. Confirm the exact permissions for each role in the release you run, since menus and rights can change between minor versions. Record the matrix as tested in your own instance, not as copied from the docs, and retest it after every upgrade.
Invitation expiry on your release
Invitation links are documented to expire after 72 hours by default, controlled by INVITE_EXPIRY_HOURS. Confirm that the setting exists and takes effect in your installed version, and check how an expired link is reissued. Test an invitation end to end so you know whether an unused link can still be accepted after the window closes.
Practical member ceiling
Community documentation does not set a member limit for a workspace, and the community edition is limited to a single workspace. Ask the vendor or test in staging how many accounts your team expects to manage, and measure how the console behaves with that population. Also confirm how account administration scales if you plan to hand member changes to an identity process.
Owner transfer behavior
Each workspace has one Owner, and transferring that role is the step that changes who controls billing, members and settings. Confirm in your version that the transfer works as the docs describe, who must perform it, and whether the previous Owner keeps any residual rights. Rehearse the transfer with a test account before an organizational change depends on it.
Roles after an upgrade
Upgrades can change the schema, environment variables and the permission model, so a role assignment that worked before a jump may behave differently afterward. Take a backup before every upgrade, follow the upgrade guide for the target version, and check .env.example for new variables. Then verify each role against your test matrix before returning users to production.
Custom roles and knowledge visibility
Custom roles with granular app and knowledge access are an Enterprise feature, so Community roles cannot separate access to individual knowledge bases. Decide whether your policy needs that separation, confirm which knowledge base visibility settings your edition offers, and document the gap if you rely on Community roles. Enterprise SSO scopes are a separate question to confirm with the vendor.
Questions teams ask before setting up Dify roles
Can a Community Dify workspace use custom roles?
No. Custom roles with granular app and knowledge access are an Enterprise feature, so a self-hosted Community deployment works with the four built-in roles: Owner, Admin, Editor and Normal. Owner is limited to one per workspace, and Normal members can only use published apps. The Community edition is also limited to a single workspace, so teams that need separate access boundaries across business units usually have to look at the Enterprise edition or split the work across separate instances, which carries its own licensing and operating cost. Confirm current limits with the Dify pricing page before you commit to a design.
How much effort does Dify role design take?
The effort depends less on Dify's settings and more on how many distinct groups need different access to apps and knowledge bases. With four built-in roles, the work is mapping each person to a role, deciding who may edit prompts and workflows, and deciding which knowledge bases are shared. Effort rises when there are many teams, regulated data sets that must be kept apart, external contractors, or a requirement to prove who changed what. Expect the largest share of time to go into agreeing the access model with data owners and reviewing it before go-live, not into clicking through the console.
What does the internal team need to provide?
A named owner for the workspace, a list of the teams and roles that need access, and the data owners who can decide which knowledge bases and apps are visible to which group. Your team also needs someone who controls the identity provider and email domains, because invitation links and sign-in depend on them. For a self-hosted deployment, the team should also own the host, the backups and the decision about who holds the Owner account. Without these inputs, role decisions get made by default and are hard to reverse later.
Can our own engineers set up Dify roles without a partner?
Yes, for a small team with clear rules. Setting the four built-in roles, sending invitations and transferring ownership are administrative tasks inside the console, and the Dify member management documentation describes them. A partner adds value when the access model is complex, when you need to document the decisions for a compliance assessment, or when you want the design reviewed against your identity and data governance policies. Whichever route you take, have someone other than the workspace Owner review the role assignments.
How do invitation links expire in Dify?
Invitation links expire after 72 hours by default, controlled by the INVITE_EXPIRY_HOURS setting. Teams that need a shorter or longer window can change that value in the environment configuration, and should record the choice in their access procedure. Expired links are not a security control by themselves, so you still need to confirm who received each invitation and remove members who no longer need access. Check the Dify environment variable reference for the current behavior in your version.
How long does Dify role setup take, and why is Enterprise pricing quoted?
Setup of the built-in roles in a small workspace can be done in a short working session, and the time grows with the number of groups, apps and knowledge bases. Dify does not publish a price for the self-hosted Enterprise edition because it is custom priced, and the Dify pricing page lists it that way. Ask any provider for a written scope that states the number of workspaces, identity integrations, roles and environments, along with what is one-time and what recurs, such as support and upgrades. DeployOpen does not publish prices and provides a quote from the written scope.
Who can see knowledge bases in a Dify workspace?
Visibility of knowledge bases depends on the roles and sharing settings in the workspace, and the Community edition does not offer granular per-knowledge-base access control for custom roles. Treat any knowledge base containing sensitive data as visible to every member who can reach its workspace, unless you have confirmed the current behavior in your version. Before loading regulated content, have the data owner confirm the sharing model in a test workspace and document the result.
How DeployOpen scopes and supports Dify access design
DeployOpen plans Dify workspace roles, member onboarding and knowledge base visibility as part of the deployment, before users are invited. We write the access model down, build it in your self-hosted instance, and hand over the settings and runbooks your administrators need to keep it current.
How we scope
- We map who needs Owner, Admin, Editor or Normal access to each workspace and why.
- We record how invitation links are issued, how long they stay valid, and who may send them.
- We agree in writing which role or workspace decisions depend on a Dify Enterprise license before work starts.
How we build
- We configure workspace roles, the single Owner assignment and ownership transfer steps in your instance.
- We set up knowledge base visibility and publish rules so Normal members only reach approved apps.
- We test each role against a documented list of permitted and blocked actions before any real user is invited.
How we hand over
- We deliver a role matrix, invitation procedure and offboarding checklist written for your administrators.
- We document where access settings live, which changes need review, and how to record approvals.
- We walk your team through the handover so they can add members and transfer ownership without us.
How we support
- Ongoing support, upgrades and periodic access reviews are available as a retainer after handover.
- We recheck role settings after each Dify release, since minor versions arrive roughly monthly.
- We confirm with you which access questions need your identity provider or the vendor, and track them to closure.
