SharePoint Online integrates with Salesforce through the Microsoft Connector for Salesforce or custom Microsoft Graph + Salesforce REST patterns, with Microsoft Teams natively (every Teams channel has a SharePoint Online site behind it), and with Power BI through embedded reports, native data connectors, and Power Platform dataflows. These three integrations cover most US enterprise SharePoint integration requests by volume and are mature enough that the practitioner question is less "can we" and more "how, with what discipline, and what to watch for."
This guide walks each integration with practical architecture patterns, identity and permission handling, performance and maintenance considerations, and where each integration fails when designed casually. It is written for US IT leaders, integration architects, SharePoint administrators, and digital workplace owners scoping the three most-requested SharePoint integrations.
Salesforce Integration
SharePoint-Salesforce integration usually has one of two directions. Documents in SharePoint surfaced inside Salesforce records is the more common pattern: contracts, proposals, and related collateral live in SharePoint Online libraries with proper retention and access controls, and Salesforce users see them inside the account, opportunity, or case they are working in.
The reverse pattern Salesforce records surfaced in SharePoint pages is less common but appears in customer portals and partner portals built on SharePoint. The two production patterns to choose between are the Microsoft Connector for Salesforce (low-friction, vendor-supported, limited customization) and a custom Microsoft Graph + Salesforce REST integration glued through Azure Functions or middleware (more work, more flexibility, more lifecycle responsibility). The identity story Entra ID on Microsoft, Salesforce identity on the other has to be designed deliberately, especially for external partner scenarios.
Teams Integration
Microsoft Teams and SharePoint Online are already integrated by Microsoft's product architecture. Every Teams channel has a SharePoint Online site behind it; the Files tab is a SharePoint Online document library; the team itself is a Microsoft 365 group that creates the SharePoint site, the OneNote, and the related artifacts. The practical integration question is not whether Teams and SharePoint connect; it is how to design the information architecture so the two surfaces feel coherent.
Common pitfalls: SharePoint sites that pre-existed Teams adoption now coexisting with Teams-spawned SharePoint sites, file sprawl, duplicate document libraries, and confusion about which surface is authoritative. The pattern that works: a deliberate site taxonomy with hub sites in SharePoint, Teams created from existing SharePoint patterns where possible, and explicit guidance to business users about which surface to use for which work. Loop components add another layer for cross-Teams, cross-SharePoint live content.
Power BI Integration
Power BI integrates with SharePoint Online in three production patterns. Embedded reports: the Power BI web part on a SharePoint Online modern page embeds an interactive report, with row-level security inherited from Power BI.
Data source: Power BI datasets source from SharePoint lists and libraries through the Power Platform Power BI connector or direct dataflows, often combining SharePoint data with other enterprise data sources for richer analytics. Bidirectional: Power BI dashboards that trigger Power Automate flows which write back to SharePoint, closing the loop for some workflow scenarios.
The integration is structurally simple because both products are Microsoft and share Entra ID; the design questions are about row-level security, refresh scheduling, dataset ownership, and avoiding Power BI sprawl alongside SharePoint sprawl.
Integration Architecture Patterns
The architecture patterns that recur across all three integrations are worth naming explicitly. Microsoft Graph for SharePoint data access. Power Platform connectors (Power Automate, Power Apps) for declarative business logic.
Native vendor connectors (Microsoft Connector for Salesforce, Power BI connector for SharePoint) where vendor depth justifies the choice. Custom APIs and Azure Functions for bespoke logic or high-volume scenarios.
Middleware (MuleSoft, Boomi, Azure Integration Services) for enterprises with established integration platforms. The choice depends on volume, complexity, ownership, and existing platform investment.
|
Integration |
Common pattern |
When to switch pattern |
|
Salesforce documents |
Microsoft Connector for Salesforce |
Bespoke logic, high volume |
|
Salesforce records in SP |
Power Automate + Salesforce REST |
Real-time, high volume |
|
Teams files |
Native SharePoint behind channel |
Always |
|
Teams cross-team content |
Loop components |
When cross-team live editing matters |
|
Power BI embed |
Power BI web part on SPFx page |
Always for embed |
|
Power BI data |
Power Platform connector / dataflow |
Always for SharePoint as source |
Security and Identity
Security and identity design is where SharePoint integrations succeed or fail at scale. Entra ID app registrations with least-privilege scopes are the baseline. Conditional access policies that the integration respects. Service accounts replaced by app-only authentication wherever possible.
Permissions reconciled on both sides SharePoint permissions and the other system's permission model have to agree on who can see what. Sensitivity labels carried across the integration where possible. DLP policies that span the integration where regulatory requirements demand it. General guidance, not legal or compliance advice; consult counsel and your security function.
Performance Considerations
Performance failures in SharePoint integrations show up as page load delays, refresh timeouts, throttling errors, and silent data lag. Microsoft Graph has well-published throttling thresholds; Salesforce has API call limits; Power BI has dataset refresh limits.
Production integrations need batch sizing, retry logic, exponential backoff, and monitoring. Embedded Power BI reports need refresh scheduling that does not overlap peak SharePoint page-load windows. Real-time integrations need event-driven design (webhooks, change notifications) rather than polling.
Maintenance and Versioning
Integrations have a long lifecycle. Vendor connectors get updated by their vendors and may change behavior. Microsoft Graph and Power Platform connectors receive continuous updates. Custom code needs ongoing engineering ownership.
Permissions and identity configurations drift; sensitivity labels and DLP policies evolve. The maintenance posture should be designed at the same time as the integration itself: who owns it, who tests it after vendor updates, who responds to alerts. Orphaned integrations are the most common source of post-migration integration incidents.
How to Get Started?
Three steps usually move an organization from "we want this integration" to a working production deployment.
- Inventory the integration requirement: data flow direction, volume, identity, permissions, lifecycle.
- Choose the pattern using the architecture matrix above usually Microsoft Connector or Power Automate first, custom only when the simpler pattern does not fit.
- Build with a security, performance, and maintenance plan from day one.
Centric runs SharePoint integrations through its SharePoint migration & integration practice, as part of the broader Centric SharePoint consulting practice.
Frequently Asked Questions
Which SharePoint integration is easiest?
Teams is structurally already integrated. Power BI is next because both share Entra ID and vendor connectors. Salesforce takes the most design work because of the cross-vendor identity and permission reconciliation.
Do we need custom code to integrate?
Usually not for the standard patterns. Microsoft Connector for Salesforce, Power BI connectors, and native Teams-SharePoint structure cover most use cases. Custom code is for bespoke logic or volumes that exceed connector limits.
How do we handle permissions across SharePoint and Salesforce?
Reconcile both sides explicitly in design. Decide which system is authoritative for which decisions; document the rules; verify on a sample of users in test before production.
Can we embed Power BI inside SharePoint without licensing every viewer?
Power BI embedded in SharePoint typically still requires Power BI licensing for viewers (with some Microsoft 365 E5 considerations). Confirm licensing for your scenario with Microsoft licensing or your reseller.
What about Loop components in Teams and SharePoint?
Loop is the newer Microsoft surface for live, cross-Teams, cross-SharePoint content components. It complements rather than replaces the native Teams-SharePoint integration and is worth considering for cross-team collaboration use cases.
How do we monitor SharePoint integrations in production?
Microsoft 365 admin center reports for SharePoint and Power Platform, custom monitoring for any Azure Functions or middleware, and alerting on the connection points that matter most to the business. Orphaned integrations are the most common failure mode.
How do we keep integrations from breaking when vendors update?
Named ownership for each integration, regular regression testing against vendor sandbox releases, and a maintenance backlog. The cost is real and should be budgeted.
Conclusion
SharePoint integrations with Salesforce, Teams, and Power BI are mature, well-tooled, and high-value when designed with discipline. The patterns are known; the failure modes are known; the security, performance, and maintenance considerations are known.
The work is in choosing the right pattern for the use case, designing the identity and permission story deliberately, and budgeting for ongoing maintenance and Centric is well-positioned to guide that work.
