Microsoft 365 · Erweiterungen & Add-ons
Office 365 und Microsoft 365 sind die Plattform. Was der Standard nicht abdeckt, bauen wir darauf — sauber, supportbar, Release-Wave-fest. Vom SharePoint-Framework-Web-Part über die Teams-App bis zum Outlook-Add-in und Copilot-Agent: arades GmbH entwickelt auf den offiziellen Microsoft-Erweiterungs-Plattformen. 20+ Jahre Praxis. Keine undokumentierten Tricks.
Warum Erweiterungen statt Workarounds
In jedem Mittelständler kommt der Punkt, an dem der Standard von Microsoft 365 nicht mehr reicht: SharePoint-Seiten sehen nicht so aus, wie Sie sie brauchen. Teams soll Daten aus dem CRM zeigen. Outlook soll Ticket-Status anzeigen, ohne dass jemand wechseln muss. Power Automate soll einen Drittanbieter ansprechen, für den es keinen fertigen Connector gibt. Ihre Anwender bauen dann Workarounds — Excel-Listen, separate Tools, geteilte Postfächer. Mit Erweiterungen lösen wir das an der Wurzel.
Sechs Erweiterungs-Typen
Microsoft hat für jeden Anwendungsfall eine dokumentierte Erweiterungs-Plattform. Wir kennen sie alle aus produktivem Einsatz — und sagen ehrlich, welche zu Ihrer Anforderung passt und welche nicht.
Die offizielle Erweiterungs-Plattform für SharePoint Online — mit TypeScript, React und modernem Frontend-Tooling. Wir entwickeln Web Parts für Modern Pages, Header- und Footer-Customizer für Tenant- oder Site-Branding sowie Field- und List-Customizer für strukturierte Datenpräsentation.
Typische Einsatzfälle: Mitarbeiter-Verzeichnis aus Entra ID, KPI-Dashboards mit Power-BI-Embedding, branchen-spezifische Form-Layouts, Marken-konformes Tenant-Branding.
Eigenständige Teams-Apps als Tabs, Bots oder Messaging Extensions. Personalized App Manifests, SSO via Entra ID, Adaptive Cards für strukturierte Inhalte. Multi-Tenant-Veröffentlichung im AppSource oder Tenant-only-Sideloading — beides praxiserprobt.
Typische Einsatzfälle: CRM-Datensätze in Teams-Konversationen, Approval-Workflows, Onboarding-Bot, branchen-spezifische Such-Funktion über mehrere Datenquellen.
Moderne Office-Add-ins über die Office.js-Plattform — laufen plattformübergreifend in Desktop-, Web- und Mobile-Apps. Outlook-Add-ins für Read- und Compose-Modus, Word-Add-ins für Vorlagen- und Content-Generierung, Excel-Add-ins für Custom Functions und domänen-spezifische Analysen.
Typische Einsatzfälle: CRM-Kontakte in Outlook anzeigen, Vertrags-Vorlagen in Word generieren, branchen-spezifische Excel-Custom-Functions für Berechnungen.
Microsoft Graph ist das einheitliche API-Tor zu Mails, Kalendern, Files, Teams-Nachrichten, Users und Devices. Wir bauen Server-Side-Integrationen (Daemon, Background-Worker, ETL) ebenso wie Client-Side-Aufrufe aus Single-Page-Apps. Subscriptions und Webhooks für ereignisbasierte Architekturen.
Typische Einsatzfälle: Externe Systeme an M365-Daten anbinden, Compliance-Auswertungen, Onboarding/Offboarding-Automatik, Reporting über Tenant-Aktivität.
Wenn Power Automate und Power Apps an eine API müssen, für die Microsoft keinen fertigen Connector liefert, bauen wir Custom Connectors auf Basis von OpenAPI/Swagger-Spezifikationen. Inklusive OAuth-Flows, Policy Templates und Multi-Tenant-Auslieferung.
Typische Einsatzfälle: Branchen-ERP, ältere SOAP-Services, eigene Backend-Services, REST-APIs von Logistik-Partnern, Marketplace-Schnittstellen.
Eigene Copilot-Agents über Microsoft Copilot Studio — mit SharePoint-, Teams- und Custom-Knowledge-Sources. Als Standalone-Agent in Microsoft Teams, in Microsoft 365 Copilot Chat oder via Microsoft 365 Copilot Extensions direkt in den produktiven Workflow eingebettet.
Typische Einsatzfälle: Wissens-Agent auf SharePoint-Intranet, HR- und IT-Helpdesk-Agent, branchen-spezifische Such-Assistenten, Onboarding-Begleitung.
Engineering-Prinzipien
Microsoft veröffentlicht zweimal pro Jahr eine Release Wave, dazu monatliche Updates für SharePoint, Teams und Microsoft Graph. Eine Erweiterung, die das nicht aushält, ist nach einem Jahr Schrott. Vier Prinzipien, an die wir uns deshalb halten — auch, wenn es kurzfristig länger dauert.
Keine undokumentierten SharePoint-Endpoints, keine private Teams-Backend-Calls, keine DOM-Manipulation auf Microsoft-Oberflächen. Alles über Microsoft Graph, SPFx, Office.js und Teams JS SDK.
Minimale Berechtigungs-Scope, klare Trennung Delegated vs. Application Permission, Admin-Consent dokumentiert. Im Code keine eingebetteten Tokens — Auth über Entra ID, MSAL, Managed Identities.
Build-Pipelines mit gepinntem Node-Version, SPFx-Generator-Version, Teams-Toolkit-Version. Bundle- und Manifest-Artefakte in Git, jede Veröffentlichung nachvollziehbar.
Im Application-Care-Modell prüfen wir 2× pro Jahr passend zur Release Wave, ob Microsoft-Änderungen Auswirkungen haben — und passen Bundle, Manifest oder Code an, bevor es bricht.
Wie wir liefern
Wenn die Anforderung sauber umgrenzt ist (z. B. „SPFx-Web-Part, das Daten X aus API Y zeigt"), kalkulieren wir Festpreis. Üblicher Rahmen: 2–6 Wochen Lieferzeit, niedriger bis mittlerer vierstelliger Bereich.
Wenn Anforderungen noch entdeckt werden müssen oder das Erweiterungs-Vorhaben Teil einer größeren Implementierung ist, arbeiten wir nach Aufwand mit Sprint-Logik und festen Tagessätzen.
Sie haben bereits SPFx-Web-Parts, Teams-Apps oder Outlook-Add-ins im Einsatz — auch von anderen Häusern. Wir übernehmen Pflege und Weiterentwicklung im Application-Care-Modell, monatlich pauschal.
AppSource oder Tenant-only
Ein Add-on muss nicht zwingend öffentlich sein. Drei Modelle, die wir liefern:
Häufige Fragen
Wir entwickeln auf den offiziellen Microsoft-Erweiterungs-Plattformen: SharePoint Framework (SPFx) für SharePoint-Web-Parts und -Extensions, Teams Apps mit Tabs, Bots und Messaging Extensions, Office-Add-ins über Office.js für Outlook, Word und Excel, Microsoft Graph-basierte Custom-Integrationen, Power Platform Custom Connectors sowie Copilot Studio Agents. Alle Erweiterungen sind Release-Wave-fest und nutzen ausschließlich dokumentierte Microsoft-APIs.
Ein einfaches SPFx-Web-Part oder Teams-Tab liegt im niedrigen vierstelligen Bereich — also als kompaktes Quick-Win-Projekt. Komplexere Add-ons mit eigener Backend-Logik, Microsoft-Graph-Calls und Multi-Tenant-Support bewegen sich im mittleren fünfstelligen Bereich. Eine erste Aufwandsschätzung gibt es im 30-Minuten-Erstgespräch.
Ja — vorausgesetzt, sie nutzen ausschließlich dokumentierte Microsoft-APIs (Microsoft Graph, SPFx, Office.js, Teams JS SDK). Wir vermeiden bewusst undokumentierte Endpoints, DOM-Manipulation und private SharePoint-Page-Routen. Im Anschluss-Care-Modell prüfen wir 2× pro Jahr passend zu den Release Waves von Microsoft, ob Anpassungen nötig sind.
Microsoft Graph ist seit vielen Jahren ein Kern-Toolset bei uns. Wir bauen sowohl Delegated-Permission-Flows (Anwender-Kontext) als auch Application-Permission-Flows (Daemon, Hintergrund-Jobs) — inklusive Change Notifications, Subscriptions, Webhooks und Batch-Requests. Für sensible Szenarien setzen wir Microsoft Entra ID Conditional Access, App Roles und Managed Identities ein.
Eine Teams-App ist eine eigenständige Anwendung in Microsoft Teams (Tabs, Bots, Messaging Extensions). Ein Copilot Agent ist eine in Microsoft 365 Copilot oder Copilot Studio gebaute KI-Schnittstelle, die auf eine Wissensbasis oder API-Quelle zugreift und natürlich-sprachlich antwortet. Beide lassen sich kombinieren: ein Copilot Agent kann als Teams-App ausgerollt werden — und eine Teams-App kann einen Copilot Agent einbetten.
Ja — Übernahme bestehender Lösungen ist häufig der Einstieg. Wir prüfen Code-Qualität, API-Aktualität, Microsoft-Graph-Permissions, Bundle-Größe und Performance. Anschließend übernehmen wir Pflege und Weiterentwicklung im Application-Care-Modell — auch bei Lösungen, die wir nicht selbst gebaut haben.
Ja — sowohl interne Add-ons (Tenant-only) als auch öffentliche Veröffentlichungen im Microsoft AppSource sind möglich. Für die AppSource-Veröffentlichung begleiten wir Sie durch die Microsoft-Zertifizierung — Sicherheits-Review, Performance-Tests, Marketing-Anforderungen und Multi-Tenant-Setup.
Kostenlose Microsoft 365 Test-Begleitung
arades richtet einen Test-Tenant für 3 Benutzer ein, schult die Key-User, begleitet wöchentlich mit einer Sprechstunde — und sagt am Ende ehrlich, ob Microsoft 365 für Sie das richtige ist. Kostenlos.
30 Min Erstgespräch
Wir hören uns die Anforderung an und sagen, welche Microsoft-Erweiterungs-Plattform passt — SPFx, Teams App, Outlook Add-in, Graph, Power Platform Connector oder Copilot Agent. Und ob ein Festpreis sinnvoll ist, oder ob die Anforderung erst geschärft werden muss.
Begleitende Dienstleistungen
Engineering-Projekte stehen selten allein — Lizenz-Logik, Architektur-Klärung, Quality-Gates, Wissens-Transfer und Folge-Betrieb laufen meistens parallel. Hier die häufigsten Begleitleistungen, die wir in Discovery-Spike, Sprint-Festpreis oder Application-Care-Verträgen zubuchen.
Vorab · Architektur
Bevor implementiert wird: Tenant-Struktur, Datenmodell, Sicherheitskonzept, Integration-Mapping. Ergebnis ist ein Architektur-Dokument, mit dem jedes Engineering-Team weiterarbeiten kann — auch ein anderes als wir.
Ansehen →
Vorab · CSP
Welche Lizenz-Bundles für welche User, welche Add-on-SKUs notwendig sind, wo Sie über- oder unterlizenziert sind. Als Microsoft Lizenzierungspartner bezogen — mit der Option, CSP nur als Kontrolle ohne Margenmaximierung zu nutzen.
Ansehen →
Während · Quality-Gate
Unabhängige Zweit-Meinung während eines laufenden Implementations-Projekts — egal ob wir es selbst durchführen oder ein anderer Partner. CMMI-basierte Quality-Gates, Risk-Reviews, Festpreis pro Gate.
Während · Adoption
Nicht der klassische 2-Tage-Workshop, der nach einer Woche vergessen ist — sondern ein dynamisches Lernprogramm über 4–6 Wochen mit Erstschulung, Anwendungsphasen und Aufbau-Sessions. Schulungs-Matrix für Rollen und Themen.
Ansehen →
Danach · Betrieb
Nach Go-Live: planbarer Application-Care-Vertrag mit Monatspauschale, SLA-basiert. Inklusive Releases, Hotfixes, Erweiterungen, Tenant-Hardening — und kontinuierlicher Begleitung statt nur Reaktion auf Ticket.
Ansehen →
Danach · Wissen
Wenn die ursprünglichen Entwickler weg sind, der Vorgänger-Partner nicht mehr greifbar oder die Dokumentation veraltet — Reverse Engineering der bestehenden Lösung mit dokumentiertem Ergebnis: Code-Map, Datenmodell, Customization-Inventar.
Ansehen →
