In Dynamics 365 Sales fehlt oft eine reine „Lese-Rolle“. Um diese effizient zu erstellen, kopieren wir die Standard-Rolle Salesperson (Vertriebsmitarbeiter) als Basis, da diese bereits alle nötigen Hintergrundrechte für die App-Navigation und Anmeldung mitbringt.
Die Umsetzung
Massen-Update: Öffne die kopierte Rolle und wähle eine Tabelle aus, die bereits auf Read: Organization steht. Klicke auf die drei Punkte und wähle Copy Table Permissions und wähle alle Tabellen an.
Ausnahmen abwählen: Bevor du die Änderungen mit Save Changes bestätigst, musst du die Haken bei bestimmten Tabellen unbedingt entfernen, damit keine Systemfehler entstehen:
Saved View
Alle Tabellen, die das Wort „User“ beinhalten (z. B. User Settings, User Dashboard).
Überfliege zur Sicherheit noch einmal alle Berechtigungen, um etwaige Konfigurationsfehler zu erkennen. Nun hast du eine fertige Read-only-Sicherheitsrolle, die einsatzbereit ist.
In Microsoft Dynamics 365 Sales gehört die Erstellung von Angeboten zum Kernprozess. Dabei stößt man in der Praxis häufig auf eine spezifische Hürde: Während Administratoren den Einzelpreis (Price Per Unit) von manuell hinzugefügten Produkten in einer Quote Line jederzeit anpassen können, ist dies für reguläre Benutzer oft gesperrt – selbst wenn diese Schreibrechte auf das Angebot haben.
Das Problem: Fehlende Transparenz in den Tabellen-Berechtigungen
Wer versucht, dieses Verhalten über die Sicherheitsrollen auf Tabellenebene zu lösen, wird schnell feststellen, dass die Quote Line (Angebotsdetail) in der Liste der Tabellen innerhalb der Sicherheitsrollen oft nicht intuitiv zu finden ist oder Anpassungen dort nicht den gewünschten Erfolg bringen. Das Feld bleibt für den User ausgegraut, eine manuelle Preiskorrektur ist unmöglich.
Die Analyse: Admin vs. User
Im Standard-System ist die Hierarchie klar definiert:
Administratoren: Besitzen umfassende Rechte und können Preise überschreiben, um auf individuelle Verhandlungssituationen zu reagieren.
Standard-User: Sind oft an die Preislisten-Logik gebunden, was die Flexibilität im Daily Business einschränken kann.
Die Lösung: Miscellaneous Privileges
Die Lösung liegt nicht in den klassischen Tabellen-Berechtigungen (Create, Read, Write), sondern in den sogenannten Miscellaneous Privileges innerhalb der Sicherheitsrolle.
Um Benutzern das Editieren von Preisen in Angebotszeilen zu ermöglichen, muss folgender Schritt durchgeführt werden:
Navigieren zu den Sicherheitsrollen im Power Platform Admin Center.
Die entsprechende Rolle auswählen und den Reiter Miscellaneous Privileges öffnen.
Im Bereich „Miscellaneous Privileges“ nach „Override Quote Pricing“ suchen und das Privilege Level dementsprechend anpassen.
Fazit
Kleine Ursache, große Wirkung: Die Granularität von Dynamics 365 ermöglicht eine präzise Steuerung, erfordert aber Detailwissen über die versteckten Privilegien jenseits der Standard-CRUD-Matrix. Mit der Anpassung der Miscellaneous Privileges wird die notwendige Flexibilität im Vertriebsprozess wiederhergestellt.
Wenn Sie mit Oracle Integration Cloud arbeiten, stoßen Sie früher oder später auf ein Problem mit API Rate Limits. Die Integration erhält eine riesige Datenkollektion, aber die Ziel-API akzeptiert nur Einzelaufrufe. Oder, noch komplexer, es müssen im Ziel-System verschiedene Einzelschritte gesetzt werden, die Schnittstelle erhält viele Aufrufe in kurzer Zeit. Das ist kein Problem, solange man nicht an ein Request-Limit stößt. Dann antwortet die API gnadenlos mit einem Error und lässt uns erstmal warten.
In diesem Tutorial zeigen wir Ihnen, wie Sie mit etwas Logik und der Wait Activity in wenigen Schritten einen „Chill-Out“ Step für Ihre Integration einbauen.
Das Szenario
Eine Datenbank liefert uns die neuesten Leads per REST-API als JSON-Array
Wir übertragen diese Leads an unser CRM, allerdings erlaubt die REST-API des CRM nur die Anlage eines Datensatzes pro Aufruf
Wir setzen eine ForEach-Schleife ein und arbeiten die einzelnen Leads geordnet ab
Das CRM hat ein API-Limit von 100 Aufrufen pro 5 Minuten. Oracle Integration schickt aber mehrere Aufrufe pro Sekunde.
Wir erreichen das Limit, die CRM-API antwortet mit „429 – Too Many Requests„
Die Integration wirft einen Fehler aus und stoppt.
Um dies zu verhindern, bauen wir einen „Chill-Out“ Step in die Integration ein und geben der Integration Zeit, um das Request-Limit abzuwarten und dann den nächsten Schwung an Daten zu übertragen.
Die Lösung in 5 schnellen Schritten
Die Variable initialisieren
Vor die For Each Schleife setzen wir eine Variable (z.B. callCount) mit dem Wert 0. Diese Variable zählt für uns die Aufrufe.
Den Wert der Variable nach jedem API-Aufruf erhöhen
In unserem Fall erfolgt pro Array-Element ein einzelner API-Aufruf und wir erhöhen den Zähler um 1
Ein Switch innerhalb der ForEach-Schleife
Hier legen wir das API-Limit fest, das wir hoffentlich durch die API-Dokumentation kennen oder, wenn nicht, uns durch Try & Error annähern. In unserem Fall sind das 100 Aufrufe. Die Bedingung legt also fest, dass wir ab Aufruf 101 eine Pause benötigen
Wenn die Switch-Bedingung erfüllt ist und das API-Limit erreicht wurde:
Einen Warteschritt einsetzen
Wir lassen die Integration nun so lange abkühlen, bis es sicher ist, die Ziel-Schnittstelle wieder aufzurufen. In unserem Fall sind das 5 Minuten (300 Sekunden)
Den Zähler zurücksetzen
Zum Schluss setzen wir den Zähler wieder auf 0. Die Integration überträgt wieder Daten bis das Limit erneut erreicht ist.
Das Ergebnis
Eine resiliente Integration, die sich selbst reguliert. Wir arbeiten große Datenmengen stabil ab, ohne die Zielsysteme zu überlasten oder Fehlermeldungen im Monitoring zu riskieren.
Hast du gewusst, dass du in Microsoft Dynamics 365 Sales keine riesige Marketing-Automatisierung brauchst, um eine gezielte Vertriebsaktion zu starten? Wenn es mal schnell gehen muss – zum Beispiel für eine Telefonaktion oder ein Follow-up – ist die Quick Campaign (Schnellkampagne) dein bestes Werkzeug.
Was ist eine Quick Campaign?
Mit der Quick Campaign kannst du direkt aus einer Liste von Kontakten, Firmen oder Leads eine einzelne Aktivität für die gesamte Gruppe erstellen.
Schritt-für-Schritt: Das Beispiel "Call Campaign"
Zielgruppe wählen: Navigiere zum Menüpunkt Contacts (Kontakte).
Auswahl treffen: Markiere die gewünschten Personen in der Liste.
Starten: Klicke in der Command Bar (Befehlsleiste) auf Quick Campaign.
Assistent folgen: Wähle „Phone Call“ als Aktivitätstyp aus und weise die Aufgaben dir selbst oder deinem Team zu.
Aktivitäten effizient abarbeiten
Sobald die Kampagne erstellt ist, findest du die Aufgaben übersichtlich im System:
Zentrale Ansicht: Unter Activities (Aktivitäten) kannst du die geplanten Anrufe einzeln aufrufen.
Workflow: Während des Telefonats hast du alle Infos direkt im Zugriff.
Abschluss: Nach dem Gespräch kannst du die Aktivität als Mark Complete schließen oder bei Erfolg direkt in eine Opportunity umwandeln.
Fazit: Minimaler Aufwand, maximale Struktur für deinen Sales-Tag!
Beim Arbeiten mit Dynamics 365 Sales ist es ganz normal, dass die Zeitleiste mit vielen Aktivitäten und Notizen gefüllt ist. Alles durchzuscrollen, nur um einen wichtigen Eintrag zu finden, kann viel Zeit kosten. Genau hier kommt die Anheften-Funktion ins Spiel.
Wenn diese Funktion von deinem Systemadministrator aktiviert wurde und deine Sicherheitsrolle dies zulässt (mit Schreib- und Löschrechten), kannst du bestimmte Datensätze, wie Notizen oder Aktivitäten anheften, sodass sie immer ganz oben in der Zeitleiste bleiben. So lassen sie sich später viel leichter wiederfinden.
Um einen Datensatz anzuheften, klicke einfach auf das Pinnadel-Symbol daneben. Der Eintrag wird in einen speziellen Bereich am oberen Rand der Zeitleiste verschoben, der als „Angeheftet“ bezeichnet ist. Dieser Bereich zeigt an, wie viele Datensätze angeheftet sind, und erlaubt maximal 15 Einträge gleichzeitig. Jeder angeheftete Datensatz bleibt dort ein Jahr lang, sofern er nicht manuell wieder gelöst wird.
✅ Kurztipp zu Berechtigungen: Wenn das Anheften bei dir nicht funktioniert, überprüfe die Einstellungen deiner Sicherheitsrolle. Unter dem Tab „Custom Entities“ findest du „Timeline Pin“. Hier müssen die Berechtigungen Erstellen, Lesen und Löschen aktiviert sein. Diese Konfiguration ist in der Standardrolle „Basic User“ enthalten, weshalb das Zuweisen dieser Rolle das Problem oft behebt. Da diese Einstellung auf Organisationsebene erfolgt, sind angeheftete Datensätze für alle Benutzer sichtbar, die die Zeitleiste dieser Entität sehen können.
Das Anheften ist vielleicht nur eine kleine Funktion. Für viele Benutzer macht sie das Navigieren durch Datensätze aber deutlich schneller und effizienter.
Ich hoffe, diese Anleitung war für einige von dich hilfreich. Bleib dran für weitere nützliche Tipps und Best Practices, damit du das Beste aus Dataverse herausholen kannst. Kontaktiere gerne unsere Microsoft-Experten bei Fragen.
In Microsoft Dynamics 365 Sales werden Angebots-IDs oft mithilfe der AutoNumber-Funktion mit einem fortlaufenden Startwert erstellt. In manchen Fällen ist es aber wünschenswert, dass sich die Nummerierung am Jahresanfang zurücksetzt, anstatt einfach unendlich weiterzulaufen.
Hier zeige ich dir, wie wir diese Herausforderung mit Power Automate gelöst haben.
🔧 Die Herausforderung
Standardmäßig setzt sich die AutoNumber-Sequenz nicht mit dem neuen Jahr zurück. Beispiel:
Angebots-ID-Sequenz: A24-998, A24-999, A24-1000 …
In unserem Fall wollten wir verhindern, dass die Angebotsnummern fünfstellig werden (z. B. A24-1000), sobald das neue Jahr beginnt. Stattdessen sollen sie im Januar des neuen Jahres wieder bei A25-001 starten.
🧩 Die Lösung: Jährliches Zurücksetzen per Power Automate
Wir haben dazu einen wiederkehrenden Power-Automate-Flow erstellt, der einmal im Jahr um 00:01 Uhr ausgeführt wird.
1. Letztes Angebot aufrufen
Mit der List Rows-Aktion:
Order By: createdon desc
Row Count: 1
So holen wir uns den zuletzt erstellten Angebots-Datensatz.
2. Apply to Each
Wir packen die Ausgabe in eine „Apply to each“-Schleife: outputs(‚List_rows‘)?[‚body/value‘]
Damit wir später leichter auf die Felder zugreifen können, nutzen wir anschließend „Get a row by ID“, um den vollständigen Angebotsdatensatz zu holen, und nennen diesen Schritt „Entity“ um.
3. Prüfen, ob sich das Jahr geändert hat
Jetzt kommt die Kernlogik
Wir vergleichen die Jahreszahl in der Angebots-ID mit dem aktuellen Kalender:
Wenn das Jahr in der Angebots-ID kleiner als das aktuelle Jahr ist, setzen wir den AutoNumber-Startwert zurück.
4. Startwert zurücksetzen
Wir nutzen die Aktion „Perform an unbound action“ mit:
Action Name: SetAutoNumberSeed
Target Field: quotenumber
Seed Value: 001
So startet die nächste Angebots-ID im neuen Jahr wieder bei A25-001.01.
✅ Ergebnis
Mit dieser Methode bleibt dein D365 Sales sauber und strukturiert: Die Angebotsnummern zeigen immer das aktuelle Jahr an, ganz ohne manuelle Eingriffe oder das Risiko, dass IDs plötzlich fünfstellig werden.
Ich hoffe, diese Anleitung hat dir geholfen. Bleib dran für weitere nützliche Tipps und Best Practices, damit du das Beste aus Dataverse herausholen kannst. Bei Fragen kannst du dich gerne an unsere Microsoft-Expert:innen wenden.
