dRofus Help & Learning

Permissions

Permissions in dRofus control what users can access and edit within projects and databases. Understanding how permissions work helps project administrators configure the right access levels for their team members.

Database vs. Project Permissions

dRofus permissions operate at two distinct levels: database and project.

Database-level permissions apply to elements shared across all projects in the same database:

When multiple projects share a database (a multi-project scenario), database permissions apply to all projects. For example, if a user has template editing rights, they have those rights in every project within that database.

Project-level permissions apply only to specific projects:

In multi-project scenarios, users can have different project permissions in each project while maintaining the same database permissions across all projects.

Permission Levels Explained

Templates

Templates have three permission levels :

  • Full: Create, delete, and edit templates

  • Limited: Edit room data on templates only (cannot create or delete)

  • Read: View templates only

Important: Once a template is applied to a room, users need full room rights to edit that template, even if they have full template permissions.

Template Occurrences

Template occurrences have three permission states :

  • Full: Create, delete, and edit template occurrences

  • Read: View template occurrences only

  • None: Cannot see template occurrences at all

Items

Items have three permission levels :

  • Full: Create, delete, and edit items

  • Read: View items only

  • None: Cannot see items at all

Users cannot delete an item if it has occurrences in the project. Additionally, the Items permission level affects which Occurrences permissions are available.

Occurrences

Occurrences permissions depend on Items permissions :

  • If Items = None, then Occurrences must be None

  • If Items = Read, then Occurrences can be None, Read, or Full

  • If Items = Full, then Occurrences can be None, Read, or Full

This means users can have read-only access to items while still having full rights to create and edit occurrences.

Rooms

Rooms have three permission levels :

  • Full: Create, delete, edit room properties (name, number, etc.), and apply templates

  • Limited: Edit room data only (can apply templates to rooms)

  • Read: View rooms only (cannot apply templates or edit data)

Users with read-only template permissions can apply those templates to rooms if they have limited room rights.


Administrator

Turning on Administrator allows the user to do all that is necessary in the Project Administration Setting. See Administration Settings

User Administrator

Turning on User Administrator allows the user to make edits in the Administration System per project, including adding/removing users and editing user permissions. See User Management

BIM Administrator

Turning on BIM Administrator allows the user to make edits in the Revit, Archicad, and IFC settings. See dRofus Integrations


Using User Groups for Permission Management

The recommended approach to managing permissions is to create user groups first, then assign those groups to individual users.

How User Groups Work

User groups define specific permission sets that can be combined on a user profile. Each user group can grant permissions to one or more areas while leaving others read-only. See User Groups

Example user groups:

  • "Room Editors" – Read-only for everything except full room rights

  • "Item Managers" – Read-only for everything except full item rights

  • "Template Coordinators" – Read-only for everything except full template rights

Combining User Groups

When multiple user groups are assigned to a user, their permissions combine to create custom permissions. For example, a user assigned to both the "Room Editors" and "Item Managers" groups would have full room rights AND full item rights, with everything else read-only.

User groups created in one project are shared across all projects in the same database, making permission management consistent and efficient.

Permission Overrides

Overrides provide granular control over what users can edit in areas where they have limited or full permissions.

Room Data Overrides

When users have limited room permissions, you can further restrict which tabs in the room data they can edit. Setting a room data override automatically sets the user to limited room permissions.

Item Data Overrides

Users with full item permissions can be restricted to editing only specific tabs within item data. This allows precise control over which information they can modify while maintaining general access to items.

Responsibility Group Overrides

Responsibility groups create granular permissions at the item and occurrence levels, overriding the default permissions.

Users can have:

  • Default permissions set to None for items and occurrences

  • Specific responsibility groups with Read rights on items

  • Other responsibility groups with Full rights on items

  • Different occurrence permissions (None, Read, or Full) per responsibility group

Important constraint: Users with None permissions on items cannot have Full rights on occurrences, even when using responsibility group overrides.

Best Practices for Setting Permissions

  1. Start with user groups: Define your user groups before adding users to the project

  2. Use descriptive names: Name user groups based on their function (e.g., "Architects - Room Access")

  3. Combine thoughtfully: Apply the right combination of user groups to each user profile

  4. Leverage database sharing: Remember that user groups are shared across projects in the same database

  5. Review custom permissions: Check the combined result when multiple user groups are assigned to verify the intended access level


Frequently Asked Questions

Q: What happens if a user has template permissions but no room permissions?
A: They can view and edit templates, but once a template is applied to a room, they cannot modify it without at least limited room rights.

Q: Can a user have different permissions in different projects within the same database?
A: Yes, for project-level permissions (rooms, occurrences, systems, procurement, delivery, model server). Database-level permissions (templates, template occurrences, items, administrator status) remain the same across all projects in the database.

Q: What does "custom permissions" mean on a user profile?
A: Custom permissions appear when multiple user groups are assigned to a user. The system combines permissions from all assigned user groups to determine the user's overall access rights.

Q: Can I give someone full occurrence rights if they only have read access to items?
A: Yes. Users with read-only item permissions can have none, read, or full permissions on occurrences.

Q: Can I give someone full occurrence rights if they have no access to items?
A: No. If items are set to None, occurrences must also be set to None.

Q: How do responsibility group overrides work with default permissions?
A: Responsibility groups can override default item and occurrence permissions for specific responsibility groups. For example, a user with None as the default can have Read or Full rights on specific responsibility groups. However, the rule that users with None on items cannot have Full on occurrences still applies.

Q: Why can't I delete an item?
A: Items cannot be deleted if they have occurrences in any project. You must first remove all occurrences before deleting the item.

Q: If I create a user group in one project, can I use it in another project?
A: Yes, if both projects share the same database. User groups are database-level entities and are available across all projects in that database.

Q: I am trying to set up a new project. Where are those settings?
A: In order to set up a project, you must be defined as an Organization Administrator. See Organization Administrator. Only a Server Administrator can elevate your permissions to Organization Admin. See Server Administrator