What Microsoft Copilot with Salesforce gives you today
Your company runs on Microsoft 365. Sales works in Salesforce, engineering works in Jira, and somebody has asked whether Copilot can cover both. The short answer: Microsoft Copilot with Salesforce and Jira is built for search and grounding over an indexed copy of your data. It is not built for taking live action inside either app. A separate path, using MCP (Model Context Protocol) clients like Claude, ChatGPT or Cursor, covers the live-action case. This post lays out both, with a comparison table and the specific permission and audit behavior each one gives you.
Every Microsoft claim below links the Microsoft Learn page it came from, checked October 2026, and anything marked preview or planned had not shipped then.
The four paths at a glance
| Path | What it does | Freshness | Writes to Salesforce or Jira | Where the control sits |
|---|---|---|---|---|
| Synced Copilot connectors | Index Salesforce CRM and Jira Cloud into Microsoft Graph for search and grounding | Permission changes sync only on full crawls | No | Default mode honors source permissions; admins choose which fields are indexed |
| Federated (MCP) connectors | Fetch live as the signed-in user | Live | No: Salesforce and Jira are not on the list today | Published by Microsoft or approved partners |
| Copilot Studio agents | Call the Premium Salesforce and Jira connectors, and MCP servers | Live | Yes | Power Platform data policies and advanced connector policies, per connector or whole MCP server |
| Elaichi | Serves Claude, ChatGPT and Cursor through one MCP endpoint, each call as the person | Live | Yes | Restrictions per role or user, down to one tool, and one audit trail |
The column that matters most is writes: only Copilot Studio and Elaichi write to Salesforce or Jira today.
Microsoft renamed Microsoft 365 Copilot to Microsoft Copilot in August 2026, and Graph connectors are now Copilot connectors. Synced Copilot connectors index Salesforce CRM and Jira Cloud into Microsoft Graph, and Copilot answers from that index (learn.microsoft.com, checked October 2026).
Federated connectors are Microsoft's live-read path. They fetch as the signed-in user at query time, and they are published by Microsoft or approved partners. Salesforce and Jira are not on that list today (learn.microsoft.com, checked October 2026).
The practical line falls here. "Find the renewal notes on the Acme account" is what the indexed path is for. "Create the renewal opportunity and link the Jira epic" is not. No Copilot connector, synced or federated, writes to either app today.
Why permission sync is not the same as live permissions
Synced Copilot connectors do honor the source app's permissions. The point to hold onto is that Microsoft Graph holds a copy, and a copy has a refresh schedule. It is not a window onto Salesforce or Jira, it is a snapshot of one.
Microsoft's own page for the Salesforce CRM connector states three specific behaviors. The default mode honors Salesforce record ownership, sharing rules and role hierarchy. Field-level security is not enforced if an admin opts in to index restricted fields. And permission changes sync only on full crawls, not incrementally (learn.microsoft.com, checked October 2026).
For an IT admin, that becomes two decisions, each made once and reviewed rarely: which fields get indexed, and how often a full crawl runs. A sharing change made in Salesforce on Monday reaches Copilot search only when the next full crawl runs. Check the connector's full-crawl schedule rather than assuming one.
A live call has no such lag, because it has no copy to go stale. Federated connectors and MCP-based tools evaluate permissions at the moment of the call, every time, against the source system directly. That gap is scheduled refresh versus per-call evaluation. It is the reason to pick one path for search and a different one for action, rather than forcing a single connector to do both.
Where do Copilot Studio and Agent 365 fit?
Copilot Studio is Microsoft's action path, and its governance is written per environment and per connector rather than per tool. Copilot Studio agents can call the Premium Salesforce and Jira connectors. Copilot Studio agents can also add MCP servers as tools (learn.microsoft.com, checked October 2026). Each tool runs on end-user credentials by default, with maker-provided credentials as an option an admin can forbid per environment (learn.microsoft.com, checked October 2026).
Governance rides on Power Platform, through two separate mechanisms that don't talk to each other:
- Data loss prevention (DLP) policies sort connectors into Business, Non-business and Blocked. Changes usually apply within an hour, and Microsoft's documented upper bound is 24 hours (learn.microsoft.com, checked October 2026).
- Advanced connector policies are a default-deny allowlist per environment or group. They can block a whole MCP server, but Microsoft states explicitly that per-tool MCP control is not available at this layer (learn.microsoft.com, checked October 2026).
The practical effect: one MCP server may expose both a read tool and a delete tool. The policy layer allows or blocks the server as one unit. A maker can switch off single tools inside one agent. That is a build choice per agent, not an admin policy (learn.microsoft.com, checked October 2026).
Agent 365 has been generally available since 1 May 2026. It is priced at $15 per user per month, or bundled into Microsoft 365 E7 (microsoft.com, checked October 2026). Its tooling gateway for registered MCP servers is in preview. Admins can approve or block servers at runtime today. Microsoft has stated tool-level blocking for those servers is planned but not shipped (learn.microsoft.com, checked October 2026). The side-by-side of Copilot Studio and an MCP gateway goes through that surface in more detail.
How Claude, ChatGPT and Cursor reach Salesforce and Jira live
The second path puts the live call directly in the AI client people already have open. The call does not go through an indexed copy or a separately governed Power Platform environment. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.
Elaichi serves one organization-wide MCP endpoint, POST https://api.elaichi.ai/mcp, behind OAuth (the sign-in standard that hands an app limited access without a shared password). There are no per-user URLs and no embedded tokens to manage or rotate. An admin adds the one address to each client where the client allows it. Each member then connects and signs in with their own grant. Clients register themselves through dynamic client registration, so there is no client ID or secret to distribute by hand.
Salesforce and Jira are both native connectors in Elaichi's catalog of 600+ connectors. Elaichi authors and serves them, rather than proxying them through a third-party integration platform. A rep connects their own Salesforce account; an engineer connects their own Jira account. Every read and every write then reaches the app as that person, evaluated live by Salesforce or Jira's own permission system. There is no index in between to go stale. A connection shared with a team runs on its owner's credential. Share one only where every person using it should be able to act as that single account.
Tool discovery works differently from a plain, flat server list, which matters once you connect more than one app to the same client. In Elaichi, connected tools are never listed one by one, however few there are. The model finds what it needs and calls it. That keeps a two-app rollout from filling the context window with every available tool on the first message. When a tool somebody expected is missing, the checks run in a fixed order.
One trade-off to state plainly, because it affects what "read-only" means in practice. On Elaichi's consent screen, the single permission "Run your connected tools" covers a connected app's reads and writes alike. Only a tool whose method is a delete also needs the "Delete data and remove access" box, which is never pre-ticked. There is no checkbox for "read-only" at connection time. Read-only access to Salesforce or Jira is something you write as a restriction afterward. It is not something a user selects when they first connect.
Writing restrictions for two apps at once
Restrictions decide which connectors and which individual tools a target may reach. A target is a role or a single user. A rule on a user replaces the role rules for that user rather than adding to them.
The trap with two apps is the allow rule. An allow rule is the target's entire allowlist, across every connector the target can see, not only the app it names. Write an allow rule to hold Jira to its read tools, and the role loses Salesforce entirely. The fix is a second allow rule naming Salesforce too. Allow rules on the same target union together, so one allow rule per app is the correct pattern once you know this. Holding a single app to reads while leaving every other connector untouched is done differently. Use blocks on that one app's write tools, not an allow rule at all. The per-tool against per-app decision covers the six cases where each shape is the right one.
Two more behaviors to know before you write anything:
- Blocks always beat allows within the layer that wins. A block is never silently overridden by a broader allow.
- In Elaichi, the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything.
Timing matters when you defend the setup to security or an auditor. A restriction change takes effect within about two minutes. Removal is faster. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.
What the audit trail records for both apps
Elaichi writes one entry per tool-call attempt, succeeded or failed. That holds across Salesforce and Jira alike. The recorded connection is the account actually reached, taken from the execution rather than the intent. That answers "which Jira site did it write to" without reconstructing it from context.
Each entry carries the operation and tool name, plus the surface and the OAuth client the call came through. It also carries whether it was approved, the outcome, and an error code. Argument names and counts are logged; argument values never are. A call made from Claude or Cursor is recorded as a user action, attributed to the person who made it, not to "the assistant."
One more distinction: the error text returned to the caller is derived from the third party's response, Salesforce's or Jira's own error message. The error written to the audit trail is not the same string. Audit records are org-visible and may fan out to a customer's own logging destination. So what is written there is an error code, never derived from Salesforce's or Jira's response.
On plans: the audit trail is on Elaichi's Gold plan. Forwarding it to your own Datadog comes with the Black plan, launching soon.
When the Microsoft path is the right answer
Say your people work in Teams, Outlook and Word, and what they want is to find things. Then the synced Copilot connectors are the complete and correct setup. The index honors source permissions in its default mode, you control which fields are indexed, and there is no second vendor in the call path. Adding anything else buys you nothing for a pure-search use case.
The Microsoft path is also right when the action you want is a Copilot Studio agent running inside Power Platform. Those agents are built and governed by the admins who already run environments and DLP policies. That fits especially well if the write operations you need are already exposed as Premium connectors.
The second path earns its place when three things are true at once. People are working in Claude, ChatGPT or Cursor rather than only in Microsoft surfaces. They need live reads and writes in Salesforce and Jira, as themselves, not through a shared service account. And you want the permission decision written once, per role, down to a single tool. One audit trail then covers both apps, instead of two separate connector logs.
Elaichi has two plans, Gold and Black. Gold is $15 per user per month as the USD list price; pricing shows the local figure. 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two. Disclosure: Elaichi, the MCP control plane described as the second path above, publishes this blog. The comparison table and Microsoft-side claims are sourced independently from Microsoft's own documentation, linked throughout.
For the wider shape of this category, read what an MCP control plane is. For the team-level walkthroughs behind this post, see giving each rep their own Salesforce access in ChatGPT. There is also rolling Cursor out to an engineering team on Jira. The full connector catalog lists what else is reachable from the same address.
