A controlled SharePoint site provisioning workflow helps IT teams create the right workspace, assign accountable owners, and avoid abandoned or misclassified sites. This checklist covers the request form, approval decisions, naming fields, ownership handoff, review dates, and the governance checks to repeat whenever Microsoft 365 tools or organizational requirements change.
Overview
SharePoint site provisioning is not simply a technical task. It is a governance decision about where information will live, who may access it, how long it should remain active, and what will happen when the original business need ends. A request process gives administrators enough context to make those decisions before a site is created.
The workflow should be easy for employees to use but structured enough to capture business ownership, sensitivity, collaboration needs, and lifecycle expectations. It should also distinguish between a SharePoint team site, a communication site, a site connected to Microsoft Teams, and a personal or working location such as OneDrive. The correct choice depends on the audience and working pattern, not on a preference for one Microsoft 365 service.
Before designing the form, document the organization’s current Microsoft 365 configuration. Available provisioning controls, templates, naming options, group settings, retention requirements, and approval capabilities can change over time. Treat platform settings as implementation details to verify in the tenant rather than assumptions to copy from an older procedure.
For broader planning, pair this workflow with a documented information architecture. The guide on planning a SharePoint information architecture that scales can help teams decide how sites, hubs, navigation, metadata, and search should fit together.
Checklist by scenario
1. Start with a site request form
Make the request form the single entry point for new sites, whether requests arrive through a service portal, a Microsoft Form, a Power Apps experience, or another approved process. At minimum, capture:
- Requester: name, department, contact details, and relationship to the requested workspace.
- Business purpose: the work the site will support and the outcome the requestor expects.
- Audience: department, project team, organization-wide users, guests, or another defined group.
- Site type: communication site, collaboration site, Teams-connected workspace, or a request that should be redirected to another service.
- Information classification: the organization’s approved sensitivity or data classification choice.
- External access: whether guests or external partners are required, and why.
- Expected duration: ongoing, project-based, seasonal, or another defined period.
- Initial owners: at least two accountable business owners where organizational policy requires continuity.
- Requested name and URL: a meaningful display name, proposed URL segment, department or project code, and any required naming convention.
- Related workspace: existing site, team, hub, library, or application that may already serve the need.
2. Use a decision table before approval
| Request pattern | Likely workspace | Approval focus |
|---|---|---|
| Publishing information to a broad audience | Communication site or approved intranet location | Audience, publishing responsibilities, navigation, and content ownership |
| Team collaboration on files, tasks, and conversations | Team-connected collaboration workspace | Membership, guest access, private channels or restricted content, and owner coverage |
| Short-term project with a defined end date | Project collaboration site or team | End date, archive or deletion decision, records needs, and handoff plan |
| Personal working files for one employee | OneDrive rather than a shared site | Whether the content truly requires shared ownership and team access |
| Controlled records or regulated information | Approved SharePoint location with required controls | Permissions, retention, labeling, audit, and records-management requirements |
This table is a starting point, not a substitute for tenant-specific policy. If the request involves sensitive information, regulated records, broad external sharing, or a complex permission model, route it for an additional security, compliance, or records-management review.
3. Complete the approval and provisioning handoff
- Check whether an existing site or team can meet the stated need.
- Confirm the proposed site type, audience, classification, and external-sharing requirement.
- Validate the requested name against naming standards and searchability requirements.
- Confirm that the proposed owners understand their responsibilities.
- Assign an initial review date based on the expected duration and risk.
- Apply the approved template, permissions model, navigation, libraries, lists, and required metadata.
- Record the request, decision, approver, provisioning date, owners, and review date in the governance register.
- Send the owner a handoff message that explains how to manage membership, report issues, review content, and request changes.
Provisioning should not end when the site URL is delivered. A short owner handoff is where governance becomes an operating practice. Link the handoff to relevant guidance, such as SharePoint document-management practices and the organization’s permissions and sharing standards.
What to double-check
Ownership and accountability
Verify that owners are active employees or approved representatives of the business, have access to the site, and know that they are responsible for membership, content quality, access reviews, and lifecycle decisions. A technical administrator can support the platform, but should not be the only person accountable for business content.
Permissions and external sharing
Use groups and role-based access wherever possible instead of accumulating individual permissions. Check whether inheritance has been broken, whether unique permissions are necessary, and whether guests have access to more content than intended. External sharing deserves a separate review because a site’s audience, documents, links, and connected services may create different exposure paths. See the external sharing review steps for a focused checklist.
Information architecture and findability
Confirm the site’s relationship to hubs, navigation, metadata, search, and existing content. A new site should not create another isolated destination for information that belongs in an established business area. Review the SharePoint search and findability guidance when deciding which columns, content types, pages, and navigation links are needed.
Lifecycle and compliance
Every request should have a stated lifecycle: ongoing review, project end, seasonal closure, or another approved schedule. Do not treat a review date as an automatic deletion date. At review time, owners should decide whether to continue, restrict, archive, migrate, or close the workspace in line with retention and records requirements. If content is part of a migration, use a separate discovery and cutover process rather than treating a new site as a simple destination; the SharePoint migration runbook provides a useful companion checklist.
Common mistakes
- Creating a site before checking for duplication: Search the existing intranet, hubs, teams, and document libraries first.
- Accepting vague purposes: “Store department files” is not enough to establish audience, permissions, structure, or retention needs.
- Assigning one owner: A single owner creates a predictable continuity risk when responsibilities change.
- Using a generic name: Names should identify the business area or project and remain understandable after the original requester moves on.
- Ignoring connected services: A site may be associated with groups, Teams, Power Platform solutions, automation, or other dependencies that also require ownership.
- Making every site an exception: Templates and standard fields reduce inconsistent decisions and make later reviews possible.
- Deleting inactive content too quickly: Inactivity is a signal for review, not proof that content has no retention, legal, or historical value.
- Failing to record the decision: If the register does not show why a site exists, who owns it, and when it was reviewed, administrators will have to reconstruct its history later.
When to revisit
Review this provisioning workflow at least annually and whenever Microsoft 365 provisioning options, templates, naming capabilities, sharing controls, retention requirements, or connected services change. Platform updates should be checked through the organization’s normal Microsoft 365 administration and change-management process before the form or automation is modified.
Service teams should also revisit the workflow before seasonal planning cycles, major reorganizations, intranet launches, migration programs, or changes to security and compliance policy. Site owners should use the same checklist when an owner leaves, a project changes scope, guest access is introduced, or a workspace becomes a long-term business record.
For a practical next step, export the current site inventory and compare each entry with five fields: purpose, site type, owners, access classification, and next review date. Resolve missing ownership first, then review sites with unclear audiences or overdue dates. After that, update the request form and approval rules so the inventory problems are less likely to recur. This turns SharePoint site provisioning from a one-time creation task into a repeatable Microsoft 365 governance process.
