Question asked yesterday in the workshop: “Where is the data collected by Copilot for Power Platform processed?” I didn’t have an answer yesterday, but I do today. 😊 The data is first processed in the region where the environment to which I sent the prompt is located.
Microsoft also reserves the right to process the data outside the source region if it is busy. The load is then distributed to data centers in geographical proximity, i.e., in Germany, then Sweden, the Netherlands, France, etc. Microsoft guarantees processing within Europe.
However, an administrator can disable this feature by selecting the affected environment in the Power Platform Admin Center and disabling the “Move data between regions” setting in the “Generative AI features” section. If you disable the option, however, Copilot features may no longer be available for that environment.
Frage gestern im Workshop: „Die Daten, welcher der Copilot für Power Platform erhebt, wo werden diese denn verarbeitet?“. Diese Antwort musste ich gestern erst einmal schuldig bleiben, aber heute habe ich sie 😊
Die Daten werden zunächst einmal in der Region verarbeitet, in der sich die Umgebung befindet, in der ich den Prompt abgesetzt habe. Da viele auch eine Umgebung zum Testen in den USA betreiben, denn nur dort gibt es die neuen Funktionen zuerst, muss man da schon einmal aufpassen.
Außerdem behält sich Microsoft das Recht vor, die Daten auch außerhalb der Quellregion zu verarbeiten, wenn diese ausgelastet ist. 😮 Die Last wird dann auf Rechenzentren in geographischer Nähe, also in Deutschland dann Schweden, Niederlande, Frankreich, etc. verteilt. Microsoft garantiert dabei die Verarbeitung innerhalb von Europa. 😴
Diese Funktion kann allerdings ein Administrator deaktivieren, indem er im Power Platform Admin Center die betroffene Umgebung auswählt und dort im Abschnitt „Generative AI features“ die Einstellung „Move data across regions“ deaktiviert. Wenn Sie die Option deaktivieren, sind aber möglicherweise keine Copilot-Funktionen für diese Umgebung mehr verfügbar ☝️
Dieser Artikel ist ohne KI geschrieben. Na so was!
Die aktuelle Ausgabe des IT-Administrator 08/2025 enthält einen Artikel von mir zum Thema Microsoft Power Pages. Es ist der zweite Artikel in einer kleinen Serie rum um das Thema Dataverse. Wer mehr über Microsoft Power Pages und Dataverse wissen möchte, auch im Zusammenspiel mit Copilot Agenten, kontaktiert mich. Die ganze Zeitung kann hier gekauft werden: https://shop.heinemann-verlag.de/
In der aktuellen Ausgabe der Fachzeitschrift IT-Administrator 07/2025 ist von mir ein Artikel über Microsoft Dataverse erschienen. Dies ist der erste Teil einer kleinen Serie, bleibt gespannt. Wer mehr über Microsoft Dataverse wissen möchte, auch und gerade im Zusammenspiel mit Power Pages oder Copilot Agenten, kontaktiert mich. https://shop.heinemann-verlag.de/
In my projects, I keep seeing Power Automate flows being created directly in an environment. This means that they are outside of a solution. The flow doesn’t care where it runs, but there are at least three good reasons to package flows in a solution and work with them. This article introduces these tree advantages. These apply even if you don’t have multiple environments, which is often the reason to work with solutions in the first place.
Note: The benefits described here are only possible if you work with https://make.Powerautomate.com. In all other sites, including https://make.PowerApps.com it doesn’t work! In addition, you must use the (not quite) new editor. Unfortunately, there are some triggers with which this is not possible. You also absolutely need a Dataverse database in your environment.
What are solutions?
Solutions are a logical container that contains artifacts from the Power Platform. These artifacts can be Power Apps, Flows, Dataverse content, and more. These solutions can be exported from an environment and imported into a target environment. This also makes it possible to get an overview of which adjustments have been made and for which period. Solutions can also be versioned, which makes it even easier to manage. Solutions require a Dataverse database.
First advantage: More actions
If a flow is outside of a solution and you try to start another flow, this is associated with a lot of effort or even completely impossible. If the flow is in a solution, there is a corresponding action for it. We can find this action, called Run a Child Flow, in the Flows group. This is the only action there.
Only a flow within the same solution can be started and you need the rights for that flow.
Attention: Currently it is not possible for me to configure the action in the new editor, I can only do this in the classic editor. In the new editor, I can’t select a child workflow. So you have to switch back and forth in development.
There is a lot more to consider on this topic, the following article explains this: https://learn.microsoft.com/en-us/power-automate/create-child-flows An addition: The sub workflow requires the action „Respond to a Power App or flow“. However, this action is not easy to find. You must enter „Power Apps“ in the search for a connector and do it exactly like this. If you search for PowerApps (without spaces), you’ll find some connectors for Power Apps, but the one we wanted isn’t there.
Second advantage: Versioning a flow
When a flow is created in a solution, it is versioned. Drafts can be saved and flows can be published selectively. It is also possible to jump back to a previous version. A flow is added to a solution like any other artifact.
Attention: I always have the problem that when I create a flow in the solution, the old editor is opened. The alternative is to first create the flow outside the solution and then import it into it.
The versioning controls are located at the top right, where save, test, etc. are already located.
Now, when a flow is saved, a minor version or draft is saved. This cannot be executed it must first be published with Publish. This also means that if you already have a published version, and you save it and want to test it, it will NOT run what you have just saved. The last published version will be executed. Before you want to test, the flow must be published via Publish.
You can use the clock icon on the left of the Flow checker action to jump back to an earlier version.
Third benefit: Change (co)ownership of a flow
In a flow outside of a solution, I can specify accounts that can change the flow with it but not change the owner. Only an owner can change the rights of a flow and delete them. But with a flow in a solution, I can also change the owner. To do this, go to the administration page of the flow and enter or change the co-owner in the Co-owners section by clicking on Set primary owner.
Make sure that the new owner also has the correct licenses for the flow. In my screenshot, this is not the case.
Summary
When developing flows, they should always be used in a solution. It has no disadvantages and only brings advantages. Have you already worked with Flow in solutions?
If you would like to learn more about Microsoft Flow, you are welcomed to attend a seminar I’ve created. I offer these once as a seminar for people with an IT background and once for people without an IT background. Get in touch with me.
In meinen Projekten sehe ich immer wieder, dass Power Automate Flows direkt in einer Umgebung erstellt werden. Damit stehen diese außerhalb einer Lösung bzw. Solution. Dem Flow ist es erst einmal gleich, wo dieser läuft, aber es gibt zumindest drei gute Gründe Flows in eine Lösung zu verpacken und damit zu arbeiten. Dieser Artikel stellt diese drei Vorteile vor. Diese gelten auch, wenn Sie nicht mehrere Umgebungen haben, was oft der Grund ist überhaupt mit Lösungen zu arbeiten.
Achtung: Die hier beschriebenen Vorteile sind nur dann möglich, wenn Sie mit der URL https://make.powerautomate.com arbeiten. In allen anderen Oberflächen, auch in https://make.powerapps.com geht es nicht! Außerdem müssen Sie zwingend den (schon nicht mehr ganz) neuen Editor verwenden. Leider gibt es einige Trigger, mit welchen dies nicht möglich ist. Außerdem benötigen Sie unbedingt eine Dataverse Datenbank in Ihrer Umgebung.
Was sind Lösungen bzw. Solutions?
Lösungen sind ein logischer Container, welcher Artefakte aus der Power Platform enthält. Diese Artefakte können Power Apps, Flows, Dataverse Inhalte und vieles mehr sein. Die Lösungen können aus einer Umgebung exportiert und in eine Zielumgebung importiert werden. Damit ist es auch möglich eine Übersicht zu erhalten, welche Anpassungen zu welchem Zeitraum durchgeführt wurden. Lösungen können auch versioniert werden, was die Verwaltung noch einmal einfach macht. Lösungen erfordern zwingend eine Dataverse Datenbank.
Erster Vorteil: Mehr Aktionen
Wenn sich ein Flow außerhalb einer Lösung befindet und Sie versuchen darin einen weiteren Flow zu starten, so ist dies mit sehr hohem Aufwand verbunden oder sogar komplett unmöglich. Wenn sich der Flow in einer Lösung befindet, gibt es dafür eine entsprechende Aktion. Wir finden diese Aktion mit den Namen Run a Child Flow in der Gruppe Flows. Dort ist dies die einzige Aktion.
Gestartet werden kann dabei nur ein Flow, welcher sich in der gleichen Solution befinden und auf dem Sie Rechte haben.
Achtung: Aktuell ist es mir nicht möglich, die Aktion im neuen Editor zu konfigurieren, dies gelingt mir nur im klassischen Editor. Im neuem Editor läßt sich mir kein untergeordneter Workflow auswählen. Man muss also in der Entwicklung hin- und herschalten.
Es gibt bei dem Thema noch einiges mehr zu beachten, der folgende Artikel erläutert dies: https://learn.microsoft.com/en-us/power-automate/create-child-flows Dazu noch eine Ergänzung: Der Subworkflow benötigt zwingend die Aktion „Respond to a Power App or flow“. Diese Aktion ist allerdings nicht einfach zu finden. Sie müssen in der Suche nach einem Konnektor „Power Apps“ eingeben und zwar genau so. Wenn Sie nach PowerApps (ohne Leerzeichen) suchen, finden Sie einige Konnektoren für Power Apps, aber der von uns gewünschte ist nicht dabei.
Zweiter Vorteil: Einen Flow versionieren
Wenn ein Flow in einer Lösung erstellt wird, so wird dieser versioniert. Dabei können Entwürfe gespeichert und Flows selektiv veröffentlicht werden. Ebenso ist es möglich auf eine Vorgängerversion zurückzuspringen. Ein Flow wird einer Lösung wie jedes andere Artefakt hinzugefügt beziehungsweise erstellt.
Achtung: Ich habe immer wieder das Problem, dass wenn ich einen Flow in der Solution erstelle, den alten Editor angeboten bekomme. Die Alternative ist, den Flow zuerst außerhalb der Lösung zu erstellen und dann in diese zu importieren.
Die Steuerelemente der Versionierung finden sich oben rechts, wo sich auch schon Speichern, Test, etc. befinden.
Wenn jetzt ein Flow gespeichert wird, wird eine Nebenversion bzw. Entwurf gespeichert. Dieser kann nicht ausgeführt, sondern muss mit Publish erst veröffentlicht werden. Dies bedeutet auch, wenn Sie schon eine Version veröffentlicht haben, speichern und dann testen, wird NICHT das ausgeführt, was Sie eben gespeichert haben, sondern die letzte veröffentlichte Version. Vor einem Test muss via Publish der Flow veröffentlicht werden.
Über das Uhrensymbol, links neben dem Flow checker, können Sie in eine frühere Version wieder zurückspringen.
Dritter Vorteil: (Co)Besitzer eines Flow ändern
In einem Flow außerhalb einer Lösung kann ich Konten angeben, welche den Flow mit ändern können, aber nicht den Besitzer ändern. Nur ein Besitzer kann die Rechte eines Flows ändern und diese auch löschen. Mit einem Flow in einer Lösung kann ich aber auch den Besitzer ändern. Dazu wird auf die Verwaltungsseite des Flows gegangen und dort unter dem Punkt Co-owners mit einem Klick auf Set primary owner der Mitbesitzer eingetragen oder geändert.
Achten Sie darauf, dass der neue Besitzer auch die richtigen Lizenzen für den Flow besitzt. In meinen Screenshot ist dies nicht der Fall.
Fazit
Wenn Flows entwickelt werden, sollte diese immer in einer Solution verwendet werden. Es hat keine Nachteile und bringt nur Vorteile mit sich. Haben Sie schon mit Flow in Lösungen gearbeitet?
Wenn Sie mehr über Microsoft Flow lernen möchten, können Sie auch gern ein Seminar von mir besuchen. Diese biete ich einmal als Seminar für Personen mit IT Hintergrund an und einmal für Personen ohne IT Hintergrund. Nehmen Sie Kontakt mit mir auf.
A customer wants to map a supplier process using Microsoft Power Pages. I was asked to advise on how it all works and what needs to be taken into account. The application is simple at first, but is very complex in itself. Essentially, it is about a supplier being able to give you feedback on whether all the materials have been delivered by the customer. The supplier also announces its deliveries, including the creation of delivery notes. All data is originally in SAP and some of it needs to be transferred to Dataverse.
The customer has a very good IT department and therefore needed targeted and in-depth advice on Power Pages. These points are certainly interesting for anyone who wants to work with Power Pages.
Dataverse is not a SQL database
A key factor in the success of a Power Pages project is the data structure in the Dataverse. Although the Dataverse is ultimately provided by a database server, it is not a „classic“ SQL database. There are no views that span multiple tables, no stored procedures, and no SQL as a query language. Instead, each table has a ready-made form, ready-made relationships, and views for the data. „Translating“ an SQL solution into a Dataverse solution can be complicated.
For the customer, part of the existing SQL solutions were transferred one-to-one into the Dataverse via virtual tables and another part was redesigned in the Dataverse.
Power Pages is not low-code
Power Pages has the Power Pages Studio. In this I can create pages with a WYSIWYG editor, make Dataverse tables available on the Internet and even enter or change data there. Just like that, with a click. But that’s not enough. These -real- low code solutions are usually not sufficient. Often they are too inflexible or simply lack options. As soon as you go a little deeper, you quickly get to Liquid. This is a dynamic language that is used to control pages in Dataverse. This is no longer low code, you have to be able to program here. You will also have to work relatively quickly with JavaScript. A precise analysis of the requirement shows what is necessary here.
Permissions in Power Pages
Permissions in Power Pages differ significantly from permissions in the Dataverse. The design of the permissions must be taken into account when designing the data structure. Most users who will log into Power Pages will probably be users from the Contacts table. If these contacts are to access specific records, these records must have a relationship to the Contacts table. Otherwise, assigning records and users becomes very difficult.
Conclusion
These few points show how complex a project to introduce a Power Page portal can be. If you have any questions about this topic or would like to see a portal in action, just write to me. Experiences from a recently completed consultation on a Power Pages project
Ein Kunde möchte einen Lieferanten Prozess über Microsoft Power Pages abbilden. Wie das alles funktioniert, was beachtet werden muss, dies sollte ich beraten. Die Anwendung ist erst einmal einfach, aber in sich dann doch sehr komplex. Im Kern geht es darum, dass ein Lieferant zu einem eine Rückmeldung geben kann, ob alle Materialien vom Auftragsgeber geliefert wurden. Zum anderen kündigt der Lieferant seine Lieferungen an, inklusive der Erstellung von Lieferscheinen. Alle Daten liegen ursprünglich im SAP und müssen teilweise ins Dataverse transferiert werden.
Der Kunde hat eine sehr gute IT Abteilung und brauchte daher eine gezielte und tiefe Beratung zu Power Pages. Diese Punkte sind auch sicher für alle interessant, welche mit Power Pages arbeiten möchten.
Dataverse ist keine SQL Datenbank
Ein wesentlicher Punkt für den Erfolg eines Power Pages Projektes ist die Datenstruktur im Dataverse. Obwohl das Dataverse letzten Endes durch einen Datenbank Server zur Verfügung gestellt wird, ist es keine „klassische “ SQL Datenbank. So gibt es keine Views, welche über mehrere Tabellen gehen, keine stored procedurs und auch kein SQL als Abfragesprache. Dafür hat jede Tabelle ein fertiges Formular, fertige Beziehungen und Ansichten für die Daten. Eine SQL Lösung in eine Dataverse Lösung zu „übersetzen“, kann kompliziert sein.
Beim Kunde wurde ein Teil der vorhandenen SQL Lösungen via virtuelle Tabellen eins zu eins ins Dataverse übernommen und ein weiterer Teil im Dataverse neu gestaltet.
Power Pages ist kein Lowcode
In Power Pages gibt es das Power Pages Studio. In diesem kann ich mit einem WYSIWYG Editor Seiten erstellen, Dataverse Tabellen im Internet verfügbar machen und dort sogar Daten erfassen oder ändern. Einfach so, nur mit klicken. Nur, das reicht eben nicht. Diese -wirklichen- Low Code Lösungen sind in der Regel nicht ausreichend. Oft sind diese zu unflexibel oder es fehlen einfach Möglichkeiten. Sobald man etwas tiefer geht, ist man sehr schnell bei Liquid. Dies ist eine dynamische Sprache, welche zum Steuern von Seiten in Dataverse verwendet wird. Diese ist nicht mehr Low Code, hier muss man programmieren können. Ebenso wird man relativ schnell mit JavaScript arbeiten müssen. Eine genaue Analyse der Anforderung zeigt hier, was notwendig ist.
Berechtigungen in Power Pages
Berechtigungen in Power Pages unterscheiden sich signifikant von Berechtigungen im Dataverse. Das Design der Berechtigungen muss beim Design der Datenstruktur mitberücksichtigt werden. Die meisten Nutzer, die sich in Power Pages anmelden werden, werden wahrscheinlich Benutzer aus der Kontakt Tabelle sein. Wenn diese Kontakte gezielt auf Datensätze zugreifen sollen, müssen diese Datensätze eine Beziehung zu der Kontakttabelle haben. Andernfalls wird eine Zuweisung zu Datensätzen und Benutzern sehr schwierig.
Fazit
Diese wenigen Punkte zeigen, wie komplex ein Projekt zur Einführung eines Power Page Portal sein kann. Wenn sie Fragen zu dieser Thematik haben oder einmal ein Portal in Aktion sehen möchten, schreiben sie mich einfach an.Erfahrungen aus einer eben abgeschlossen Beratung zu einem Power Pages Projekt
In der aktuellen Ausgabe 11/23 vom IT-Administrator ist von mir ein Artikel über Microsoft Biceps erschienen. Wer damit nichts anfangen kann, einfach das Heft kaufen 🙂
08.06.2023 Eigene Daten können mit ChatGTP und Azure Cognitive Search einfach erschlossen werden. Dieser Artikel enthält einige Anmerkungen zu einem Projekt von Microsoft, welches genau dies leistet.
KI Tools wie ChatGTP entwickeln für viele Organisationen erst dann einen größeren Nutzen, wenn es möglich wird die eigenen Daten darin zu verwenden. Microsoft hat vor einer Weile ein Projekt vorgestellt, welche es erlaubt, eigene Dokumente zu indizieren und per ChatGTP abzufragen. Dies ist eine gute Gelegenheit, um eigene Daten per ChatGTP zu erschließen. Eine Beschreibung für das Projekt findet sich unter
In dem Repo https://github.com/Azure-Samples/azure-search-openai-demo/ gibt es eine Anleitung, wie das entsprechende Projekt eingerichtet wird. Ohne lokale Rechte als Administrator geht es schon mal nicht. Ich möchte jetzt nicht im Einzelnen erklären was Sie wie machen müssen, die Artikel sind wirklich gut. Vielmehr möchte ich einige Anmerkungen machen, welche im Artikel nicht enthalten sind.
Damit sie das Projekt überhaupt nutzen können, muss in Ihrem Azure Mandaten OpenAI aktiviert sein. Sie können in Azure die OpenAI Ressource immer aufrufen. Wenn Sie noch keine Freischaltung haben, wird Ihnen ein Link angeboten, welcher auf ein Formular verweist. Nach dem Ausfüllen und Versenden des Formulars hat es bei mir nur einen Tag gedauert, dann stand OpenAI zur Verfügung.
In dem Formular wird nach einer Region gefragt, in welcher OpenAI aktiviert werden soll. Bei mir war das EastUS als einzige Option. Wenn man das Projekt einrichtet, fragt dieses ebenfalls nach einer Region und schlägt standardmäßig EastUS2 vor. Wenn man diesen Standard bestätigt, schlägt das Projekt fehl. Man kann nur die Region verwenden, welche man im Formular angegeben hat.
Das Projekt baut ein Verzeichnis auf, in welcher sich in der root der Ordner data befindet. Dieser enthält die Dokumente, welche in der Azure Cognitive Search indiziert werden. ChatGTP fragt dann diese Suche ab. Sie können natürlich auch eigene Dokumente in diesem Ordner ablegen, aber nur als PDF. Wenn Sie ein anderes Format wünschen, wie z.B. docx, müssen Sie den Quellcode in Python anpassen. Findet der Parser ein Dokument, welches kein PDF ist oder er kann das PDF nicht öffnen, stützt das Programm ab.
Im folgenden Screenshot habe ich den schon vorhandenen PDF Dateien einige Märchen der Gebrüder Grimm hinzugefügt und dann Inhalte abgefragt. Dabei sieht man links die Abfragen und rechts die gefundenen Dokumente.
Im Projekt wird die Azure Cognitive Search benutzt. Dies impliziert, dass Sie die Kosten im Auge behalten sollten. Die Suche kann vergleichsweise teuer werden. Außerdem benötigt das Indizieren seine Zeit. Wenn man bei den mitgelieferten PDF Dateien bleibt, sind dies mehrere Stunden.
Da die Azure Cognitive Search benutzt wird, ist die Möglichkeit dieses Projektes nicht auf Dokumente begrenzt. Praktisch kann jede Datenquelle verwendet werden, welche von der Azure Cognitive Search indiziert werden kann. Dies eröffnet viele neue und interessante Möglichkeiten. Gerade auch die Azure Cosmos Datenbank, mit ihrer optimierten Verarbeitung von JSON Dokumenten bietet sich hier an. Oder eine Microsoft SQL Datenbank, welche ein ERP indiziert. Ideen gibt es viele.
Fazit
Das Projekt läßt sich vergleichsweise einfach aufsetzen, braucht aber eine Weile bis sich Ergebnisse zeigen. Diese wiederum sind fantastisch und eröffnen ungeahnte Möglichkeiten. Dadurch, dass ausschließlich Cloud Komponenten verwendet werden und der Quellcode offen ist, lässt sich die Lösung auch einfach in eigene Apps einbauen.
Nico Thiemer - SharePoint Enthusiast seit 2001 