Staffbase Integrationen: Alle 14 Methoden im Vergleich

Staffbase steht, die App ist ausgerollt – und jetzt fragt der Fachbereich, ob man nicht „mal eben" den Kantinen-Speiseplan einbinden kann. Die ehrliche Antwort: Ja, kann man. Aber es gibt 14 verschiedene Wege dahin, und der falsche kostet dich Monate.

Dieser Artikel zeigt alle 14 Integrationsmöglichkeiten mit einer Vergleichstabelle am Ende.

Keine Lust zu lesen? Unser Integration Finder führt dich in 3 Schritten zur passenden Methode für dein Setup.

Bevor du weiterliest: Drei Fragen, die alles klären

Die meisten Integrationsprojekte scheitern nicht an der Technik. Sie scheitern daran, dass der falsche Weg gewählt wurde. Bevor du in die Details einsteigst, beantworte drei Fragen:

1. Wer setzt es um? Redakteure ohne technischen Hintergrund? IT-Admins mit Grundkenntnissen? Oder ein Entwicklerteam?
2. Was sollen Mitarbeitende sehen? Statische Links? Live-Daten aus Drittsystemen? Interaktive Elemente?
3. Wie schnell muss es gehen? Diese Woche? Diesen Monat? Oder ist es ein strategisches Projekt?

Die Antworten führen dich direkt zur richtigen Kategorie in der Vergleichstabelle weiter unten.

Welche Staffbase-Integrationen gibt es?

1. Custom Widgets (Web Components)

Custom Widgets sind eigenständige UI-Komponenten, die direkt in Staffbase-News und -Pages eingebettet werden. Sie basieren auf dem Web Components-Standard und kommunizieren über das Staffbase Widget SDK mit der Plattform.

Das bedeutet in der Praxis: Ein Custom Widget verhält sich für Redakteure wie ein Standard-Staffbase-Widget. Es taucht im Widget-Picker auf, lässt sich per Drag & Drop platzieren und konfigurieren. Unter der Haube kann es beliebige Daten anzeigen – von Kantinenmenüs über Schichtpläne bis hin zu SAP-Daten.

Wann sinnvoll: Wenn du Live-Daten aus Drittsystemen anzeigen willst und Wert auf ein natives Staffbase-Erlebnis legst. Typische Einsatzgebiete: Speisepläne, ÖPNV-Abfahrten, KPI-Dashboards, Mitarbeiterverzeichnisse.

Aufwand: Mittel. Staffbase stellt einen Widget-Generator bereit, der das Grundgerüst erstellt. Die eigentliche Logik (Datenanbindung, UI) erfordert Webentwicklungs-Know-how – oder ein Low-Code-Tool wie den Widget Builder, das den Entwicklungsaufwand auf Stunden reduziert.

Einschränkung: Custom Widgets sind nur in News und Pages verfügbar, nicht im Public-Bereich der App.

2. Custom Plugins (iframe-basiert)

Custom Plugins sind eigenständige Web-Applikationen, die per iframe in Staffbase eingebettet werden. Das Plugins Client SDK stellt eine JavaScript-Bridge bereit, über die das Plugin mit der Staffbase-Plattform kommuniziert.

Das bedeutet in der Praxis: Du entwickelst eine normale Webanwendung und bettest sie in Staffbase ein. Für den Nutzer sieht es aus wie ein Teil der Plattform. Admins fügen Plugins genauso hinzu wie Standard-Plugins.

Wann sinnvoll: Wenn du eine bestehende Web-App hast, die du schnell in Staffbase verfügbar machen willst. Oder wenn du eine vollständige Anwendung brauchst (mit eigener Navigation, eigenem State) – nicht nur einen Content-Block.

Aufwand: Niedrig bis mittel. Die Web-App muss extern gehostet werden, was eigene Infrastruktur voraussetzt. Für die reine Einbettung reicht wenig Aufwand, aber die App selbst muss natürlich existieren.

Die häufigste Fehlentscheidung: Teams greifen zu Plugins, weil es schneller wirkt als ein Custom Widget. Sechs Monate später kämpfen sie mit iframe-Problemen auf Mobilgeräten, fehlender Staffbase-Kontext-Integration und einer externen App, die gewartet werden muss. Wenn dein Use Case ein Content-Block auf einer Seite ist (Speiseplan, Dashboard, Feed), nimm ein Widget. Wenn es eine vollständige Anwendung mit eigener Navigation ist (Ticketsystem, Buchungsportal), nimm ein Plugin.

3. Staffbase REST APIs

Die Staffbase REST APIs bieten programmatischen Zugriff auf Nutzer, Inhalte, Gruppen und mehr. Du kannst Daten lesen, schreiben, ändern und löschen.

