Vom Projekt in die Roadmap

Keiner von uns hat mit dem Produktstart die Projektarbeit aufgegeben — mit Absicht. Die Wochen in Kundenumgebungen sind unsere Produktforschung: eine Governance-Anforderung, die ein Prüfer in einem Tenant stellt, eine Integration, die schneller Datenmüll schreibt als jeder Nutzer, eine Release-Welle, die still das Plugin-Verhalten ändert. Aus diesen Momenten werden Tickets, aus Tickets Features, und Features bekommen alle.

Diese Schleife ist auch der Grund, warum Support so funktioniert, wie er funktioniert: Wer euer Ticket beantwortet, hat den Code geschrieben — oder sitzt daneben. Zwischen euch und einer Antwort steht kein First-Level-Skript, und kein Feature-Wunsch verschwindet in einem Backlog, das niemand liest. Die Distanz zwischen „ein Kunde ist darauf gestoßen" und „der Fix ist auf AppSource" wird in Tagen gemessen, nicht in Quartalen.

So arbeiten wir

So betreiben wir xRM Products

Software von einem fokussierten Team zu kaufen, sollte sich sicherer anfühlen, nicht riskanter. Hier steht, warum es das tut.

Entwicklung & Releases

Alle drei Apps kommen als Managed Solutions über Microsoft AppSource — jedes Release durchläuft also Microsofts Publisher-Zertifizierung, bevor es euren Tenant erreichen kann. Wir entwickeln gegen dieselben halbjährlichen Release-Wellen, die ihr bekommt, testen auf High-Volume-Tabellen, lange bevor ein Kunde es tut, und behandeln ein Update, das in eurer Umgebung irgendetwas bricht, als unser Versagen — nicht als euer Risiko. Nichts installiert sich außerhalb des Solution-Frameworks, die Deinstallation ist so sauber wie die Installation.

Eure Daten, euer Tenant

Es gibt keine xRM-Cloud. Kein Connector ruft unsere Server, keine Telemetrie-Pipeline trägt eure Datensätze irgendwohin, keine Verarbeitung passiert außerhalb von Microsoft Dataverse. Regeln, Logs, Übersetzungen und Konfiguration sind normale Dataverse-Zeilen — abgedeckt von euren Sicherheitsrollen, euren Backups, eurer Compliance-Grenze. Wenn eure Prüfer fragen, wo die Daten liegen, ist die Antwort ein Wort: Dataverse.

Sicherheit durch Architektur

Die Apps verlassen das Dataverse-Sicherheitsmodell nie — sie erweitern es. Jede Aktion eines Nutzers läuft unter dessen eigenen Sicherheitsrollen, und sensible Fähigkeiten tragen eigene Privilegien: Das Lesen des Audit-Logs und das Wiederherstellen daraus sind getrennte Berechtigungen — Prüfer können sehen, ohne handeln zu können, und Administratoren handeln nur, wo ihre Rolle es erlaubt. Es gibt keine Service-Accounts zum Einrichten, keine gespeicherten Zugangsdaten, keine API-Keys zum Rotieren — die Apps authentifizieren sich, wie Dataverse selbst es tut, weil sie Dataverse sind. Zusammen mit Daten, die den Tenant nie verlassen, bleiben euer bestehendes Security-Review, eure DLP-Richtlinien und eure Data-Residency-Zusagen vollständig intakt: Was euer Compliance-Team für Dynamics 365 freigegeben hat, deckt die xRM-Apps bereits ab.

Falls ihr uns je braucht — und falls nicht

Support-Anfragen landen direkt bei den Foundern und werden innerhalb eines Werktags beantwortet. Das wichtigere Versprechen ist aber das umgekehrte: Die Apps sind so gebaut, dass sie uns nicht brauchen. Die Konfiguration ist dokumentiert und lebt als Daten in eurer Umgebung, Administratoren steuern alles über die Standard-Dynamics-Oberfläche, und eine funktionierende Installation funktioniert weiter — durch Update-Wellen, durch Admin-Wechsel, über Jahre. Abhängigkeit vom Hersteller ist ein Designfehler. Wir haben ihn wegdesignt.

Hinter jedem Release steht ein Team von Dynamics-365-Spezialisten — Entwickler, Berater und Tester, die die Plattform täglich leben. Jedes Feature bauen Menschen, die selbst auf der Kundenseite des Tisches gesessen haben.

Was wir gemeinsam bauen.

Vier Dataverse-native Governance-Apps — drei verfügbar in fünf Sprachen auf Microsoft AppSource, eine unterwegs. Keine externen Dienste, keine Daten, die euren Tenant verlassen.