Skip to main content

Staffbase Integrations: All 14 Methods Compared

12 min read
Staffbase Integrations: All 14 Methods Compared

Staffbase is live, the app is rolled out – and now a colleague from the business asks if you can “just quickly” add the cafeteria menu. The honest answer: Yes, you can. But there are 14 different ways to get there, and the wrong one will cost you months.

This article covers all 14 integration options with a comparison table at the end.

Don’t feel like reading? Our Integration Finder guides you to the right method in 3 simple steps.

Before You Read On: Three Questions That Clarify Everything

Most integration projects don’t fail because of technology. They fail because the wrong approach was chosen. Before diving into the details, answer three questions:

  1. Who’s implementing it? Editors with no technical background? IT admins with basic skills? Or a development team?
  2. What should employees see? Static links? Live data from third-party systems? Interactive elements?
  3. How fast does it need to happen? This week? This month? Or is it a strategic project?

The answers will lead you straight to the right category in the comparison table below.

What Staffbase Integrations Are Available?

1. Custom Widgets (Web Components)

Custom Widgets are standalone UI components embedded directly into Staffbase News and Pages. They’re built on the Web Components standard and communicate with the platform through the Staffbase Widget SDK.

What this means in practice: A Custom Widget behaves like any standard Staffbase widget for editors. It shows up in the widget picker, can be placed via drag & drop, and configured. Under the hood, it can display any data – from cafeteria menus to shift schedules to SAP data.

When to use: When you want to display live data from third-party systems with a native Staffbase experience. Typical use cases: lunch menus, transit departures, KPI dashboards, employee directories.

Effort: Medium. Staffbase provides a widget generator that creates the scaffolding. The actual logic (data connection, UI) requires web development skills – or a low-code tool like Widget Builder that reduces development effort to hours.

Limitation: Custom Widgets are only available in News and Pages, not in the public area of the app.

2. Custom Plugins (iframe-based)

Custom Plugins are standalone web applications embedded via iframe in Staffbase. The Plugins Client SDK provides a JavaScript bridge for communication between the plugin and the Staffbase platform.

What this means in practice: You build a regular web application and embed it in Staffbase. For users, it looks like part of the platform. Admins add plugins the same way they add standard ones.

When to use: When you have an existing web app you want to make available in Staffbase quickly. Or when you need a full application (with its own navigation, own state) – not just a content block.

Effort: Low to medium. The web app needs external hosting – which means your own infrastructure to manage. The embedding itself is straightforward, but the app needs to exist.

The most common mistake: Teams choose plugins because it seems faster than building a Custom Widget. Six months later, they’re dealing with iframe issues on mobile devices, missing Staffbase context integration, and an external app that needs maintenance. If your use case is a content block on a page (menu, dashboard, feed), use a widget. If it’s a full application with its own navigation (ticket system, booking portal), use a plugin.

3. Staffbase REST APIs

The Staffbase REST APIs provide programmatic access to users, content, groups, and more. You can read, write, modify, and delete data.

When to use: Backend integrations. Syncing user data from your HR system. Auto-publishing content. Exporting reporting and analytics. Anything that should run in the background without a user seeing a UI.

Effort: High. You need backend developers comfortable with REST APIs, authentication, and error handling.

Important to know: The REST API is the data layer. It doesn’t provide a UI. In most projects, the API serves as the data source for Custom Widgets – the widget displays what the API delivers.

4. Microsoft Power Automate Connector

The official Staffbase Connector for Power Automate enables workflow automation without code. Triggers in Staffbase fire actions in other systems and vice versa.

When to use: In M365-heavy organizations already using Power Automate. Typical flows: New employee in HR system → automatic welcome news in Staffbase. Form submitted → ticket created in ServiceNow.

Effort: Very low. No code required, just Power Automate knowledge.

Limits: Power Automate automates processes but doesn’t deliver a UI in Staffbase. You can create and publish content with it, but you can’t display live data on a page. For that, you need a widget.

5. Microsoft 365 Widgets (Built-in)

Staffbase ships ready-made widgets for M365 services: Teams Overview, Sites, Document Library, Viva Communities.

When to use: Standard M365 use cases without customization needs. “Show me my Teams channels” or “Show the latest documents from this SharePoint library.”

Effort: Minimal. Configuration in Staffbase Studio, no code.

Limits: No custom branding, no custom layout, no individual data logic. What Staffbase ships is what you get.

6. SharePoint Integration / News Central

News Central synchronizes Staffbase content bidirectionally with SharePoint and Viva Connections. Communicators control which content appears when and for whom in SharePoint.