Wann sinnvoll: Backend-Integrationen. Nutzerdaten aus dem HR-System synchronisieren. Inhalte automatisch publizieren. Reporting und Analytics exportieren. Alles, was im Hintergrund laufen soll, ohne dass ein Nutzer eine UI sieht.

Aufwand: Hoch. Du brauchst Backend-Entwickler, die mit REST APIs, Authentifizierung und Fehlerbehandlung vertraut sind.

Wichtig zu wissen: Die REST API ist die Daten-Ebene. Sie liefert kein UI. In den meisten Projekten wird die API als Datenquelle für Custom Widgets genutzt – das Widget zeigt an, was die API liefert.

4. Microsoft Power Automate Connector

Der offizielle Staffbase-Connector für Power Automate ermöglicht Workflow-Automatisierung ohne Code. Trigger in Staffbase lösen Aktionen in anderen Systemen aus und umgekehrt.

Wann sinnvoll: In M365-lastigen Unternehmen, die bereits Power Automate nutzen. Typische Flows: Neuer Mitarbeiter im HR-System → automatisch Willkommens-News in Staffbase. Formular ausgefüllt → Ticket in ServiceNow erstellt.

Aufwand: Sehr niedrig. Kein Code nötig, nur Power Automate-Kenntnisse.

Grenzen: Power Automate automatisiert Prozesse, liefert aber kein UI in Staffbase. Du kannst damit Inhalte erstellen und publizieren, aber keine Live-Daten auf einer Seite anzeigen. Dafür brauchst du ein Widget.

5. Microsoft 365 Widgets (Built-in)

Staffbase liefert fertige Widgets für M365-Dienste mit: Teams Overview, Sites, Document Library, Viva Communities.

Wann sinnvoll: Standard-M365-Use Cases ohne Customizing-Bedarf. „Zeig mir meine Teams-Kanäle" oder „Zeig die neuesten Dokumente aus dieser SharePoint-Library".

Aufwand: Minimal. Konfiguration im Staffbase Studio, kein Code.

Grenzen: Kein eigenes Branding, kein Custom-Layout, keine individuelle Datenlogik. Was Staffbase liefert, ist was du bekommst.

6. SharePoint Integration / News Central

News Central synchronisiert Staffbase-Inhalte bidirektional mit SharePoint und Viva Connections. Kommunikatoren steuern, welche Inhalte wann für wen in SharePoint erscheinen.

Wann sinnvoll: Wenn dein Unternehmen parallel Staffbase und SharePoint betreibt und die Kommunikation vereinheitlichen will.

Aufwand: Niedrig bis mittel. Erfordert Staffbase 365-Paket und Konfiguration.

Stolperfalle: Doppelte Administration. Wenn Redakteure Inhalte sowohl in Staffbase als auch in SharePoint pflegen, wird es schnell inkonsistent. News Central löst das nur, wenn du einen klaren Content-Workflow definierst.

7. ServiceNow Integration

Die zertifizierte ServiceNow-Integration bringt ITSM direkt ins Intranet: Ticketstatus anzeigen, Knowledge-Base durchsuchen, Self-Service-Anfragen starten.

Wann sinnvoll: IT-Service-Portale im Intranet. Mitarbeitende sollen Tickets sehen und erstellen können, ohne zwischen Staffbase und ServiceNow zu wechseln.

Aufwand: Mittel. ServiceNow-Verbindung muss konfiguriert werden, unterstützt ITSM, HRSD und CSM.

Abgrenzung zu Custom Widgets: Die native Integration deckt Standard-Fälle ab (Ticketliste, Knowledge Search). Sobald du ein individuelles UI oder zusätzliche Datenfelder brauchst, wird ein Custom Widget nötig.

8. RSS-Feed-Integration

RSS-Feeds in Staffbase zeigen externe Inhalte automatisch in Article- oder Updates-Channels an.

Wann sinnvoll: Branchennews, Pressemitteilungen, externe Blogs – alles, was bereits als RSS-Feed vorliegt.

Aufwand: Minimal. Feed-URL eintragen, fertig.

Grenzen: Read-only, kein eigenes Branding, keine Interaktivität. RSS zeigt Titel, Text und Link. Für alles, was darüber hinausgeht (Filtern, Kategorisieren, individuelles Layout), brauchst du ein Custom Widget.

9. Integrated Content Plugin

Das Integrated Content Plugin bettet externe Websites so ein, dass sie im Look & Feel der Staffbase-App erscheinen.

Wann sinnvoll: Schnelle Einbindung externer Tools (Raumbuchungssystem, Formular-Tool), wenn ein nativer Look gewünscht ist.

Aufwand: Minimal. URL eintragen, konfigurieren.

Grenzen: Die externe Website muss iframe-Einbettung erlauben (X-Frame-Options). Viele moderne Webanwendungen blockieren das aus Sicherheitsgründen.

