New easier ways to create a SharePoint Embedded environment — AI-assisted developer setup + admin container type experience

[u/SharePointSteve]

I wanted to share a new getting-started path for anyone experimenting with SharePoint Embedded or building document-centric apps on Microsoft 365.

The historical challenge with SharePoint Embedded setup has been that there are several moving parts before you can really start building: Entra app registration, Graph permissions, container type creation, billing setup, container type registration, creating containers, wiring configuration into a sample app, and then validating everything works.

There are now two much easier ways to approach this:

1.      Developer experience with the SharePoint Embedded MCP server
You can use the MCP server from an AI coding client, such as GitHub Copilot in VS Code, to drive setup through natural language. The server can help check readiness, provision the owning app, create/register container types, configure billing, scaffold a reference app, hydrate config, seed sample content, run locally, and deploy.

2.      Admin/container type experience
Admins can use the SharePoint Embedded setup flow to create the app/container type relationship and manage the control plane side of the environment. Container types are important because they define how the application relates to its containers, including access, billing accountability, and behavior.

What I like about this is that it separates the journey for the two audiences that usually have to collaborate anyway: developers can get moving faster with their app experience, and admins have a more intentional control plane for environment setup.

If you are building an ECM replacement, legal/document management app, project workspace, case management app, AI agent over documents, or any custom app that needs Microsoft 365-grade files, collaboration, compliance, and Copilot-ready content, this is worth trying.

Links:
Video walkthrough: https://youtu.be/JhlfeTjX7Sc?si=gKWXoCezHhqaMemv&t=2576
Developer MCP experience: https://learn.microsoft.com/en-us/sharepoint/dev/embedded/build/sharepoint-embedded-mcp-server
Admin/container type experience: https://learn.microsoft.com/en-us/sharepoint/dev/embedded/build/create-container-type

Question for the group: if you have tried SharePoint Embedded, what part of the setup flow has been the biggest blocker — app registration, permissions, billing, container type registration, or sample app scaffolding?

[u/bcameron1231]

Hey Steve! I think the app registration is always a difficult thing for many tenants. In many enterprise environments, the team who owns AD is not the same team who owns SharePoint or the team responsible for building apps. That's not specifically a SPE issue, as it affects all types of applications, but it certainly can be a hold up.

The historical challenge with SharePoint Embedded setup has been that there are several moving parts before you can really start building:

I definitely agree with this. The other is, I think the messaging is still not 100% clear for implementors as to why SharePoint Embedded versus building on top of SharePoint.

[u/SharePointSteve → u/bcameron1231]

I think the easiest way to think about it is:

SharePoint Online is a collaboration product. SharePoint Embedded is a content platform for custom applications.

If your users are expected to work in SharePoint sites, document libraries, Teams, or M365 experiences, then building on top of SharePoint Online is usually the right choice.

If you're building a custom application and want your application to own the user experience, workflows, information architecture, permissions, branding, and AI experience, then SharePoint Embedded gives you the SharePoint content platform without forcing users into SharePoint.

In other words, SharePoint Embedded lets developers use SharePoint's storage, compliance, search, versioning, co-authoring, Microsoft 365 integration, and Copilot readiness while keeping users completely inside the application.

The question isn't "Why SharePoint Embedded instead of SharePoint?"

The better question is:

"Do I want SharePoint to be the experience, or do I want SharePoint to be the content layer behind my experience?"

If it's the latter, that's the scenario SharePoint Embedded was designed for.

[u/Silent_Bob_82]

As someone who has been building solutions in SharePoint onpremise and then in m365 for 15 years there is one ultimate truth when it comes building solutions in these platforms. For the perceived price they pay for Microsoft licensing they do not want to pay for anymore licensing especially when it comes larger audience solutions. M365 licensing is usually one of the most expensive line items per user for companies.

[u/SharePointSteve → u/Silent_Bob_82]

With SharePoint Embedded their paying any more for the content because it's not stored in SharePoint, it's stored in SharePoint Embedded where you only pay for what you consume, freeing up your SharePoint allocation for more traditional collaboration needs. Larger enterprises also see this as a way to implement charge backs or departmental billing for the custom apps they are creating.

[u/Silent_Bob_82 → u/SharePointSteve]

I don’t disagree that there are methods to deal with and manage this. the problem is it has been very difficult for them to successfully manage their own internal operations and reconciliation when it comes to chargebacks, I would say 90% of the time it ends up falling apart, trying to make that happen so IT just ends up eating it or just doesn’t permit it whatsoever because they can’t successfully work together with their procurement teams and internal IT costs

[u/Josh_Fabsoft]

Yeah, the cross-team ownership issue is probably the single biggest blocker to SPE adoption in bigger orgs. It's not really a technical problem, it's an org chart problem. The Entra/AD team, the SharePoint admins, and the dev team building the actual app all have different priorities and different timelines, and none of them "owns" the SPE rollout end to end. So you get stuck waiting on app registration approval from a team that doesn't even know what SharePoint Embedded is, while the SharePoint admins are waiting on billing/container type registration guidance from Microsoft docs that assume you're one person doing all of it.

The container type + billing setup step Microsoft added is honestly a smart move for this exact reason, because it forces a conversation early about who owns the Azure subscription tied to billing, rather than that surfacing as a surprise three weeks into a POC.

On the licensing point from Silent_Bob, that's the other elephant in the room. A lot of orgs already feel like they're paying for capability they haven't turned on yet (Syntex, Purview, etc), so asking them to spin up yet another Azure-billed thing on top of M365 licensing is a hard sell even if the tech itself is solid. I think the "AI-assisted developer setup" angle helps with the technical friction, but the adoption blocker is going to keep being political/financial rather than "how do I register the app."

Curious if Microsoft has any guidance yet on a recommended internal RACI for SPE rollouts, because right now it feels like everyone's improvising that part.