When to use: When your organization runs Staffbase and SharePoint in parallel and wants to unify communications.

Effort: Low to medium. Requires the Staffbase 365 package and configuration.

Pitfall: Double administration. When editors maintain content in both Staffbase and SharePoint, inconsistencies pile up fast. News Central only solves this if you define a clear content workflow.

7. ServiceNow Integration

The certified ServiceNow integration brings ITSM directly into the intranet: view ticket status, search the knowledge base, submit self-service requests.

When to use: IT service portals in the intranet. Employees should be able to view and create tickets without switching between Staffbase and ServiceNow.

Effort: Medium. The ServiceNow connection needs configuration; supports ITSM, HRSD, and CSM.

Compared to Custom Widgets: The native integration covers standard cases (ticket list, knowledge search). As soon as you need a custom UI or additional data fields, a Custom Widget is required.

8. RSS Feed Integration

RSS feeds in Staffbase display external content automatically in Article or Updates channels.

When to use: Industry news, press releases, external blogs – anything already available as an RSS feed.

Effort: Minimal. Enter the feed URL, done.

Limits: Read-only, no custom branding, no interactivity. RSS shows title, text, and link. For anything beyond that (filtering, categorizing, custom layout), you need a Custom Widget.

9. Integrated Content Plugin

The Integrated Content Plugin embeds external websites so they appear in the look and feel of the Staffbase app.

When to use: Quick embedding of external tools (room booking system, form tool) when a native look is desired.

Effort: Minimal. Enter URL, configure.

Limits: The external website must allow iframe embedding (X-Frame-Options). Many modern web applications block this for security reasons.

10. Embedded Pages Widget

The Embedded Pages Widget embeds Staffbase pages into other pages. Useful for content reuse (same block on multiple pages), but limited to internal content – no external data, no third-party systems.

Structured links as lists or tiles – the simplest form of “integration.” Good for quick access to enterprise tools, but purely navigational: no data flow, no live information. Users leave Staffbase on click.

12. SSO Integration (SAML/OIDC)

Single Sign-On via SAML 2.0 or OpenID Connect with common identity providers: Entra ID (Azure AD), Okta, ADFS, Ping Identity.

When to use: Always. SSO is not an optional integration – it’s a prerequisite for enterprise deployment. Without SSO, employees won’t log in.

Effort: Medium. IdP configuration, attribute mapping, session management.

Common pitfall: SAML attributes don’t match expected Staffbase fields. This leads to missing profile pictures, wrong department assignments, or failed logins. Test attribute mapping with a pilot group before go-live.

13. SCIM User Provisioning

SCIM 2.0 automatically synchronizes user data between your identity provider and Staffbase. Onboarding, offboarding, and attribute changes happen without manual intervention.

When to use: Once you hit around 500 users, or when employees join and leave regularly. Without SCIM, someone maintains the user list manually – that doesn’t scale.

Effort: Medium. Configure SCIM endpoint, define mapping, run test sync.

How it works with SSO: SSO handles authentication (who gets in), SCIM handles provisioning (who exists). Both together create proper user management.

14. Webhooks / Event-Based Integration

Staffbase can send events to external systems via Power Automate or direct API calls: new post published, user created, group changed.

When to use: When external systems should react to Staffbase events. Example: New blog post → automatic post in Teams channel. New employee in Staffbase → onboarding workflow in HR system.

Effort: Medium. Requires middleware or Power Automate.

Limitation: Push-only. Staffbase sends events but doesn’t receive webhooks from outside. For the reverse direction, use the REST API.

Comparison Table: All 14 Methods at a Glance

IntegrationEffortFlexibilityTarget GroupLive DataMobileTypical Use Case
Custom WidgetsMedium★★★★★Developers / Low-CodeYesYesDashboards, feeds, dynamic content
Custom PluginsMedium★★★☆☆DevelopersLimitedLimitedEmbed existing web apps
REST APIsHigh★★★★★Backend developersYesData sync, automation
Power AutomateVery low★★☆☆☆IT admins, power usersConditionalWorkflow automation
M365 WidgetsMinimal★☆☆☆☆AdminsYesYesShow Teams, SharePoint, OneDrive
SharePoint / News CentralLow★★☆☆☆CommunicationsYesYesContent sync across platforms
ServiceNowMedium★★★☆☆IT teamsYesYesTickets, knowledge base
RSS FeedMinimal★☆☆☆☆EditorsYesYesExternal news
Integrated ContentMinimal★★☆☆☆AdminsConditionalYesEmbed external tools
Embedded PagesMinimal★☆☆☆☆EditorsYesReuse content
Link WidgetsMinimal★☆☆☆☆EditorsYesNavigation, quick links
SSO (SAML/OIDC)Medium★★★☆☆IT architectsYesAuthentication (mandatory)
SCIMMedium★★★☆☆IT / HRUser sync (from ~500 users)
WebhooksMedium★★★★☆Backend developersPushEvent-based automation

