“Copilot” is several products that get collapsed in procurement. Microsoft 365 Copilot is the add-on that sits in Word, Excel, PowerPoint, Outlook, Teams, and the Copilot app. Copilot Studio is the low-code environment for multi-step agents beyond Microsoft. Nimbus is for work that leaves Microsoft — Salesforce, NetSuite, and the rest of the stack where money actually moves.

Nobody else will be as good at “summarise this thread and the attached deck” inside Outlook. That recap is tenant productivity. Updating forty opportunities in Salesforce is company operations. If your programme starts with “every knowledge worker has a Copilot licence,” you are specifying Microsoft. If it starts with “RevOps will not allow unapproved Salesforce writes from an agent, and we need a record of those releases,” you are specifying Nimbus. You can keep both. Using Nimbus does not mean ripping Copilot out of Office.

Microsoft’s own architecture and privacy docs are the source: Copilot is grounded in Microsoft Graph — mail, files, meetings, and sites the user can already access — and prompts, responses, and Graph data are not used to train foundation LLMs. That is the right privacy story for find-and-draft inside Microsoft. It still describes find and draft inside Microsoft, not sign a write in Salesforce. Agent Builder covers simple agents inside Copilot, grounded in Microsoft 365 content, for information workers. Studio is the step that leaves Graph.

Words you’ll hear

Microsoft 365 Copilot. The per-person assistant inside Office, grounded in Microsoft Graph — mail, files, meetings, and sites the user can already access.
Microsoft Graph. The map of what this person can already open in Microsoft 365. Copilot should not leak a file they cannot open in SharePoint.
Copilot Studio. Low-code agents with branching, approvals, and connectors to Salesforce, SAP, ServiceNow, and custom APIs. You can publish to Teams. Metering is often credits or messages on top of licences.
Agent Builder. Simple agents inside Copilot, grounded in Microsoft 365 content, for information workers.
Workstream. In Nimbus, a shared workspace for one job across systems that are not all Microsoft.
Write-back. Changing a live system. You can update Salesforce from Studio. The update is a flow-shaped side effect in Microsoft’s world. In Nimbus it is a quoted release with a named signer.
Lifecycle Graph. The causal record of who approved, what changed, and what the next team should believe.
E5. Microsoft 365 E5 explains identity, compliance, and Office. It does not explain CRM write-back or a company work ledger.

Why the difference matters

Studio agents that leave Graph for other connectors inherit a different permission story: connector logins, rules that stop sensitive files leaking, environment strategy. IT knows this is where Copilot programmes stall. You can update Salesforce from Studio. The update is a flow-shaped side effect in Microsoft’s world. In Nimbus it is a quoted release with a named signer. Approvals in a Power Platform artefact are real. They are not a Lifecycle Graph of the job across departments.

In Nimbus, the scarce resource is control of work across systems that are not all Microsoft. The quarterly review deck may live in SharePoint. The opportunities live in Salesforce. The revenue number finance trusts may live in NetSuite. A workstream puts those in one job. Records stay read-only until someone who is allowed to approve writes actually does. The Lifecycle Graph keeps the release.

Glean-class search and Copilot-class Graph grounding solve findability. Nimbus assumes you can already find the policy. The failure is that AI work does not land in a signed-off artefact. Purpose limitation is easier to explain when a recruiting workstream cannot see finance forecasts. A Copilot licence that sees “whatever this user can already open” is a different design — Microsoft’s Graph design, by intention. That design is correct inside Office. It is a wide blast radius if the same licence is treated as the operating model for every system the user can already open.

Lock-in is the honest trade. Copilot deepens Microsoft 365. Nimbus is lock-in of a different kind: the work loop and the graph. If most proprietary work is already in Microsoft, Copilot’s return is easier. If most money-moving systems are Salesforce, NetSuite, and specialist software, Copilot Studio becomes a connector project — and Nimbus was designed as that project plus the record. E5 explains identity, compliance, and Office. It does not explain CRM write-back, choosing models across vendors, or a Lifecycle Graph. Standardise Copilot where Microsoft’s graph is the work. Standardise an operating layer where the business process is the work.

Role by role: a knowledge worker in Word, Excel, Outlook, and Teams wants the side pane — nobody else will recap the thread and the attached deck as well. IT owns Graph, licences, and often Studio as a Power Platform artefact: a helpdesk bot, an HR FAQ, a Teams helper. RevOps lives in Salesforce, not in SharePoint; a Studio connector to Salesforce is a flow-shaped side effect, not a company release. Finance trusts NetSuite, not the recap. Security will like Graph grounding and the privacy docs, and still ask who signed a CRM write. A CIO who already bought E5 should use Copilot where Microsoft’s graph is the work — and still not pretend E5 bought an operating layer.