10. Embedded Pages Widget

Das Embedded Pages Widget bettet Staffbase-eigene Pages in andere Pages ein. Sinnvoll für Content-Wiederverwendung (gleicher Block auf mehreren Seiten), aber beschränkt auf internen Content – keine externen Daten, keine Drittsysteme.

11. Link-Widgets (Link List / Link Tiles)

Strukturierte Verlinkungen als Liste oder Kacheln – die einfachste Form der „Integration". Gut für Schnellzugriffe auf Unternehmenstools, aber rein navigational: kein Datenfluss, keine Live-Informationen. Der Nutzer verlässt Staffbase beim Klick.

12. SSO-Integration (SAML/OIDC)

Single Sign-On über SAML 2.0 oder OpenID Connect mit gängigen Identity Providern: Entra ID (Azure AD), Okta, ADFS, Ping Identity.

Wann sinnvoll: Immer. SSO ist keine optionale Integration, sondern Voraussetzung für den Enterprise-Einsatz. Ohne SSO loggen sich Mitarbeitende nicht ein.

Aufwand: Mittel. IdP-Konfiguration, Attribute Mapping, Session-Management.

Typischer Stolperstein: SAML-Attribute stimmen nicht mit den erwarteten Staffbase-Feldern überein. Das führt zu fehlenden Profilbildern, falschen Abteilungszuordnungen oder fehlgeschlagenen Logins. Prüfe das Attribute Mapping vor dem Go-Live mit einer Testgruppe.

13. SCIM User Provisioning

SCIM 2.0 synchronisiert Nutzerdaten automatisch zwischen Identity Provider und Staffbase. Onboarding, Offboarding und Attribut-Änderungen laufen ohne manuellen Eingriff.

Wann sinnvoll: Ab circa 500 Nutzern oder wenn regelmäßig Mitarbeitende ein- und austreten. Ohne SCIM pflegt jemand die Nutzerliste manuell – das skaliert nicht.

Aufwand: Mittel. SCIM-Endpunkt konfigurieren, Mapping definieren, Test-Sync durchführen.

Zusammenspiel mit SSO: SSO regelt die Authentifizierung (wer darf rein), SCIM regelt die Provisionierung (wer existiert). Beides zusammen ergibt erst eine saubere Nutzerverwaltung.

14. Webhooks / Event-basierte Integration

Staffbase kann über Power Automate oder direkte API-Calls Events an externe Systeme senden: Neuer Beitrag veröffentlicht, Nutzer erstellt, Gruppe geändert.

Wann sinnvoll: Wenn externe Systeme auf Staffbase-Events reagieren sollen. Beispiel: Neuer Blogartikel → automatischer Post im Teams-Kanal. Neuer Mitarbeiter in Staffbase → Onboarding-Workflow im HR-System.

Aufwand: Mittel. Erfordert Middleware oder Power Automate.

Einschränkung: Push-only. Staffbase sendet Events, empfängt aber keine Webhooks von außen. Für den umgekehrten Weg nutze die REST API.

Vergleichstabelle: Alle 14 Methoden auf einen Blick

Welche Staffbase-Integration passt zu meinem Use Case?

Statt eines theoretischen Entscheidungsbaums drei praxisnahe Szenarien:

„Wir haben kein Entwicklerteam"

Dein Werkzeugkasten: RSS-Feeds, Link-Widgets, M365 Widgets, Integrated Content Plugin, Power Automate. Damit kommst du weiter, als die meisten denken. Für Kantinenmenüs, Schichtpläne oder Daten aus Drittsystemen brauchst du allerdings Custom Widgets – und genau hier setzt der Widget Builder an: Custom Widgets ohne Programmierung erstellen, vom Redaktionsteam selbst pflegen.

„Wir sind ein M365-Unternehmen"

Starte mit den nativen M365 Widgets und SharePoint/News Central. Ergänze Power Automate für Workflow-Automatisierung. Sobald die nativen Widgets nicht mehr reichen (individuelles Layout, Daten aus Nicht-Microsoft-Systemen), erweitere mit Custom Widgets. Der Widget Builder integriert direkt mit Microsoft 365 und SharePoint.

„Wir haben Entwickler und wollen es richtig machen"

Basis: SSO + SCIM für saubere Nutzerverwaltung. Darauf aufbauend Custom Widgets für die UI und REST API für Backend-Integrationen. Webhooks für Event-basierte Prozesse. Das ist der Stack, den wir bei Enterprise-Kunden am häufigsten sehen. Selbst mit eigenem Entwicklerteam lohnt sich der Widget Builder für Standard-Widgets – damit sich die Entwickler auf die komplexen Fälle konzentrieren können.

Was erfahrene Staffbase-Teams anders machen