Which Staffbase Integration Fits My Use Case?

Instead of a theoretical decision tree, three practical scenarios:

“We don’t have a development team”

Your toolkit: RSS feeds, link widgets, M365 widgets, Integrated Content Plugin, Power Automate. You can get further with these than most people think. For cafeteria menus, shift schedules, or data from third-party systems, you’ll need Custom Widgets – and that’s exactly where Widget Builder comes in: create Custom Widgets without programming, maintained by the editorial team.

“We’re an M365 organization”

Start with the native M365 widgets and SharePoint/News Central. Add Power Automate for workflow automation. Once the native widgets aren’t enough (custom layout, data from non-Microsoft systems), extend with Custom Widgets. Widget Builder integrates directly with Microsoft 365 and SharePoint.

“We have developers and want to do it right”

Foundation: SSO + SCIM for proper user management. On top of that, Custom Widgets for the UI and REST API for backend integrations. Webhooks for event-based processes. This is the stack we see most often at enterprise customers. Even with your own development team, Widget Builder pays off for standard widgets – so your developers can focus on the complex cases.

What Experienced Staffbase Teams Do Differently

From dozens of Staffbase projects, we see a clear pattern: successful teams don’t choose one integration method – they combine three to four.

The typical enterprise stack:

  • SSO + SCIM (mandatory)
  • 3–5 Custom Widgets (core application)
  • Power Automate (automation)
  • 1–2 native M365 Widgets (basic functions)

The typical mid-market stack:

  • SSO (mandatory)
  • 1–3 Custom Widgets via Widget Builder
  • RSS for external news
  • Link widgets for tool navigation

The decisive difference: successful teams start with what shows immediate impact (usually one or two Custom Widgets solving a concrete everyday problem), then expand step by step. Projects that struggle tend to try integrating everything at once.

Common Mistakes – and How to Avoid Them

SSO without SCIM: Setting up Single Sign-On but leaving user management manual. Works for 50 users. At 500, someone maintains user lists full-time. Set up SCIM from the start.

Plugin instead of Widget: An iframe-based solution for a simple content block. Six months later: mobile issues, no access to Staffbase context, an external app someone needs to host and maintain. Rule of thumb: if it’s a content block, it’s a widget.

Wrong expectations for RSS: RSS shows title and text. No audience targeting, no custom layout, no interaction. If you want more, you need a Custom Widget.

Power Automate as a UI solution: Power Automate automates workflows in the background. It doesn’t display live data on a Staffbase page. For that, you need a widget.

Frequently Asked Questions

Which integration method works without developers?

No-code options: RSS feeds, link widgets, M365 widgets, and the Integrated Content Plugin require no coding. For Custom Widgets with live data connections, use Widget Builder – built specifically for teams without developer capacity.

Custom Widget or Custom Plugin – when do I use which?

Widget = content block on a page (menu, dashboard, feed). Plugin = standalone application with its own navigation (ticket system, booking portal). When in doubt: widget.

Do I need SSO and SCIM?

SSO: Yes, without exception. SCIM: Strongly recommended from around 500 users. Below that, manual user maintenance is manageable; above that, it becomes a full-time job.

Can Widget Builder replace the REST API?

No. Widget Builder creates Custom Widgets (frontend). The REST API is backend integration. In many projects, both are combined: Widget Builder for the widget, the API as the data source.

What does Custom Widget development cost?

Without Widget Builder: weeks of developer time, depending on complexity. With Widget Builder: hours to a few days, because the infrastructure (hosting, SDK integration, build pipeline) is already in place.

More questions? Check our FAQ.

Conclusion

Fourteen options look daunting on paper. Real-world Staffbase environments usually run three to five of them. SSO and SCIM are mandatory. One to three Custom Widgets solve the most important everyday problems. Everything else you add as needed.

The fastest path to a tangible result: a Custom Widget that solves a concrete problem. The cafeteria menu currently distributed as a PDF. The shift schedule currently pinned to a bulletin board. The transit departures someone googles every day.

That’s exactly what we built Widget Builder for.

Next Steps


Related articles: