Shipping Co-Authoring in Your SaaS: What SharePoint Embedded Gives You Out of the Box
There is a feature request that never leaves the backlog of a document-heavy SaaS product: “Can two of our users edit the same document at the same time?” It arrives from sales after a lost deal, from customer success after a churn review, from the roadmap workshop where somebody demonstrates a competitor. And it usually dies in the same place — the estimate. Built from scratch, real-time collaborative editing of Word and Excel files is not a feature, it is a company; the editor-fidelity problem alone has consumed engineering organisations far larger than most ISVs.
The estimate changes completely when the question is reframed. If you add co-authoring to your SaaS product by embedding Microsoft’s own editors and storage rather than recreating them, the platform supplies the parts that were unbuildable and your team builds only the parts that are genuinely yours. This article is a scoping piece for exactly that exercise: a clear ledger of what SharePoint Embedded for SaaS hands you on day one, what your engineers still have to design and build, how long the work realistically takes, and the three pitfalls we most often see teams discover after launch. It is written for the product manager or engineering lead at a software vendor who has to stand in front of a roadmap meeting and defend a scope, which is why our SaaS and software vendors clients tend to ask for it in precisely this form.
If you need the primer first, we have written about what SharePoint Embedded is — in one line, a container-based document store owned by your application inside Microsoft 365, with the Office web editors attached. And if you are still weighing it against the older WOPI integration route, our decision framework for ISVs and enterprise architects covers that choice; this article assumes SharePoint Embedded is the road you are scoping.
The Platform’s Side of the Ledger
Everything in this section arrives with the platform. Your team writes none of it, and — just as important for your scope document — your team cannot meaningfully customise most of it either. It is worth being concrete, because each line below is something teams have historically attempted to build and regretted.
- Full-fidelity Office web editors. Word, Excel and PowerPoint documents open in Microsoft’s own web editors, inside your application’s frame. Fidelity is the point: tracked changes, formulas, pivot tables, formatting behaviour — the things every “good enough” third-party editor eventually breaks on real customer documents.
- Real-time co-authoring and presence. Multiple users edit the same document simultaneously, see each other’s cursors and positions, and watch changes merge live. This is the same co-authoring machinery Microsoft 365 users already know, which means the behaviour is proven and your users need no training. A genuine Word co-authoring integration — the request that started this whole exercise — is therefore a configuration outcome, not an engineering programme.
- Autosave and version history. Documents save continuously, and versions accumulate automatically with user attribution. You do not build a versioning subsystem, a “restore previous version” feature, or an autosave debouncer.
- Previews and thumbnails. Documents can be rendered for preview without opening an editing session, and thumbnails are available for gallery-style views in your UI.
- Content search. Text inside stored documents is indexed and searchable through the platform, scoped to your application’s containers — full-text search over document content without standing up your own indexing pipeline.
- Enterprise storage plumbing. Encryption, durability, and the operational baseline of Microsoft 365 storage come with the container model, along with the governance surface enterprise customers increasingly demand. (That surface deserves its own discussion and this is not that article.)
Read the list again from a build-versus-embed angle and notice its shape: these are precisely the components with the worst build-it-yourself economics. The editor is effectively unbuildable at fidelity; co-authoring is a distributed-systems problem wearing a text box as a disguise; search and versioning are undifferentiated heavy lifting. The platform’s side of the ledger is the side you were never going to win. It also keeps improving without your involvement: as Microsoft ships changes to the web editors, your product inherits them, which is a maintenance posture no in-house editing component can offer.
Your Side of the Ledger
None of what follows is optional, and none of it comes in the box. This is the real scope of the feature, where estimates should concentrate — and, not coincidentally, where a SharePoint Embedded development engagement spends nearly all of its time. The platform half of the ledger needs configuring; this half needs designing.
Container lifecycle, tied to your domain objects
SharePoint Embedded stores documents in containers, and the platform has no opinion about what a container means. Your product does: a container per project, per client workspace, per deal room — whatever maps to the object your customers think in. Your team designs that mapping and then owns the lifecycle around it: containers created when the domain object is created, archived or deleted when it closes, and — the case everyone forgets — cleaned up when a customer leaves. We come back to offboarding under pitfalls, because it earns the repetition.
Permission mapping
Your application already has a permission model — roles, workspaces, sharing rules your customers have configured for years. Containers have their own permission model. The bridge between the two is yours to design: when your app says “viewer”, what does the container say? Who reconciles the two when an admin changes a role mid-session? This is the single most consequential design task in the whole feature, because every mistake here is an access-control mistake. It deserves a design review on its own.
The editor launch experience
The platform provides the editor; your product decides how users reach it. Where do documents surface in your UI? What does clicking one do — preview or edit? Which of your application’s states map to read-only, and how is that communicated? Do you offer “open in the desktop app” for the power users who will demand it, and how does your UX handle the handover? None of these decisions is difficult in isolation; collectively they are the difference between a document feature that feels native to your product and one that feels bolted on.
Notifications and activity
When a colleague edits the proposal, who finds out, and where? The platform knows what happened; broadcasting it in your product’s voice — activity feeds, email digests, in-app notifications wired to your existing notification centre — is application work. Change notifications from the platform give you the raw events; the product experience built on them is yours.
Customer onboarding and consent
Because the capability lives inside Microsoft 365, bringing a customer aboard involves their Microsoft 365 administrator granting your application access — a one-time consent step on their side. For self-serve SMB customers this needs a well-designed guided flow; for enterprise customers it needs documentation their IT team will accept and a support script for the questions that follow (“what exactly does your application get access to, and why?”). None of this is difficult, but it is a genuine workstream: an onboarding state that can stall on someone outside your company, error handling for half-completed setups, and a way for your success team to see where each customer is in the process. Scope it explicitly, because it is the one part of the feature your own engineers cannot click through end to end without a second tenant to play the customer.
For the engineering detail behind this half of the ledger — container types, permission grants, Microsoft Graph calls — our recent step-by-step guide to building a SharePoint Embedded application covers the implementation layer this article deliberately stays above.
What the Effort Actually Looks Like
An honest framing for the roadmap meeting: for a competent team that already runs a multi-tenant SaaS product, the first production release of an embedded document feature is a matter of weeks — not the months a naive reading of the feature suggests, and emphatically not the years a from-scratch editor would consume. The platform’s side of the ledger is why. You are not building document collaboration; you are integrating it, and the integration surface is bounded.
What stretches the timeline is rarely the platform. It is your own side of the ledger: a permission model with years of accumulated special cases that resists clean mapping; enterprise customers whose admins must consent to your application touching their tenant, which adds an onboarding flow and a support script; UX iterations on the editor launch experience once real users touch it. In our experience the ratio of “integrating Microsoft’s capability” to “deciding what our product should do with it” runs about one to two — plan accordingly, and put your senior product thinking on the second part. The staffing shape follows from that ratio: this is not a project that needs a large team, but it does need your people who genuinely understand the existing permission model and the customers’ working patterns, because those are the two inputs no external partner can supply from outside.
Two engagements of ours illustrate the shape of the work from different angles. When we integrated in-browser Office editing into the document management platform of Kendox — via WOPI, the integration route of its era — the substantial engineering was never the editing surface itself: it was fitting the capability into their existing microservices architecture, supporting both their SaaS and on-premise deployment models, and collaborating with their in-house designers so the result felt like Kendox rather than an embedded foreign object. That distribution of effort is exactly what a SharePoint Embedded build looks like today, with less integration work at the editor end. And Slidebank, a presentation-management SaaS, is the organisational half of the same lesson: their customers demanded a mobile experience the in-house team had no capacity to build without derailing the core product, so we delivered the iPad app alongside them while their team stayed focused. Document features tend to arrive at ISVs the same way — urgent, adjacent to the roadmap, and competing with it for the same engineers.
Three Pitfalls That Surface After Launch
We see the same three mistakes often enough that they belong in any scoping conversation, precisely because none of them shows up in a demo.
Permission mapping that drifts. The launch-day mapping between your roles and container permissions is usually correct. The trouble is everything after: a new role added to your product without a corresponding container rule, a bulk role migration that never re-syncs grants, an admin tool that edits one side of the bridge. Treat the mapping as a continuously reconciled contract — with an automated job that detects and repairs divergence — not as a one-off translation done at container creation. The failure mode here is not a bug ticket; it is a customer’s security review finding.
Assuming desktop and web parity. Users will open documents in desktop Office the moment you let them, and the desktop applications are not the web editors: offline windows, different save semantics, features that behave differently across the two. If your product’s logic assumes the tight always-connected loop of the web editor — for status tracking, for locking, for notifications — desktop editing will quietly violate those assumptions. Decide deliberately whether to support desktop opening at launch, and if you do, test your product’s state machine against it rather than against the web editor alone.
Ignoring container lifecycle at offboarding. Every customer who signs will eventually leave, taking their contractual right to data deletion or export with them. If containers were created ad hoc and never tracked against customers, offboarding becomes an archaeology project — and orphaned containers keep costing you storage indefinitely. Build the offboarding path when you build the onboarding path: an auditable delete-or-export sequence per customer, exercised in testing, not designed for the first time when a churned customer’s deletion request arrives with a deadline attached.
What the three have in common is instructive: each one lives on your side of the ledger, in the seams between the platform and your product, and each is invisible in a demo because demos exercise the platform’s side — the editors, the co-authoring, the things that were always going to work. Weight your test plan, and your design reviews, towards the seams.
How McKenna Consultants Can Help
Scoping is where this feature is won or lost, and the ledger above is the shape of every successful scoping we have run: let the platform carry the editors, the co-authoring and the versioning, and spend your team — or ours — on the container lifecycle, the permission bridge and the product experience that make it yours. McKenna Consultants has been building Microsoft document integration for over 25 years, from in-application Office editing for document management vendors to the SharePoint Embedded work that now lets any SaaS product embed Microsoft 365 document editing inside its own walls.
If you are putting a document collaboration feature on your roadmap and want the scope, the estimate and the pitfalls examined by people who have shipped this before, get in touch — a short conversation at scoping time is worth a great deal more than a rescue later.
