Collaboration
In most traditional 3D engines, collaborating as a team can be challenging. Team members must constantly synchronize their local project files, which often leads to conflicts—especially when multiple people edit the same assets or scenes. Resolving these conflicts can be time-consuming and disrupt the workflow.
A key strength of 3dverse is its focus on streamlining collaboration. The platform enables smooth teamwork through real-time updates and shared access to assets and projects.
However, responsibilities and access privileges must be managed carefully to ensure security and efficiency.
In this chapter, you'll learn how to invite collaborators, and understand how to secure your projects by assigning roles and permissions.
Hierarchy
Collaboration is structured around a hierarchy:
- Organization (top level)
- Project (workspace inside an organization or in a personal space)
- Environment (a specific instance of a project)
You can invite collaborators at the organization and project levels of this hierarchy. The access they receive is determined by both the role you assign and the level at which they are invited.
Team
From the Team page of your organization or project, you can see and manage all collaborators by assigning them roles.
Roles and Permissions
On a project, each collaborator is assigned a role that defines what they can and cannot do.
- Viewer: Read-only access. Can view all resources but cannot make changes.
- Editor: Can create, edit, and modify all resources.
- Admin: Full control, including deleting all resources and managing collaborator roles.
The role assigned to a collaborator at a higher level in the hierarchy cascades down to lower levels, unless overridden by a more permissive role at a lower level.
| Resource | Viewer | Editor | Admin |
|---|---|---|---|
| Organizations | Read organization details, list accesses | – | Read metrics, grant/revoke access to collaborators, update organization details, delete organization |
| Projects | Read project details, read metrics (storage, usage, sessions), list accesses | Update project details | Create/delete/move project, grant/revoke access to collaborators |
| Environments | Read environment details | Update environment settings | Create/delete environment |
| Folders | Browse folders, list assets, list accesses | Create/rename folder | Delete folder, grant/revoke access to users and groups |
| Assets | Read asset | Create/edit asset, move assets to trash | Delete asset |
| Users | List users, read user details, list accesses | Update user settings | Create/delete user, update settings, create user token |
| Groups | List groups, read group details, list accesses | Update group details | Create/delete group, grant/revoke access |
| API Keys | List API keys | – | Create/revoke API key |
| Sessions | List sessions, read session details and logs, download crash dumps | – | Kill session, kick client |
| Webhooks | List webhooks | Create webhook, Update webhook | Delete webhook |
| Upload Tasks | Read conversion task logs | Upload source files | – |
Inviting Collaborators
From the Team page of your organization or project, you can invite new collaborators by clicking the Invite button.
Invite from Organization
- Grants access to all projects and environments within the organization.
- The assigned role applies everywhere in the organization.
If you invite Jane as an Editor to the organization, she can edit all projects and all environments under that organization.
Invite from Project
- Grants access to a specific project and all its environments.
- The role applies consistently across the project.
If you invite John as a Viewer to the "Car Configurator" project, he can open all environments in that project but cannot edit them.
How Roles Apply Across the Hierarchy
When a collaborator is invited at multiple levels with different roles, their permissions are combined. The most permissive role applies.
Role Inheritance
- An Organization-level role cascades down to all projects and environments.
- A Project-level role cascades down to all environments within that project.
Union of Permissions
If a collaborator has roles at different levels, permissions are merged.
If you invite Alice as a Viewer at the organization level and as an Editor at the project level, she will have Editor permissions in that project and all its environments.
Practical Scenarios
Scenario 1: Giving Read-Only Access to a Contractor
- Invite them as a Viewer at the project level.
- They can review all environments in that project without making changes.
Scenario 2: Allowing an External Partner to Edit Only One Project
- Invite them as an Editor to that project.
- They can make changes within the project but have no access to other projects.
Scenario 3: Setting Up Organization-Wide Administrators
- Invite trusted team members as Admins at the organization level.
- They can manage all projects, environments, and collaborator permissions.
- Limit Admins: Assign the Admin role only to trusted collaborators to reduce risks.
- Use Project-Level Access for External Collaborators: Grant contractors access only at the project level.
- Leverage Groups: Use groups to manage permissions for multiple users efficiently.