Warum Stammdaten in Microsoft 365 replizieren?

Vom Formular über Genehmigungsworkflows bis zur Fachanwendung – SharePoint Online bietet die Integrationsplattform, aber nur, wenn die richtigen Daten dort auch verfügbar sind. In der Praxis liegen Stammdaten von Kunden, Projekten, Aufträgen oder Verantwortlichkeiten in Vorsystemen: ERP, CRM, Fibu oder Projektmanagement-Tools.

Ohne saubere Anbindung dieser Systeme endet das schnell in Excel-Exporten, mehrfacher Datenpflege und insgesamt inkonsistenten Informationen in Microsoft 365.

Professionelle Schnittstellen und Datenreplikation lösen genau das: Sie holen Daten aus dem Vorsystem strukturiert ab, transformieren sie nachvollziehbar und schreiben sie in Dataverse-Tabellen oder SharePoint-Listen – damit du in M365 direkt weiterarbeiten kannst:

in SPFx-Webparts für Zeiterfassung, Antragsportale oder komplette Fachanwendungen auf SharePoint-Seiten
in SharePoint-Listen für Asset-, Aufgaben- oder Status-Tracking
in Dokumentenbibliotheken, um Verträge, Belege und andere Dateien sauber Kunden oder Lieferanten zuzuordnen
in Power Automate-Flows und Genehmigungsprozessen

Kurz-Antwort

Daten aus Vorsystemen (ERP, CRM, Fibu, Projektmanagement) gehören nicht manuell in Microsoft 365 kopiert, sondern per Schnittstelle strukturiert nach Dataverse oder SharePoint-Listen synchronisiert. Das Vorsystem bleibt die Single Source of Truth; M365 hält die aktuelle Kopie für SPFx-Webparts, Lookups und Automatisierung. Der eigentliche Abgleich läuft serverseitig über Azure Functions – Vorsystem-API-Keys bleiben in Azure, nicht im SPFx-Quellcode.

Referenz: Vorsystem nach Microsoft 365

Ein bewährtes Muster – unabhängig davon, ob Lexware, SAP oder ein anderes System die Quelle ist:

Vorsystem-API (REST, OData, Export) liefert die Stammdaten
Integrations-Runtime (meist Azure Functions oder Logic Apps) übernimmt Abruf, Transformation und Fehlerbehandlung
Ziel in M365 – Dataverse und/oder SharePoint-Listen speichern das Replikat
Nutzung – SPFx, Power Automate, Power Apps oder Berichte arbeiten mit den M365-Daten
Betrieb – Monitoring, dokumentiertes Mapping, klare Master-Regeln

Das Vorsystem bleibt in der Regel Master; Microsoft 365 hält ein aktuelles, konsistentes Replikat für Anwender und Automatisierung.

Praxisbeispiel: Zeiterfassung in SharePoint mit Kunden aus Lexware Office

Ein konkretes Entwicklungsprojekt zeigt, wie das Muster in der Praxis aussieht – hier mit Dataverse als Ziel, weil Zeiteinträge, Lookups und HR-Rollen sauber zusammenspielen müssen.

Ausgangslage

Mitarbeitende buchen Arbeitszeit in einem SPFx-Webpart. Die erfassten Tätigkeiten sollen für spätere Auftrags- oder Projektabrechnungen mit Kundenzuordnung gebucht werden – die Kundenstammdaten werden aber in Lexware Office gepflegt, nicht manuell in Dataverse.

SPFx-Zeiterfassungswebpart auf SharePoint mit Kundenzuordnung aus Dataverse — SPFx-Zeiterfassung auf SharePoint: Arbeitstypen, Tätigkeitsbeschreibungen und Kundenzuordnung aus synchronisierten Lexware-Stammdaten. Für die Demo wurden die Kundennamen anonymisiert.

Die Lösung: Kunden per REST API aus Lexware lesen, in eine Dataverse-Zuordnungstabelle spiegeln und im Webpart als Dropdown nutzen.

Kurz-Antwort (Lexware-Beispiel)

Im Lexware-Office-Beispiel liest eine Azure Function Kunden per REST (`/v1/contacts`) aus Lexware und schreibt sie per Upsert in die Dataverse-Tabelle pa365hr_zuordnung (externe Lexware-ID als Schlüssel). Das SPFx-Zeiterfassungswebpart auf SharePoint nutzt diese Stammdaten als Kunden-Dropdown – ohne Lexware-Zugangsdaten im Browser. HR kann den Sync per Button „Kunden aus Lexware“ anstoßen.

Ablauf in vier Schritten

Lexware Office (Vorsystem) liefert Kunden/Kontakte per REST API
Azure Function (serverseitig, mit Application User) synchronisiert per Upsert nach Dataverse
Dataverse-Tabelle pa365hr_zuordnung stellt Lookups für Zeiteinträge bereit
SPFx-Zeiterfassungswebpart liest die Zuordnungen und speichert die gewählte Kundenzuordnung am Zeiteintrag

