Manage Permissions in Microsoft Teams and SharePoint — Without Permission Chaos

How Does Access Profiles Solve This Problem?

The configuration is done once in the workspace template. After that, every new workspace automatically inherits the defined roles and permissions.

Step 1: Define Project Roles

The administrator defines the roles needed for day-to-day project work. Unlike Microsoft Teams, which implicitly groups guests under Members, Valprovia Governance explicitly distinguishes three user types:

Owners — e.g., "Project Manager" with full access and "Deputy" as backup. Members — e.g., "Team Member" with editing rights and "Controlling Reader" with read-only access. Guests — e.g., "External Partner" with restricted access to shared areas. Through the explicit separation of Guests, external users receive their own roles with their own permissions — instead of blanket Member rights.

Here the administrator creates the project roles. For Owners, "Project Manager" and "Partner" have been defined; for Members, "Controlling Reader". Each role can be marked as default and reordered.

The administrator clicks "New Owner Role" and enters the role name in the dialog — e.g., "Project Manager". Optionally, they add a description that will appear as a tooltip for end users.

Step 2: Configure Behavior

Two optional settings control how end users work with roles: Enforce role selection ensures every project member gets a role — essential for regulated environments and audit requirements. Allow multiple selection enables assigning multiple roles to a person — e.g., when someone is both a team member and a controlling officer.

Step 3: Link Roles to SharePoint Permissions

Each role is assigned to a SharePoint group. These groups define which permissions apply to which project folders and document libraries. If a group doesn't exist yet when the workspace is created, it's automatically created.

In the "Role-Based Permission Assignments" section, the administrator links each role to a SharePoint group. Here, "Project Manager" is connected to the SharePoint group of the same name, "Controlling Reader" to "Project Controlling Reader". No roles have been defined for Guests yet.

This is how the assignment looks in edit mode: The administrator selects the role from the dropdown on the left and types the SharePoint group name on the right. A click on the checkmark saves the link.

The complete configuration at a glance: At the top, the workspace template ("ConsultancyProject.xml") is configured. Below, the Role-Based Permission Assignments — "Project Manager" and "Partner" for Owners, "Controlling Reader" for Members, each with its assigned SharePoint group. No roles have been defined for Guests yet.

What Do Project Managers and End Users Experience?

For the project manager, the daily workflow changes noticeably: Instead of filing an IT ticket and waiting for permissions to be set up, they open the workspace, add a new team member, and select the appropriate role from the dropdown. Done. The SharePoint permissions are set automatically in the background.

The project manager adds a new team member and opens the role dropdown. The roles predefined by the administrator are available for selection — in this case "Project Manager" and "Partner".

The role "Project Manager" has been selected and appears as a tag next to the username. The project manager can still change the assignment or confirm it with a click.

Both workspace owners now have their roles: One user is "Project Manager", the other is "Partner". A click on "Send request" triggers the automatic permission assignment.

After submitting, the confirmation appears: The permission changes are carried out automatically in the background. The project manager doesn't need to do anything else.

Roles Are Not Labels — They Control Real Permissions

Role labels are not a new concept. Many governance solutions allow assigning tags or roles to users. The key difference: these labels typically remain purely visual — they label a user but have no effect on actual permissions in SharePoint. Valprovia Governance goes a step further and links each role directly to a SharePoint permission group. A label becomes a real permission — automatically, consistently, and synchronized with every change.

A concrete example demonstrates this difference. One user has the role "Project Manager", another has "Partner":

Starting point: One user has the role "Partner", another is "Project Manager". Both roles are linked to different SharePoint permission groups.

As Project Manager, the user has access to all three project folders — 01_Project Calculation, 02_Controlling, and 03_Development:

SharePoint, the Project Manager sees all three project folders. The SharePoint permission group "Project Manager" has access to the entire project structure.

When the role is changed to "Partner", Valprovia Governance automatically adjusts the SharePoint permissions:

The project manager changes the role via the dropdown. Valprovia Governance removes the user from the old SharePoint permission group and adds them to the new one.

The result: As Partner, the user can only see one folder — 03_Development. The folders 01_Project Calculation and 02_Controlling are no longer visible because the SharePoint permission group "Partner" doesn't have access to them:

After the role change, the user only sees the folder 03_Development. The permissions were automatically adjusted through the underlying SharePoint permission groups — without manual intervention.

What Valprovia Governance Focuses On

Valprovia Governance is a preventive governance solution: preventing problems before they occur. Security and permission management are at its core — not only at the workspace level but especially within workspaces: Who can do what, and why?

Access Profiles is the expression of this approach. Project managers retain control over project permissions without having to file IT tickets. IT administrators benefit from consistent permission structures across all workspaces and automatic synchronization when roles change. Compliance officers receive enforced role assignments for audit purposes and automatic protection against uncontrolled permission changes. And for end users, it remains a simple dropdown — they select "Project Manager" or "Reader", and the correct permissions are set automatically.

Frequently Asked Questions About Access Profiles

How do Access Profiles differ from native Microsoft Teams roles?

Microsoft Teams only knows two fixed roles: Owner and Member. Guests are implicitly treated as Members. Valprovia Governance extends this model to three explicit user types — Owners, Members, and Guests — and enables any number of roles per type with their own SharePoint permissions. For example, a "Project Manager" with full access can be distinguished from a "Controlling Reader" with read-only access, and external guests receive targeted roles instead of blanket Member rights.

How do organizations with many parallel projects benefit?

Roles are defined once in the workspace template. Every new project created with this template automatically inherits the same permission structure. For a hundred parallel projects, this saves a hundred manual SharePoint configurations — and ensures every project has consistent permissions.

Can external partners and consultants get their own roles?

Yes, roles can be defined separately for all three user types — including guests. An external consulting partner can have a different role and thus different permissions than an external auditor. Each role only has access to the project areas designated for it.

Is Access Profiles suitable for regulated industries with audit requirements?

Yes. The "Enforce role selection" setting ensures every project member has a documented role. No user can exist without a role assignment in a workspace. This creates a traceable permission structure that serves as evidence during audits.