Enterprise LOB MCP Apps for M365 Copilot - Salesforce, ServiceNow, HubSpot.

Disclosure: I work on this at Microsoft.

We have developed an open-sourced collection of interactive-UI samples for MCP / the Apps SDK — servers that render widgets (forms, record views, dashboards) in the client instead of returning text.

The samples cover a range of scenarios, from field ops and expense submission to insurance and training, But the ones enterprises keep asking for are the core LOB systems, so those are the most built-out: Salesforce CRM, ServiceNow ITSM, HubSpot CRM (MIT licensed).

What they actually do: you ask Copilot something like "show my open opportunities" or "create a lead for Acme," and instead of a wall of text you get a real widget — a record list, an editable form, a dashboard — right in the chat. Edit a field, submit, done. The MCP server exposes CRM operations as tools; the widget is what comes back.

Repo (servers + React widget source + deploy scripts), MIT: https://github.com/microsoft/mcp-interactiveUI-samples

A few things we worked out while building them:

• The UI is React. Each tool result maps to a React/TS widget (record views, editable forms, dashboards) that renders in the client. The server sends data + which widget; the widget owns the interaction. Widget source is in the repo, not just screenshots.
• Foreign keys resolved server-side. Users talk in names, not IDs — "opps for Acme." The tool takes account_name and resolves the FK (Account.Name lookup, parent-traversal LIKE) on the server. On a miss it returns suggestions instead of a dead end, so the model never has to guess an AccountId.
• A shared_mcp helper package. The boring-but-critical parts — auth, HTTP, logging, telemetry — live in one shared_mcp module that could be reused by every app. So each app is mostly just its domain tools + widgets, and cross-cutting fixes land in one place.
• Tools named as verbs on entities. Consistent get_/create_/update_ per object (get_leads, create_lead, update_lead, get_opportunities, …). Predictable surface the model picks from reliably, and a plus a show_create_form verb for "open the form" instead of writing directly.

Where it stands: These run end-to-end against real Salesforce/ServiceNow/HubSpot orgs (live REST APIs, not mock data), with local + Azure Container Apps deploy scripts.

They're reference samples meant to be forked and adapted — not a hardened product. Auth today is a service identity (Connected App / client-credentials); per-user OAuth so each user only sees their own records is the next step.

Would love feedback:

1. - What LOB system should we build next (SAP, Workday, Jira, Dynamics…)?
2. - Better patterns for UI-returning MCP tools than what's above?
3. - How are you handling per-user auth / downstream token exchange for MCP servers?
4. - Anything that'd make these easier to actually adopt at work?

Video: https://youtu.be/eELXlXAn2ac?si=2WxlEMeAWlJSgU1K

LOB MCP Apps

Enterprise LOB MCP Apps - Salesforce, ServiceNow, HubSpot.

Disclosure: I work on this at Microsoft.

We have developed an open-sourced collection of interactive-UI samples for MCP / the Apps SDK — servers that render widgets (forms, record views, dashboards) in the client instead of returning text.

The samples cover a range of scenarios, from field ops and expense submission to insurance and training, But the ones enterprises keep asking for are the core LOB systems, so those are the most built-out: Salesforce CRM, ServiceNow ITSM, HubSpot CRM (MIT licensed).

What they actually do: you ask Copilot something like "show my open opportunities" or "create a lead for Acme," and instead of a wall of text you get a real widget — a record list, an editable form, a dashboard — right in the chat. Edit a field, submit, done. The MCP server exposes CRM operations as tools; the widget is what comes back.

Repo (servers + React widget source + deploy scripts), MIT: https://github.com/microsoft/mcp-interactiveUI-samples#enterprise-lob-mcp-apps

A few things we worked out while building them:

• The UI is React. Each tool result maps to a React/TS widget (record views, editable forms, dashboards) that renders in the client. The server sends data + which widget; the widget owns the interaction. Widget source is in the repo, not just screenshots.
• Foreign keys resolved server-side. Users talk in names, not IDs — "opps for Acme." The tool takes account_name and resolves the FK (Account.Name lookup, parent-traversal LIKE) on the server. On a miss it returns suggestions instead of a dead end, so the model never has to guess an AccountId.
• A shared_mcp helper package. The boring-but-critical parts — auth, HTTP, logging, telemetry — live in one shared_mcp module that could be reused by every app. So each app is mostly just its domain tools + widgets, and cross-cutting fixes land in one place.
• Tools named as verbs on entities. Consistent get_/create_/update_ per object (get_leads, create_lead, update_lead, get_opportunities, …). Predictable surface the model picks from reliably, and a plus a show_create_form verb for "open the form" instead of writing directly.

Where it stands: These run end-to-end against real Salesforce/ServiceNow/HubSpot orgs (live REST APIs, not mock data), with local + Azure Container Apps deploy scripts.

They're reference samples meant to be forked and adapted — not a hardened product. Auth today is a service identity (Connected App / client-credentials); per-user OAuth so each user only sees their own records is the next step.

Would love feedback:

1. - What LOB system should we build next (SAP, Workday, Jira, Dynamics…)?
2. - Better patterns for UI-returning MCP tools than what's above?
3. - How are you handling per-user auth / downstream token exchange for MCP servers?
4. - Anything that'd make these easier to actually adopt at work?