Managing access to iTwins

In any organization, different teams handle different project aspects, requiring unique levels of data access. For example, engineers need detailed design control, while project managers oversee high-level aspects. Access control lets you define groups like “Engineers” and “Project Management.” These groups can be assigned to multiple iTwins within the same organization.

When a new member is added to the "Engineers" group, they automatically gain access to all relevant iTwins. Similarly, removing someone from a group instantly updates their access across the board. In this way, the iTwin Platform reduces administrative effort and ensures consistent access at the organizational level.

In a complex, multidisciplinary organization, such structure is not just helpful—it’s essential.

While groups determine who gets access, roles define what level of access each group has. For example, the "Engineering Team" group might have roles such as "Contributor," with full editing capabilities, or "Reviewer," with read-only access. On the other hand, the "Project Management" group might have roles like "Project Admin," giving them full administrative control of the project. By creating and managing roles at the organizational level, you establish consistent and clear rules that help improve workflow clarity.

Just as with groups, roles can be managed at the organizational level to ensure consistency across iTwins. For example, if your organization recently began incorporating reality data, users with the “Contributor” role might need new permissions to add this data to iTwins. Instead of modifying access for each individual iTwin, you can update the “Contributor” role at the organizational level. This change then applies automatically across all iTwins with this role.

This centralized approach reduces the risk of unauthorized access, enhances workflow efficiency, and ensures consistent permissioning.

While consistency is key, there are scenarios where exceptions are necessary. For instance, government projects might need custom groups or roles that are restricted to specific iTwins, granting access only to those with the necessary clearance. Another example is highly confidential or private projects that involve individual users, rather than broad groups. In such cases, each user’s permissions might be assigned individually to maintain stronger regulation over iTwin access.

By creating custom groups or roles at the iTwin level, you can cater to these unique cases while keeping the organization’s overall data secure. This allows outside collaborators to work seamlessly without affecting broader organizational access patterns.