SharePoint agents are Q&A on sites. Use them for findability. Do not use them as the operating model. Keep Copilot in Office. Put the job that leaves Microsoft in a workstream.

When Microsoft Copilot is a better fit

Choose Microsoft 365 Copilot when the job is knowledge-worker productivity in Word, Excel, Outlook, and Teams, and Microsoft’s own files and mail are the corpus.

Choose Copilot Studio when the agent is a Power Platform artefact IT will own — a helpdesk bot, an HR FAQ, a Teams helper. Metering is often credits or messages on top of licences; budget that as a Microsoft programme, not as a Nimbus substitute.

SharePoint agents are Q&A on sites. Use them for findability. Do not use them as the operating model.

Do not choose Copilot as a stealth operating layer for non-Microsoft systems. You will spend a year on connector reviews and still lack workstreams, specialist teams, and a Lifecycle Graph.

Keep Copilot in Office. Using Nimbus does not mean ripping it out. A coherent coexistence: Copilot for tenant productivity; Nimbus for jobs that also touch Salesforce, NetSuite, and the rest of the stack. Drafts can move from a recap into a workstream. Write credentials for money-moving systems should sit in Nimbus connector scopes, not in a Studio flow by default.

How this shows up in Nimbus

Nimbus does not try to be the Word side pane. It does not assume the only intelligence in the company is whatever Microsoft licensed this quarter. See models. Routing includes not throwing the most powerful model at a simple lookup. Treat Microsoft-hosted models as infrastructure options in an enterprise conversation with sales, not as a reason Copilot and Nimbus are the same product.

The wiki is what the company asserts. Connectors are scoped per workspace. Agents get the systems you attached, in the mode you allowed, until a human releases a write. Agent teams finish the work Copilot handed you after the recap.

You can set Nimbus up yourselves. Copilot programmes at organisational scale are famous for implementation. Keep Copilot in Office; do not staff a consulting partner to invent an operating layer.

See Governance.

Questions people actually ask

Does Nimbus replace Microsoft 365 Copilot?

No. Keep Copilot in Office. Nimbus does not try to be the Word side pane. It tries to be the place agent teams finish work that leaves Microsoft.

Does Copilot Studio replace Nimbus?

Only if “a few Power Platform agents” is the entire AI programme. Studio can be shared inside the Microsoft tenant. It does not replace Nimbus as a governed execution layer with a company wiki and an operational ledger.

Can Nimbus use Azure OpenAI or Microsoft models?

Nimbus routes models for quality, cost, and latency — including not throwing the most powerful model at a simple lookup. Treat Microsoft-hosted models as infrastructure options in an enterprise conversation with sales, not as a reason Copilot and Nimbus are the same product.

Why not standardise on Copilot because we already buy Microsoft 365 E5?

E5 explains identity, compliance, and Office. It does not explain CRM write-back, choosing models across vendors, or a Lifecycle Graph. Standardise Copilot where Microsoft’s graph is the work. Standardise an operating layer where the business process is the work.

Do we need a Microsoft partner to get Nimbus running?

No. You can set it up yourselves. Copilot Studio at organisational scale usually is not self-serve in the same way.

Can we keep Copilot and put Salesforce writes in Nimbus?

Yes. That is the intended coexistence. Recap in Outlook; finish in a workstream. Do not let a Studio Salesforce connector become the unofficial write path “because we already had an approval step in the flow.” Quote the change, name the signer, store the outcome.

Who should own which product?

IT typically owns Microsoft 365 Copilot and Studio: licences, Graph, Power Platform environments. Line operators own Nimbus workstreams that touch Salesforce, NetSuite, and specialist systems. Security reviews Graph grounding and write gates. A single “we already pay Microsoft” owner will stretch Copilot into an operating layer.

What about Glean if we already have Copilot?

Copilot respects Microsoft permissions inside Microsoft. Glean searches across many apps, including Microsoft, and respects source permissions. You may still need Glean if SharePoint search is not enough, and still need Nimbus if neither is an operating layer. See Nimbus vs Glean.

What is write-back governance, What is an enterprise AI operating system, and Nimbus vs Glean.

Nimbus vs Microsoft Copilot: Great Inside Office, or Work That Leaves Microsoft?