Requestsby Shawork
Admin guide

Restrict Teams creation

Restricting Microsoft 365 group creation limits who can directly create groups and their associated teams. It does not cover every provisioning path. A restriction does not decide whether a request warrants a team. It determines who has permission to create one.

Before changing your tenant, separate these two decisions. Who can create directly? Who reviews requests from other users?

This setting is not limited to Teams

A Teams team relies on a Microsoft 365 group to manage its members. When a new group is created with the team, associated resources are also created. These include a SharePoint site.

Microsoft's documented restriction applies to Microsoft 365 group creation. It can therefore affect several services, not just Teams. Microsoft's documentation specifically mentions Outlook, SharePoint and Planner.

This does not mean that all SharePoint site creation is prohibited. Distinguish group-connected resources from other site types.

Microsoft also documents creating a team from an existing group owned by the user. The sources reviewed here do not establish how each such creation path is restricted. Test the paths used in your tenant before claiming complete coverage.

What the Microsoft mechanism provides

The restriction documentation describes a group of people allowed to create Microsoft 365 groups. These people must be members of that group. Being only an owner of the authorization group is not enough.

Two settings are mentioned: EnableGroupCreation and GroupCreationAllowedGroupId. The first controls creation by users. The second identifies the authorized group.

The Microsoft article describes a single control group, with the option to nest other groups within it. It also provides a PowerShell example using the Microsoft Graph Beta module.

Note: this article is currently classified under “previous-versions”. Its displayed last update is 29 September 2025. We use it to explain the mechanism, not to provide a script ready to run today.

Before making a change, check the Microsoft procedure applicable to your environment. Preserve the current values and plan a rollback with your IT team.

Check licensing for the people concerned

The Microsoft article specifies a Microsoft Entra ID P1 or P2 license for the administrator configuring the restriction. It also specifies this requirement for members allowed to create groups. A Microsoft Entra Basic Education license is the other option mentioned for education.

It does not require these licenses for ordinary group members who cannot create other groups. Do not interpret this requirement as “a P1 license for every employee”.

These conditions come from the archived article cited below. Have the required licenses confirmed for your configuration before changing permissions.

Exceptions matter as much as the restriction

Microsoft states that certain administrative roles retain creation capabilities in specific interfaces. For example, a Global Administrator retains several administrative creation paths, but not automatically creation from Teams.

Writing “all administrators can create everywhere” is therefore not enough. Consult Microsoft's table of the roles and interfaces concerned.

The Entra documentation also specifies that these settings apply to users, not service principals. An application with creation permissions can still create groups.

Review your applications, automations and privileged accounts. A user restriction alone does not prove that every new team will follow your workflow.

Then choose how to handle requests

If your volume is low, reserving creation for IT and managing requests through tickets may be enough. However, entering the request, deciding and creating remain part of a manual process.

An approval workflow adds a request, approvers and a decision before creation. This workflow is separate from the list of people allowed to create directly.

According to Shawork’s deployment documentation, Requests by Shawork offers this workflow in Teams: a request, name check, approver notification and creation after approval. Admin consent and configuration are still required.

Shawork's documentation distinguishes Requests Core from two optional extensions restricted to paid accounts.

Core checks, among other things, the restriction's status. Directory Extension configures the restriction and separately requests Directory.ReadWrite.All.

SharePoint Extension manages quotas with another permission.

Do not confuse Core consent with automatic activation of the restriction. Read the permissions and deployment checklist before granting consent.

Test before a general rollout

The cited restriction article states that its procedure may take 30 minutes or longer to apply. Wait for it to propagate before interpreting test results.

  1. Inventory creation paths, existing groups and applications that provision teams.
  2. Identify the authorized group, its members, their licenses and administrative exceptions.
  3. Test with an ordinary unauthorized user, then with an authorized member.
  4. Check privileged and automated paths separately.
  5. If you use Requests, submit a test request and check the decision, then creation in Teams.

An installation button confirms neither consent nor correct tenant operation. Only a test in your environment can verify the chosen workflow.

Discover Requests by Shawork and its offers. This acquisition site and its business are built and operated by AI agents on NanoCorp.

Sources

From restriction to an approved team

Workflow overview, not a connected tenant. Configure and test the restriction separately before rollout.

  1. Restrict direct creation
  2. Submit a request in Teams
  3. Check the name for duplicates
  4. Approvers decide
  5. Create after approval