Copilot + Salesforce: Three Approaches Compared

Enterprise customer context is split across two systems. Salesforce holds the system of record: accounts, opportunities, cases, custom objects, activity histories, and team execution data. Microsoft 365 holds the working layer: email threads, meeting transcripts, documents, and spreadsheets.

Microsoft 365 Copilot excels at working across M365 content. The gap is governed, user-level Salesforce context - available inside Copilot, with the same security controls and compliance requirements your Salesforce org enforces. Three realistic approaches exist to close that gap.

The table below summarizes the key trade-offs across eight dimensions that matter most for enterprise deployments:

Microsoft provides a prebuilt Salesforce connector that indexes Salesforce records into Microsoft Graph, making them searchable from Copilot and Microsoft Search. It's a Microsoft-managed service configured through the M365 admin center - no middleware to host.

The limitations that matter for enterprise Salesforce orgs:

• Five standard objects only. Accounts, Contacts, Opportunities, Leads, and Cases. Custom objects, Orders, Contracts, and Activities are not supported. [1]
• Permission gaps. Microsoft's documentation states the connector does not support Apex-based sharing, territory-based sharing, or personal group sharing. Managed permission sets and permission set groups are not honored, which can cause fields to not be indexed or appear for users who shouldn't see them. [1][2]
• Data indexed outside Salesforce. The connector ingests Salesforce data into Microsoft Graph. [3] For regulated industries, this data movement creates a compliance review requirement - Salesforce records are now stored and processed in Microsoft's infrastructure.
• Read-only, no PII masking. There is no write-back capability and no built-in data masking. Whatever fields are indexed are indexed as-is. [1]

Bottom line: The Graph Connector is a search tool for broad keyword lookups against a limited set of standard objects. It is not a governed integration layer for complex Salesforce environments.

Microsoft Copilot Studio lets you build custom agents that connect to Salesforce through the Power Platform connector. This gives more flexibility than the Graph Connector - at the cost of significantly more development and ongoing maintenance.

Key trade-offs:

• Service account authentication. The Power Platform Salesforce connector authenticates via a service account or shared connection. Every user sees Salesforce data through that account's permissions - not their own. In orgs with role hierarchies or territory management, this is a meaningful security gap. [4]
• Manual object and field mapping. Every Salesforce object and field must be explicitly mapped. Custom objects require custom configuration. Schema changes require maintenance. [5]
• 500KB response limit. Copilot Studio limits connector responses to 500KB. [6] Rich account context - related opportunities, contacts, activities - frequently exceeds this ceiling, requiring payload trimming that reduces what Copilot can reason over.
• Consumption-based pricing. Messages and Power Platform API calls are metered. For high-volume enterprise usage, costs escalate unpredictably.

Bottom line: Viable if you have a strong Power Platform team and can accept service-account-level permissions. But you are building and maintaining a custom integration with all the time and cost that implies.

GPTfy takes a different architectural approach: instead of pulling Salesforce data into Microsoft's ecosystem, GPTfy runs inside your Salesforce org and returns governed, processed context to Copilot on demand.

A Microsoft 365 Copilot extension - available from Microsoft AppSource - covers Word, Excel, PowerPoint, Teams, and Outlook in a single install. Users invoke GPTfy from within Copilot to pull the right Salesforce context for the task at hand.

Why the architecture matters:

• Automatic metadata access. GPTfy runs as a managed package inside Salesforce, so it understands custom objects, custom fields, formula fields, and relationships automatically - no manual mapping required. [7]
• Native permission enforcement. Every query executes in the requesting user's Salesforce security context - sharing rules, field-level security, role hierarchy, and record-level access all respected per user. [7]
• Zero data movement. Raw Salesforce records stay in Salesforce. Only the masked, AI-processed response is returned to Copilot. [7]
• Four-layer PII/PHI masking. Field-value masking, regex pattern detection (SSNs, phone numbers, emails), blocklists, and custom Apex masking - all applied before data leaves your org. [8]
• Configuration-driven write-back. Copilot logs summaries, creates tasks, opens cases, and updates account notes - with admin control over which actions are permitted. [7]
• Dual-platform certification. Certified on both Salesforce AppExchange [10] and Microsoft AppSource [9] - security reviews passed on both platforms.

For full technical details, download the GPTfy Copilot integration datasheet.

The Graph Connector makes sense when you need basic search across standard Salesforce objects, your org doesn't rely on custom objects or complex permission models, and you don't handle sensitive data requiring masking. Lightest weight, lowest capability.

Copilot Studio makes sense when you have a dedicated Power Platform team, your use case is narrow enough that service-account permissions are acceptable, and you're prepared to build and maintain the integration over time. Flexible, but requires ongoing investment.

GPTfy makes sense when Copilot needs to work with the full richness of your Salesforce data model - custom objects, complex permission hierarchies, sensitive data - and you need to go live quickly with predictable costs. It's the default choice for regulated industries and enterprises with mature Salesforce implementations. See the broader platform comparison for additional context on AI architecture trade-offs.

The most impactful Copilot workflows are not one-shot queries - they are agentic: retrieve Salesforce context, reason over it, generate a Microsoft 365 artifact, write the outcome back to Salesforce, and trigger the next step. This full loop requires an integration layer with governed read and write access to the Salesforce data model, executing in the user's security context.

GPTfy Agents are built specifically for this pattern. Because GPTfy runs inside Salesforce with native permissions, four-layer masking, and admin-configured write-back governance, it powers agentic AI workflows spanning the full Salesforce-Microsoft boundary - without moving raw records out of Salesforce or requiring service-account workarounds. A rep can retrieve an Account 360, generate a QBR PowerPoint, and draft a Word proposal in a single governed loop.

A read-only index cannot complete this loop. A service-account integration cannot enforce per-user governance at the write step. Agentic AI in regulated enterprises requires each step - retrieve, reason, generate, write back - to be governed, auditable, and permission-enforced. That is what the Salesforce-native architecture provides.

All claims about Microsoft product capabilities and limitations are sourced from official Microsoft documentation. GPTfy claims are sourced from GPTfy's product documentation and AppExchange and AppSource listings.

Last verified: February 2026