Build the engagement layer once. Let one agent act across all your systems of record.

With Customer 360 Assistant, people ask in Microsoft Teams. One Microsoft Foundry agent routes each request to the right tool, and every action runs as the signed-in user, with their own permissions in each system.

Watch the 2:40 story Deploy the sample

Engagement layer

Built once, where people work

Teams chats1:1 and group chats
Microsoft 365 Copilotvia Foundry publishing
Web chatsample app included

One agent

Routes every request

Microsoft Foundry agent Understands the request and picks the right tools

Identity gateway

Azure API Management

Swaps in the user's own token

Systems of record

Solid: included. Dashed: add yours.

SalesforceCRMas Alice(included)
ServiceNowITSMas Alice(included)
JiraWork trackingNot included
SAPERPNot included
WorkdayHRNot included
Your APICustomNot included

Alice signs in once. Every wire carries her identity, so each system applies Alice's own permissions.

Customer 360 Assistant is an open-source reference implementation. Salesforce and ServiceNow are working examples; Jira, SAP, Workday and your own APIs are not included and follow the same pattern.

Five minutes before the call.

Alice, an account manager, has five minutes before a call with Contoso. In a Teams group chat she gets a 360° view across Salesforce and ServiceNow. After the call, she updates the CRM in one sentence. Every action runs as Alice.

2 min 40 s, silent, with burned-in English captions. Animated mock-ups with demo data (Contoso, Alice, Bob).

Consent is designed to happen once per system; a current Foundry platform issue can ask users to consent again after about an hour (known issue).

Read the transcript and scene descriptions

