> For the complete documentation index, see [llms.txt](https://docs.wem.io/platform/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.wem.io/platform/wemmodeler/user-roles-scheme.md). # User Roles Scheme A WEM user has a specific role within a Workspace or Project. When you create a new Workspace, you automatically become the Owner of that Workspace. Via button \[Manage projects & workspaces] in the Modeler, you can (with the proper rights) manage user roles. {% hint style="info" %} In future, a new WEM Account Management Portal will be launched, which will provide more fine-grained options to assign roles and rights to users. {% endhint %} ### Workspace Rights

Workspace-level User Rights

#### Specific rights only applicable to a Workspace: > (Working upwards in the list as displayed above) | Rights | Features | | ---------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | **Manage workspace** | | | **Edit design (master) templates** | add design template collections with a share-code. | | **Edit widgets** | create/edit/delete widgets in Widget Editor. | #### Rights applicable to all projects in a Workspace | Rights | Features | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Manage projects** | manage all projects in workspace, specifically manage user-rights on project-level. | | **Configure projects** | | | **Debug live** | \*new\* specific right to start debugger on the live portals. | | **Debug staging** | \*new\* specific right to start debugger on the staging portals. | | **Publish to live** | \*new\* specific right to publish to the live environment. | | **Publish to staging** | \*new\* specific right to publish to the staging environment. | | **Edit projects** | make changes to project contents, elements, flowcharts, datamodel. | User rights applied on Workspace level, will apply to all projects within the workspace, and will be applied to new projects created in this workspace in the future. Any specific right is as described: there is no inheritance or implicitness. If you need to be able to publish to both staging and live, you need to have both specific rights. Publish to live does NOT give you the right to publish to staging implicitly. ### Project Rights For users that do not get Workspace-level rights, you can apply Project-only rights, applicable to only that project.

Project-level user rights

*See the single "Project" label with some of the rights, as opposed to the plural "Projects" for the Workspace-level rights.* These Project-level rights can only be applied to users that do not have any Workspace-level rights. Any user either has rights on Workspace and therefore on all contained projects, or has rights on singular projects (and needs to get those specific project-rights assigned to every project). | Rights | Features | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Manage project** | manage this project, specifically manage user-rights on project-level. | | **Configure project** | | | **Debug live** | \*new\* specific right to start debugger on the live portals for this project. | | **Debug staging** | \*new\* specific right to start debugger on the staging portals for this project. | | **Publish to live** | \*new\* specific right to publish the portals of this project to the live environment. | | **Publish to staging** | \*new\* specific right to publish the portals of this project to the staging environment. | | **Edit project** | make changes to project contents, elements, flowcharts, datamodel. | ### **Read-Only Access** Accounts can be added to a workspace or project without being assigned a role. These accounts have read-only access, meaning they can view the workspace or project they were added to, but cannot make any changes. Any change, in overlays for example, that appear to be editable will not be saved. **What read-only users can access** Read-only access prevents users from making changes, but does not restrict what they can view. Users with read-only access have full visibility into the project's contents, including any calculated fields that may contain sensitive information. Keep this in mind when adding users without a role to projects that contain confidential data; read-only is not the same as restricted access. *** ### The old role-based situation Previous versions of Modeler used the following roles: | User role | Description | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | Workspace User | A User on Workspace-level has the right to work on all projects in the Workspace (i.e. model and build an application) | | Workspace Power User | A Power User has the same rights as a regular User, but can also: publish and configure all projects as well as edit widgets | | Workspace Admin | An Admin has the same rights as a Power User, but can also: manage projects and workspace settings | | Workspace Owner | An Owner has the same rights as an Admin, but can also change ownership. There can be only one | | | | | Project User | A User on project-level has the right to work in this specific project (i.e. model and build an application) | | Project Power User | A Power User has the same rights as a regular User, but can also: publish and configure this project | | Project Admin | An Admin has the same rights as a Power User, but can also: manage project | #### **In schematic:** | Action | Project | | | Workspace | | | | | | ---------------------- | ------- | ---------- | ----- | --------- | ---------- | ----- | ----- | --------------------------------------------------------------------------------------- | | | user | power user | admin | user | power user | admin | owner | | | Edit project | \* | \* | \* | \* | \* | \* | \* | make changes to project elements, flowcharts, datamodel | | Publish project | | \* | \* | | \* | \* | \* | publish to staging and live environments to make the application available to end-users | | Configure project | | \* | \* | | \* | \* | \* | edit project settings, create/copy/delete portals | | Manage project | | | \* | | | \* | \* | manage project-level users | | Edit widgets | | | | | \* | \* | \* | create/edit/delete widgets | | Manage workspace | | | | | | \* | \* | create/copy/delete projects, edit workspace settings, manage workspace-level users | | Change workspace owner | | | | | | | \* | change the owner of the workspace | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.wem.io/platform/wemmodeler/user-roles-scheme.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.