Damit bleiben Lexware-Zugangsdaten aus dem SPFx-Quellcode. Das Webpart arbeitet gegen Dataverse und löst den Import per Azure Function an (Function-Key in der Property Pane, nicht im Repository).

Technische Umsetzung

Lexware: Kontakte per REST auslesen

Lexware Office stellt Kunden über den Contacts Endpoint bereit, z. B.:

GET /v1/contacts?customer=true&vendor=false&page={n}

Der Import läuft seitenweise, damit auch größere Kundenbestände stabil verarbeitet werden (inkl. Beachtung von API-Limits).

Sync über Azure Function

Das Webpart ruft eine Azure Function in der gleichen Function App wie andere HR-Berechnungen auf:

POST /api/lexware/kunden/sync?code=<FUNCTION_KEY>

Ein leerer Body {} genügt – die Function liest Lexware und schreibt nach Dataverse.

Dataverse: Zuordnungstabelle als Ziel

Die synchronisierten Kunden landen in pa365hr_zuordnung:

Lexware ist das führende System für Kundenstammdaten
pa365hr_externeid referenziert die Lexware-Contact-id
pa365hr_name aus Firmen- oder Personenname
Archivierte Lexware-Kontakte werden in Dataverse deaktiviert (statecode = Inaktiv)

Im Web-API-Code wird typischerweise das Entity Set pa365hr_zuordnungs angesprochen; die Tabelle heißt pa365hr_zuordnung.

Dataverse-Struktur mit Zuordnungstabelle für Lexware-Kundendaten in Microsoft 365 — Dataverse-Struktur: Zuordnungstabelle als Ziel für Stammdaten aus Lexware – Grundlage für Lookups in der Zeiterfassung.

Synchronisierte Lexware-Kunden in der Dataverse-Zuordnungstabelle — Replizierte Kundendatensätze aus Lexware in Dataverse – bereit für SPFx und Prozesse in Microsoft 365.

Planung: Checkliste für M365-Integrationsprojekte

Bevor du mit der Umsetzung startest, lohnt sich ein kurzer Abgleich entlang der Architektur:

Stammdaten und Mapping

möglichst identische Tabellen- und Feldnamen zwischen Vorsystem und M365
Pflichtfelder prüfen
klare Entscheidung: welches System ist Master für welche Entität

Sync und Konsistenz

Einweg-Sync (empfohlen für Stammdaten) vs. bidirektionale Pflege
Umgang mit Archivierung/Löschung im Vorsystem
Aktualität: nächtlicher Job vs. manueller Button vs. eventgetrieben
Sync-Modus: Full-Sync oder Delta

Security und Governance

Entra ID / Application User statt persönlicher Admin-Konten
Least Privilege auf Tabellen und Listen
nachvollziehbares Logging ohne personenbezogene Daten im Klartext

Betrieb in der M365-Landschaft

Für den laufenden Betrieb – am Lexware-Beispiel messbar, aber generell übertragbar:

Application User in Dataverse mit gezielten Rechten auf die Zieltabellen
Lexware API Key nur in den App Settings der Function App – nicht im SPFx-Quellcode und nicht für Endanwender sichtbar
Azure Function Key (Host-Key) in der SPFx-Property Pane je Webpart/Site hinterlegen – zur Laufzeit für Sync-Aufrufe, typischerweise nicht im Git-Repository
App-Registrierung, EasyAuth & CORS als Security Layer vor dem Function Code
Rate Limits der Vorsystem-API einplanen (Throttling, Retries)

Mein Entwicklungs-Setup

Für Auftragsentwicklungen verwende ich die folgenden Komponenten:

Git und GitHub für die Quellcodeverwaltung, auf Wunsch geteilt für vollen Entwicklerzugriff
Cursor AI – KI- bzw. agentengestützte Softwareentwicklung
VS Code und Extensions für Projekt-Erstellung, Konfiguration und Deployments (SPFx Toolkit, Dataverse Tools, Power Platform)

Fazit

Schnittstellen in Microsoft-365-Projekten sind kein Selbstzweck. Sie schaffen die Datenbasis in Dataverse oder SharePoint, auf der SPFx-Webparts, Workflows und Fachprozesse wirklich tragen.

Wenn Vorsysteme sauber angebunden sind, müssen Anwender nicht zwischen Lexware, ERP, CRM und manueller Listenpflege wechseln – sie arbeiten direkt in SharePoint und M365 mit aktuellen Stammdaten.

Dein Vorsystem soll in Microsoft 365 ankommen?

Egal ob Du Dein Entwicklungsprojekt komplett extern vergeben möchtest oder einen Sparringspartner für Dein Vorhaben suchst: Nutze das Kontaktformular für ein unverbindliches Erstgespräch!