A real Monday morning
A countdown: your customer call starts in five minutes.
Meet Alice, an account manager. Her biggest customer, Contoso, joins a call in 5 minutes.
Two teams, two systems, one customer
CRM in Salesforce and ITSM in ServiceNow side by side. Nobody sees the risk.
Deals live in Salesforce. Support tickets live in ServiceNow. Connecting the dots by hand takes much longer than five minutes.
One question
In a Teams group chat, Alice types "Give me a Customer 360 view for Contoso Ltd". Behind the scenes, acting as Alice, the assistant reaches Salesforce and ServiceNow.
So Alice asks her assistant, right in a Teams group chat. It queries Salesforce and ServiceNow using Alice's own access.
The 360° answer
Open pipeline: Contoso Analytics Add-on, $350k, in Qualification. Open cases: trading desk dashboard timeout, report generation slow. IT incidents: database performance degradation, network latency in EU-West. Both cases trace back to one database incident; suggested action: share the fix ETA on the call.
Seconds later, she has the open deal, worth $350k… the customer's open support cases… and the IT incidents behind them. One root cause behind both cases, and a $350k deal at risk.
After the call
The call is done. Time to update the CRM.
The call goes well. Now the CRM needs an update.
Update by asking
Alice types: "Add a note on the Contoso Analytics Add-on opp: customer wants a POC first. Move the close date to next quarter."
One sentence, in the chat she already has open. She asks for a note for the team and a new close date.
Written to Salesforce
"Done. Two updates, zero clicks." The opportunity shows the note and a close date moved from Dec 18, 2026 to Mar 31, 2027.
The assistant logs the note in Salesforce and moves the close date. And the record shows exactly who made the change.
Look closer
Last modified by: Alice. Not a bot. Not a service account.
Salesforce recorded the change under Alice's own name.
Follow Alice's identity
Alice in Teams, then the agent (Teams bot and Foundry agent, no master key), then the API gateway (Azure API Management: validate Alice's token, find her account in each system, get a token for Alice in each system), then Salesforce and ServiceNow, each "as Alice". Her permissions. Their rules.
How does it work? Follow Alice's identity. She is signed in to Teams with her work account. The agent has no master key. It carries Alice's token. The gateway checks it, then gets Alice's own token for each system. Each system enforces its own rules. Alice sees only what she may see.
Consent once
An OAuth consent card: "Customer 360 Assistant wants to access Salesforce as you". Alice selects Allow access, and the card reads "Connected as Alice".
The first time, Alice approves access once for each system. After that, every request runs as her.
Why it matters
Trust built in, not bolted on: her permissions, no master key, fully traceable.
There is no over-privileged service account in the data path. Every read and write can be traced to a real person.
Where you already work
Inside Microsoft Teams: 1:1 chat, group chats, and as a Copilot agent.
It works in 1:1 chats, in group chats, and as a Copilot agent.
Open source
Customer 360 Assistant: identity-aware AI across your CRM and ITSM, with links to both GitHub repositories.
Customer 360 Assistant: the code is open source on GitHub.

Build the engagement layer once.

People already work in Teams. The assistant meets them there, and in Microsoft 365 Copilot through Foundry publishing, so there is no new portal to adopt. Every system you add later answers in the same conversation.

Teams 1:1 and group chatsAsk privately, or mention the assistant where the team already talks. azd up publishes a Teams app to your org catalog.
Microsoft 365 CopilotPublish the same agent from the Foundry portal. The Teams and Copilot guide covers both paths.
Web chatA sample web app (MSAL.js) signs people in and talks to any Foundry agent it discovers in your subscription.

One Foundry agent The same agent and the same identity, whichever host people use

One agent routes every request.

A Microsoft Foundry agent understands what the person needs, chooses the tools, correlates answers across systems and drafts the update. The same agent serves every host, and every read and write uses the asker's own access.

Before a customer call
“Prepare me for my QBR with Acme Corp. Pull everything from both systems.”
SalesforceServiceNow
Account review
“Give me a Customer 360 view for Contoso Ltd.”
SalesforceServiceNow
Incident triage
“We have a P1 incident about API gateway failures. Which accounts and open opportunities are affected?”
ServiceNowSalesforce
Change planning
“We're planning a billing upgrade on Saturday. Check the change request and the accounts with upcoming renewals.”
ServiceNowSalesforce
After the call
“Add a note on the Contoso Analytics Add-on opportunity: the customer wants a POC first. Move the close date to next quarter.”
Salesforce write, as the user

Adapted from the repository's test scenarios, which run against seeded demo data. The last prompt is the CRM update shown in the video.

Acts as the user, never as a super-user.

The agent holds no shared credential for your systems. It carries the signed-in user's identity, and each system decides what that person may see and change.

Sign in once
Alice signs in to Teams with her work account (Microsoft Entra ID).
Consent once per system, by design
Standard OAuth consent the first time the agent reaches a system; a known platform issue can ask again after about an hour.
The gateway swaps the token
Azure API Management validates Alice's token, finds her account in each system and gets a token issued to Alice.
Each system applies its rules
Sharing rules, field-level security and ACLs decide what Alice can see and change.
Writes carry her name

Opportunity · example data
Contoso Analytics Add-on

Last modified by
Alice

No shared credential touches business data. A minimal-access service account only maps Alice to her Salesforce user, and each per-user token exchange appears in Salesforce Login History.

Identity propagation stops privilege escalation, but it cannot stop an agent from misreading intent, so keep confirmations for destructive actions (what it does not protect against).

Your next system plugs into the same agent.

Salesforce and ServiceNow are working examples. Jira, SAP, Workday and your own APIs are not included; each would follow the same three-part pattern, while the agent, the Teams experience and the identity flow stay the same.

What each system of record needs. Salesforce and ServiceNow are included; the others follow the same pattern and are not included.
System of recordkeeps its own rules	Tool serverdiscover, query, act	Gateway policyuser-token exchange	Foundry connectionattaches the tools	Statusin this sample
SalesforceCRM	7 tools	OBO policy	OAuth2 connection	Included: this repository
ServiceNowITSM	3 tools	OBO policy	OAuth2 connection	Included: `snow-meta-tool`
JiraWork tracking	You add	You add	You add	Not included, same pattern
SAPERP	You add	You add	You add	Not included, same pattern
WorkdayHR	You add	You add	You add	Not included, same pattern
Your APICustom	You add	You add	You add	Not included, same pattern

Why meta-tools instead of one tool per object?

Many MCP servers define one tool per object, so every new object means new code and a longer tool list. A meta-tool server works like a shell: the agent discovers objects, learns their fields and builds the query itself, with the user's own access. Seven generic tools reach the standard and custom objects the user can see, and the list stays the same whatever the size of the org. Read the pattern.

What's in the box.

In this repository

Salesforce meta-tool server. Seven tools: discover objects, describe fields, query, search, write and run approvals, plus whoami.
Identity gateway. Azure API Management policies for the three-phase on-behalf-of (OBO) exchange.
Foundry agents. salesforce-assistant and customer360-assistant, wired through OAuth2 identity-passthrough connections.
Engagement. A web chat app, a Teams app for your org catalog, and Microsoft 365 Copilot through Foundry publishing.
Delivery. Bicep and azd, Salesforce org setup scripts, demo-data seeding and end-to-end tests.

The two-repo Customer 360 demo

snow-meta-tool. ServiceNow tools with the same pattern and the same identity flow.
Correlated demo data. Accounts, opportunities, cases and incidents that line up across both systems.

A reference implementation, not a product. It runs on demo data and has not been audited for production. Read the scope and limitations and the known platform issues before you adapt it.

For architects and developers.

Infrastructure as code, the gateway policies, the tool server and the agents are all in the repository. With the prerequisites in place, one command deploys the stack.

Azure architecture: browser and Teams clients, Container Apps for the chat app and bot channel, the Microsoft Foundry agent and model, API Management with the Salesforce and ServiceNow OBO policies and Key Vault certificates, the two MCP servers, and the external Salesforce and ServiceNow clouds, each enforcing the user's own permissions. — Full architecture. Select the image to open the full-resolution diagram on GitHub.

Deploy the Salesforce side

Prerequisites: a certificate, the Salesforce org setup, an Entra app for the OAuth2 connection and identity mapping. The installation guide walks through each one.

# after the prerequisites in docs/installation.md
azd env new obo
azd env set SF_INSTANCE_URL "https://your-org.my.salesforce.com"
azd env set SF_CONNECTED_APP_CLIENT_ID "<consumer-key>"
azd env set SF_SERVICE_ACCOUNT_USERNAME "<svc-user>"
azd env set MCP_OAUTH_CLIENT_ID "<mcp-oauth-app-id>"
azd env set MCP_OAUTH_CLIENT_SECRET "<secret>"
azd up