Aus dutzenden Staffbase-Projekten sehen wir ein klares Muster: Erfolgreiche Teams wählen nicht eine Integrationsmethode, sondern kombinieren drei bis vier.

Der typische Enterprise-Stack:

• SSO + SCIM (Pflicht)
• 3–5 Custom Widgets (Kernanwendung)
• Power Automate (Automatisierung)
• 1–2 Native M365 Widgets (Basisfunktionen)

Der typische Mittelstands-Stack:

• SSO (Pflicht)
• 1–3 Custom Widgets via Widget Builder
• RSS für externe News
• Link-Widgets für Tool-Navigation

Der entscheidende Unterschied: Erfolgreiche Teams starten mit dem, was sofort Wirkung zeigt (meistens ein bis zwei Custom Widgets, die ein konkretes Alltagsproblem lösen), und ergänzen schrittweise. Gescheiterte Projekte versuchen, alles gleichzeitig zu integrieren.

Häufige Fehler – und wie du sie vermeidest

SSO ohne SCIM: Single Sign-On einrichten, aber die Nutzerverwaltung manuell lassen. Funktioniert bei 50 Nutzern. Bei 500 pflegt jemand Vollzeit Nutzerlisten. Richte SCIM von Anfang an ein.

Plugin statt Widget: Eine iframe-basierte Lösung für einen simplen Content-Block. Sechs Monate später: Probleme auf Mobilgeräten, kein Zugriff auf Staffbase-Kontext, eine externe App, die jemand hosten und warten muss. Faustregel: Wenn es ein Content-Block ist, ist es ein Widget.

Falsche Erwartungen an RSS: RSS zeigt Titel und Text. Kein Filtern nach Zielgruppe, kein Custom-Layout, keine Interaktion. Wenn du mehr willst, brauchst du ein Custom Widget.

Power Automate als UI-Lösung: Power Automate automatisiert Workflows im Hintergrund. Es zeigt keine Live-Daten auf einer Staffbase-Seite an. Dafür brauchst du ein Widget.

Häufige Fragen

Welche Integrationsmethode funktioniert ohne Entwickler?

RSS-Feeds, Link-Widgets, M365 Widgets und das Integrated Content Plugin kommen ohne Code aus. Für Custom Widgets mit Datenanbindung nutze den Widget Builder – das ist explizit für Teams ohne Entwickler-Kapazität gebaut.

Custom Widget oder Custom Plugin – wann nehme ich was?

Widget = Content-Block in einer Seite (Speiseplan, Dashboard, Feed). Plugin = eigenständige Anwendung mit eigener Navigation (Ticketsystem, Buchungsportal). Im Zweifel: Widget.

Brauche ich SSO und SCIM?

SSO: Ja, ausnahmslos. SCIM: Ab circa 500 Nutzern dringend empfohlen. Darunter ist manuelle Nutzerpflege zumutbar, darüber wird es zum Fulltime-Job.

Kann der Widget Builder die REST API ersetzen?

Nein. Der Widget Builder erstellt Custom Widgets (Frontend). Die REST API ist Backend-Integration. In vielen Projekten werden beide kombiniert: der Widget Builder für das Widget, die API als Datenquelle.

Was kostet eine Custom-Widget-Entwicklung?

Ohne Widget Builder: Wochen an Entwicklerzeit, je nach Komplexität. Mit Widget Builder: Stunden bis wenige Tage, weil die Infrastruktur (Hosting, SDK-Integration, Build-Pipeline) bereits steht.

Weitere Fragen beantworten wir in unserer FAQ.

Fazit

14 Integrationswege klingt nach Komplexität. In der Praxis nutzen die meisten Unternehmen drei bis fünf davon. SSO und SCIM sind Pflicht. Ein bis drei Custom Widgets lösen die wichtigsten Alltagsprobleme. Alles andere ergänzt du nach Bedarf.

Der schnellste Weg zu einem spürbaren Ergebnis: Ein Custom Widget, das ein konkretes Problem löst. Den Kantinen-Speiseplan, der bisher per PDF verschickt wird. Die Schichtzeiten, die bisher auf einer Pinnwand hängen. Die ÖPNV-Abfahrten, nach denen jeden Tag jemand googelt.

Genau dafür haben wir den Widget Builder gebaut.

Nächste Schritte

• Widget-Galerie durchstöbern – schau dir an, wie ein Speiseplan-Widget oder KPI-Dashboard in Staffbase aussieht
• Widget Builder Integrationen – über 100 unterstützte Plattformen
• Demo vereinbaren – den Widget Builder live in deiner Staffbase-Umgebung sehen

Verwandte Artikel:

• Staffbase personalisieren mit dem JASP Widget Builder
• Kantine bis KPI: Was verteilte Teams wirklich brauchen
• Mitarbeiter-Engagement steigern: Die Top-Widgets für HR