Create a pipeline to enable SharePoint and Teams governance

This is step three in your SProbot journey, after you’ve created a template.

It's easy to enable governance on Teams and SharePoint workspace creation without sacrificing self-service. Pipelines help you to automate and govern workspace build requests. For Teams and SharePoint sites which need to be created repeatedly, you can create templates, and then pipelines for builds based on these templates.

You can enable your users to request builds by publishing the URL of a pipeline's build request form on your Intranet, or an applicably accessible Teams channel, or even a Viva Connections dashboard. People can then open the form, request a workspace, and SProbot will use the pipeline to build it and notify the requester once complete.

Preparation

Before you can create a pipeline, you will need to create a template.

Step 1: Create a pipeline

Navigate to the Workspace setup screen, select the Pipelines tab and Create your first pipeline.

Choose a unique name for the pipeline and select whether you want to enable Teams or SharePoint team sites to be created using it.

• The name is also the title of the request form seen by your users.
• The type also determines the default managed path of either /teams or /sites.

‍

Step 2: Basic information

The basic information step enables you to define:

1. The template on which builds using the pipeline are based - Select from the templates you have created. If you create a Teams pipeline, only Teams templates can be used, and vice versa for a SharePoint team site pipeline.
2. The global category to assign in the workspace directory - Select from the categories you have created to enable logical classification. All workspaces built with the pipeline will have the selected category assigned in the workspace directory.
3. The text description shown at the top of the request form - This text explains to users what they can expect when requesting a workspace with the form. Use it to describe the channels, folders, libraries and other structural elements included in the template. It's also a good idea to explain the purpose of workspaces created using this pipeline, so it's perfectly clear when to use it and when not.
4. Whether users are required to provide an individual workspace description - If you check this box, the Description field on the pipeline's request form is mandatory. This ensures that people who request workspaces properly explain the intended purpose and contents, making it easier for everyone to find what they need.
5. Who should be notified when workspaces are created - Individuals you select here are included in notifications sent when workspace builds are successfully completed, in addition to those who are selected as owners on the request form.

Save and next saves these settings but does not yet publish the pipeline to make its request form available.

Step 3: Governance rules

The rules you define in this step of the pipeline configuration are enforced on all workspaces created using the pipeline and enable you to control how workspaces are named, how they're owned, and what security rules are applied.

Naming & Association

• Name prefix - This prefix is added to the title of Teams and SharePoint team sites created with the pipeline. Because the URL of the linked team site of a team is deduced from the title but with spaces removed, the prefix will also indirectly determine the URL. In the example below, the prefix includes a space after the hyphen. If someone requests a team with the name 2023 Incentives, it will be created as HR - 2023 Incentives and the linked team site URL will be /teams/hr-2023incentives. It's a good idea to keep this prefix short to prevent it from causing long team names from not being fully visible in the left panel of the Teams app.
• Hub site - Sites registered as hubs on the tenant can be selected, and team sites (or linked team sites in the case of teams) created using the pipeline will then inherit the navigation, theme and some permission settings from the hub. Read more about hubs.

Ownership

• Minimum number of owners - This setting is enforced on the owner(s) field on the request form. Having at least 2 owners helps prevent teams from becoming orphaned easily.
• Limit owners to a group - This enables you to prevent anyone outside the selected group from being set as owners at the point of creation. When completing the request form, the Owner(s) field label indicates that it's limited to the group only, and when using the field, only owners and members of the group are returned and selectable.

Access control

• Sharing settings - This setting defines how the owners and members of workspaces are able to share them. Read more about limiting sharing by default‍
• Prevent guess access - Enabling this prevents guests (external users) from being added to Teams and SharePoint sites created with the pipeline. Read more about preventing guest access.
• Prevent folder creation - This option is only available for Teams pipelines, it removes the New folder button within the default document library inside the SharePoint site for a team. Owners are able to revert this setting if they want to, and it also does not apply to any additional document libraries created in the site.

‍

Step 4 - Approval & availability

Approval

• Require approval - When you enable approval, all workspace build requests made using the request form need to be approved by the users you define before they are actioned. Read more about workspace approval.

Availability

• Limit pipeline access - If the request form should only be available to some people, you can select them here. You could for example limit the creation of HR project sites to HR staff only by selecting an appropriate group (Microsoft 365 groups and Azure AD security groups are supported, but mail-enabled AAD security groups are not currently supported).

If you’re not ready for your users to start requesting builds yet (or you want to make the request form unavailable at a later point) you can set the pipeline as inactive.

Step 5: Request form URL

As soon as you publish the pipeline, it becomes available and you'll be able to access its request form with its unique URL.

The form is only available to users in your tenant, and each user will need to authenticate when they access it. Read more about tenant user permissions in How permissions work in SProbot.

Tip: You can copy the request form URL from the template list on the tenant home.

Step 6: Test the request form

The request form display is dependent on whether the pipeline type is Team or Team site:

What's next?

Once your request form is published, you can make it available to your users. You could:

• Create a page on your Intranet (whether it's in SharePoint or not) explaining the company policy on workspaces within the specific department, and say "Use this form to request a new HR project workspace".
• Pin an explanation about workspace creation at the top of a departmental Teams channel.
• Create a link in a Viva Connections dashboard which is pinned in the Teams app.

When someone requests a workspace, their request is added to the build queue and is usually initiated and completed within a few minutes. When it completes, people specified as owners and those selected as notification recipients receive a confirmation email. Pipeline builds display in the build dashboard on the tenant home page.

Editing a pipeline

You can view and edit an existing pipeline at any point. You cannot change the associated template, hub site or name prefix once a pipeline has been published, but you can change:

• The pipeline's name (which is the title of the request form)
• The description shown on the request form
• Who is notified in addition to owners when builds complete
• The minimum number of owners
• Sharing and guest access settings
• Who the pipeline is accessible to
• Whether the pipeline is active or not

When you’re happy with your changes, save them. You do not need to complete all steps, a save on the screen the setting appears on is effective immediately.