New setting available - Governance in SharePoint: Redirect users to an organization approved request page
A site request can carry everything an organization needs to make a good provisioning decision: ownership, access requirements, naming information, and an expected end date. SharePoint’s new redirect setting provides a direct entry point into that process.
The video at the end demonstrates how “Redirect users to an organization approved request page” connects the familiar Create site action to a custom request form. A SharePoint list stores the requests, while two Power Automate flows handle provisioning and deletion.
The result is a practical foundation for end-to-end site governance using built-in Microsoft 365 capabilities. Users get a clear request experience, and administrators get a central place to review requests, execute lifecycle actions, and track their outcomes.
A new entry point for site governance
In the demonstrated SharePoint admin center, Settings → Site creation offers three choices for the SharePoint site creation experience: use the built-in experience, redirect users to an approved request page, or turn off the built-in experience.
Selecting the redirect option and saving a destination URL sends users to that address when they choose Create site in the demonstrated SharePoint start-page experience. Microsoft documents this option as an entry point to an organization’s custom provisioning process. [1]
The setting supplies the routing. The list, form, and flows supply the governance logic: what information to collect, who can authorize provisioning, how the site is configured, and when its lifecycle ends.
The SharePoint list becomes the control center
The solution starts with a custom SharePoint list. Each item represents a site request and remains available as the operational record after provisioning or deletion.
| Information captured | Purpose in the process |
|---|---|
| Site title and description | Describe the requested workspace and its purpose. |
| Site name / URL component | Define the technical address using the organization’s naming rules. |
| Site owner | Identify the person responsible for the workspace. |
| Users with read or write access | Capture the initial permission requirements. |
| Department and site type | Provide context for review and provisioning. |
| End date | Provide a basis for future lifecycle review or expiry automation. |
| Status and created-site link | Show processing progress and provide access to the provisioned site. |
| Owner notification preference | Capture information that a notification extension can use. |
The demonstration deliberately leaves the technical site name out of the user-facing request form. An administrator supplies it before provisioning, allowing the organization to enforce a consistent URL pattern. The user can describe the business need without having to choose the final technical address.
The list also contains a management column with actions for the provisioning and deletion flows. Administrators can work directly from the relevant request instead of copying its details into a separate provisioning interface.
A custom form built with the native Lists experience
The request form is created through the list’s Forms command. This is the native Microsoft Lists forms experience; building this intake form does not require a separate Power Apps application or Microsoft Forms survey. [2]
The configuration sequence is straightforward:
- Create the request list and configure its columns.
- Create a form containing the fields users should complete.
- Copy the form’s sharing link.
- Paste it into the organization-approved request-page setting and save.
- Test the Create site action and submit a request.
Submitting the form creates a list item. In the demonstrated implementation, this records the request; an administrator subsequently reviews it and starts provisioning. Automated approval is a possible extension.
Flow 1: Provision the site and configure access
The provisioning flow turns the selected request into a configured SharePoint site. Its main stages are:
- Set the request status to In progress. The list immediately shows that processing has started.
- Submit the creation request. Send the relevant site information to the SharePoint REST API and evaluate the response.
- Wait for provisioning. Poll the provisioning state and stop if creation fails.
- Check that the new site can be accessed. Retry reading site information until the site is ready for the next operations.
- Apply permissions. Retrieve the required SharePoint group IDs, resolve or ensure the selected users in the site collection, and add them to the appropriate groups.
- Write the result back. Save the created-site URL and change the request status to Created.
The separate waiting and readiness checks matter because provisioning is asynchronous. A successful initial request does not establish that every subsequent permission operation can run immediately. The flow coordinates these stages before reporting completion.
The video also shows an error-handling scope configured to run after the preceding scope fails or times out. It marks the request as Failed and terminates the run, keeping the operational result visible in the list.
REST operations behind the workflow
For implementing this pattern, Microsoft documents the following operations under /_api/SPSiteManager. These are implementation references, rather than a literal export of the demonstrated flows. [3]
| Operation | Method and endpoint | Role |
|---|---|---|
| Create | POST /_api/SPSiteManager/create | Submit the site configuration. |
| Status | GET /_api/SPSiteManager/status?url='…' | Inspect the provisioning state. |
| Delete | POST /_api/SPSiteManager/delete | Request deletion using the site ID. |
The documented creation API supports communication sites using SITEPAGEPUBLISHING#0 and team sites without a Microsoft 365 group using STS#3. A request form that also offers group-connected team sites needs a corresponding group-aware provisioning branch. Adding a choice to the form alone does not implement that branch. [3]
Power Automate’s SharePoint connector includes Send an HTTP request to SharePoint and is classified as a standard connector. This provides a native route for the SharePoint REST calls, subject to the connection’s permissions. Connector classification alone does not determine the licensing requirements of every extended solution. [4]
Flow 2: Delete the site with explicit confirmation
The second flow handles the other end of the lifecycle. An administrator starts it from the request item and must enter the confirmation word delete before processing continues.
The flow reads the stored site information, retrieves the site ID, and submits it to the deletion endpoint. It then checks the outcome in a loop and updates the request status to Deleted.
In the demonstration, the site disappears from the admin center’s active-site list and appears under deleted sites. The request item remains available, preserving the connection between the original request and its final operational state.
The video explicitly presents this deletion flow as a starting example with incomplete exception handling. A production implementation should extend it with timeout and failure handling comparable to the provisioning flow.
Turn the request list into a lifecycle dashboard
The demonstrated status choices include In progress, Declined, Archived, Created, Deleted, and Failed. Standard list filtering and grouping make it possible to build useful views for administrators—for example, failed runs requiring attention, created sites, or completed deletions.
These records provide visibility into sites managed through this process. They do not automatically inventory every site in the tenant. Likewise, an Archived status value does not itself implement an archive operation.
Keeping the request and lifecycle state together reduces the need to reconstruct decisions from email threads. For stronger traceability, the solution can additionally record approval outcomes, timestamps, error details, and flow-run references.
Extend the two flows into a complete governance process
The video proposes several extensions that build on the demonstrated foundation:
- Manager approval: determine the requester’s manager, request a decision, and start provisioning after approval. Record declined requests in the same list.
- Lifecycle review: use a scheduled flow to find requests whose end dates have been reached. Add owner confirmation or an extension decision before invoking authorized deletion logic.
- Notifications: inform the requester or owner when a site is ready, when processing fails, or when retirement is approaching.
Approval, notification delivery, and scheduled expiry processing are proposed extensions, not features already completed by the two demonstrated flows. For automated reuse, factor the provisioning and deletion logic into an appropriately callable workflow structure rather than assuming an administrator-triggered flow is already a child flow.
Additional production refinements can validate names, prevent duplicate processing, protect administrator-maintained fields, and limit who can execute the management flows. Hiding an action or field in the interface is not a substitute for permissions. A business end date should initiate the organization’s lifecycle policy, including any required retention checks.
Why built-in Microsoft 365 capabilities are a strong foundation
Users retain a familiar starting point. They use the existing Create site action and arrive at the organization’s request form. Governance becomes part of the normal user journey.
Requests become structured and actionable. Ownership, department, access requirements, and lifecycle information are collected consistently. Administrators spend less time chasing missing details.
Provisioning becomes repeatable. The flow applies the configured steps each time, including readiness checks and permission assignment. This reduces repetitive administration and inconsistent setup.
Governance continues after creation. The same record supports operational visibility, review dates, and eventual retirement. Site lifecycle management starts with the original request.
The solution can evolve within the existing platform. Native forms provide intake, lists hold the operational data, and Power Automate coordinates the work. This implementation avoids requiring a separate custom-hosted provisioning application, while still requiring thoughtful workflow design and ongoing maintenance.
Align the process with Teams and Microsoft 365 groups
The redirect setting controls the SharePoint request experience. Microsoft 365 groups and Teams can create connected SharePoint sites through other routes, so their creation policies must be managed separately. Microsoft also distinguishes the SharePoint experience setting from its control over site creation through tools and APIs. [1]
Organizations should therefore align this request process with their wider collaboration governance. The video shows how to connect the user journey, administrative decisions, provisioning, and deletion into one manageable process—and how to extend that process as business requirements develop.
Watch the accompanying video to follow the redirect configuration, submit a request, and see both Power Automate flows create and retire a SharePoint site.
Kommentare