Start / Seminare / Microsoft Copilot Studio in der Praxis

Modul

Bereitstellung und Weiterentwicklung

Modul 9 von 11 aus dem Seminar Microsoft Copilot Studio in der Praxis

5 Kapitel in diesem Modul-Video · Laufzeit

Für Teams

Die Videos zeigen, wie es geht. Die Schulung sorgt dafür, dass Ihr Team es danach tut.

Ein Video kann niemanden fragen, warum es ausgerechnet in Ihrem Repository nicht funktioniert. Es kann kein Team auf eine gemeinsame Konvention bringen. Und es setzt sich niemand freiwillig drei Tage hin. In der Schulung sind am Ende alle auf demselben Stand, gearbeitet wurde am eigenen Code, und die offenen Fragen sind entschieden — in ein paar Tagen statt irgendwann nebenbei.

Vorgespräch am Telefon · Programm nach Maß · ab 1 Tag (8 Unterrichtseinheiten) · Teilnahmezertifikat

Schulung anfragen So läuft eine Schulung ab

Vertonung mit synthetischer Stimme · Inhalte redaktionell verantwortet · © 2026 HECKER CONSULTING, alle Rechte vorbehalten

Transkript

Der gesprochene Text dieses Moduls zum Mitlesen, Überfliegen und Durchsuchen. Ein Klick auf einen Zeitstempel springt an die Stelle im Video.

Bereitstellung und Weiterentwicklung

0:00 Der letzte Tag beginnt mit dem Schritt, der oft als Ziel gilt und in Wahrheit ein Anfang ist: dem Veröffentlichen. Ab diesem Moment reden Menschen mit dem Agenten, die nicht wissen, wie er gebaut ist. Sie formulieren anders, fragen anderes und geben nicht so schnell auf wie wir im Test. Deshalb geht es in diesem Modul um zwei Dinge gleichzeitig: wie ein Agent sauber in einen Kanal kommt — und wie man ihn danach beobachtet. Das Zweite wird am häufigsten vergessen.

Bereitstellung und Weiterentwicklung

0:27 Vier Themen. Zuerst die Kanalwahl und was sie über den Inhalt entscheidet. Dann die Authentifizierung im Zielkanal — mit einigen Überraschungen, die man besser vorher kennt. Im dritten Kapitel geht es um Solutions und Umgebungen, also darum, wie ein Stand von der Entwicklung in die Produktion wandert. Und zum Schluss um die Auswertung im Betrieb.

Kanal auswählen

0:48 Beginnen wir bei der Frage, wo der Agent eigentlich erreichbar sein soll. Das klingt nach einer Entscheidung am Schluss — tatsächlich hätte sie ganz am Anfang fallen müssen, wie Sie gleich sehen werden. Der Ablauf ist zweistufig: Erst wird der Agent veröffentlicht, danach mit Kanälen verbunden. Und dann kommt ein Satz, den man sich merken sollte: Jede Veröffentlichung wirkt auf alle verbundenen Kanäle zugleich.

1:12 Es gibt also keine Teilveröffentlichung, kein „nur in Teams, noch nicht auf der Website". Zur Auswahl stehen unter anderem Teams und Microsoft 365 Copilot, SharePoint, die eigene Website, eine mobile Anwendung und die Kanäle des Azure Bot Service. Die Faustregel bleibt schlicht: dorthin, wo die Zielgruppe ohnehin arbeitet.

1:33 Zwei Zeilen verdienen besondere Aufmerksamkeit. Die dritte: Die Demo-Website ist für Rückmeldungen gedacht, nicht für den Betrieb — sie ist ausdrücklich nicht dafür vorgesehen, sie mit Kundschaft zu teilen. Und die erste: Teams und Microsoft 365 vertragen nur die Anmeldung mit Microsoft, und Markdown wird dort nur teilweise dargestellt.

1:53 Die Fußzeile ergänzt einen Punkt, der Projekte aufhalten kann: Administratoren steuern über die Kanalfreigabe, welche Kanäle überhaupt zur Verfügung stehen. Fragen Sie das früh ab. Hier schließt sich der Kreis zu Modul 4. Teams zeigt in einem Frageknoten höchstens sechs Auswahlmöglichkeiten — wer zehn plant, plant am Kanal vorbei.

2:14 Eine Antwort zeigt höchstens zwanzig Quellenangaben, und längere Titel werden gekürzt. Anhänge kann niemand senden, in keinem Kanal. Und selbst die Zufriedenheitsabfrage sieht je nach Kanal anders aus — mal als Karte, mal als reiner Text. Der Kanal ist also keine Zustellungsfrage, sondern eine Entwurfsvorgabe. Der erste Punkt ist der, den ich am häufigsten sehe: Die Demo-Website wird geteilt, weil sie so praktisch ist.

2:40 Der zweite ist eine Frage der Reihenfolge — breit in Teams verteilen, bevor alles konfiguriert und geprüft ist; die Dokumentation warnt davor ausdrücklich. Der dritte ist der Kanal als letzte Entscheidung, obwohl er die erste sein müsste. Und der vierte ist der, der erst beim Klicken auffällt: veröffentlichen in einen Kanal, den der Administrator gar nicht freigegeben hat.

Authentifizierung im Zielkanal

3:02 Jetzt zu dem Teil, bei dem Testchat und Wirklichkeit am weitesten auseinander liegen. Im Testchat sind Sie immer angemeldet und haben immer Rechte. Im Kanal gilt beides nicht selbstverständlich. Standardmäßig steht ein Agent auf Anmeldung mit Microsoft. Das ist bequem: In Teams, Power Apps und Microsoft 365 Copilot greift damit ohne weitere Einrichtung die Entra-ID-Anmeldung, und die Leute müssen sich nicht extra anmelden.

3:27 Für andere Kanäle mit Anmeldung brauchen Sie die manuelle Authentifizierung. Und noch einmal der Zusammenhang von Mittwoch, weil er im Betrieb so oft zuschlägt: Ohne Authentifizierung kann der Agent keine Werkzeuge mit Nutzerrechten verwenden. Beides hängt zusammen, auch wenn es in zwei verschiedenen Menüs steht. Der rote Faden ist die schrittweise Öffnung: erst für sich selbst, dann für die Zielgruppe, dann für alle.

3:52 Schritt drei ist der entscheidende — prüfen mit einem Konto der Zielgruppe, nicht mit dem Maker-Konto. Das ist die Stelle, an der Berechtigungsprobleme endlich auffallen, und sie fallen immer auf. Schritt vier wiederholt Wissensantworten und Werkzeuge im Kanal, weil dort andere Regeln gelten. Und die Fußzeile erinnert an die Falle von Donnerstag: Änderungen an der Authentifizierung wirken erst nach dem nächsten Veröffentlichen.

4:16 Dieses Verhalten sorgt regelmäßig für Verwirrung, und es hat einen guten Grund: Niemand soll mitten im Gespräch plötzlich mit einer anderen Fassung reden. Der neue Stand greift deshalb erst mit einer neuen Sitzung, und eine Sitzung endet in den meisten Kanälen nach dreißig Minuten ohne Aktivität. In Teams können Sie das mit der Eingabe „start over" abkürzen. Sonst kann es bis zu einer Stunde dauern.

4:39 Planen Sie das ein, wenn Sie eine Korrektur ausrollen und jemand sie prüfen soll. Der erste Punkt ist der Kern dieses Kapitels: im Testchat geprüft, im Kanal scheitert die Anmeldung. Der zweite ist die Verzögerung von eben — der Maker sieht den neuen Stand, die Nutzenden noch den alten, und beide reden aneinander vorbei.

4:57 Der dritte ist eine dokumentierte Einschränkung, die in Partnerszenarien wehtut: Gastnutzende erhalten keine generativen Antworten aus SharePoint-Quellen. Und der vierte ist die Notlösung, die alles bricht — die Authentifizierung abschalten, damit es endlich läuft.

Solutions und Umgebungen

5:13 Jetzt zum Weg eines Stands durch die Umgebungen. Das klingt nach IT-Prozess und ist auch einer — aber mit einer Besonderheit. Die Empfehlung lautet: mindestens drei Umgebungen — Entwicklung, Test, Produktion. Transportiert wird über Solutions, umgebungsabhängige Werte laufen über Umgebungsvariablen und Verbindungsverweise.

5:34 Dazu eine konkrete Vorgabe, die man leicht übersieht: Produktion wird als Produktionsumgebung angelegt, alle anderen als Sandbox-Umgebungen. Das ist kein Etikett, sondern beeinflusst, was möglich ist. Wer das beim Einrichten falsch macht, merkt es erst, wenn er etwas zurücksetzen will. Drei Stationen, und die Richtung ist einseitig. Das ist der Kern der ganzen Disziplin: Geändert wird nur ganz links. Test und Produktion empfangen, sie werden nicht bearbeitet.

6:03 Sobald jemand in der Produktion „nur schnell etwas anpasst", gibt es zwei Wahrheiten — und die Entwicklungsumgebung ist ab dann falsch. Diesen Rückweg gibt es nicht, man muss ihn von Hand nachbauen. Deshalb ist diese schlichte Kette eine der wirksamsten Vereinbarungen, die ein Team treffen kann. Und jetzt die Einschränkung, die man kennen muss: Einige Dinge sind nicht solutionfähig.

6:27 Dazu gehören die Einstellungen zu Application Insights, die manuelle Authentifizierung, die Sicherheit des Web-Kanals, die verbundenen Kanäle — und jede Art von Freigabe. Das klingt nach Kleinkram, ist aber genau der Kleinkram, der dafür sorgt, dass ein Agent in der Produktion steht und niemand ihn erreicht. Die Konsequenz ist einfach: Führen Sie eine Nachliste je Zielumgebung. Ohne diese Liste vergisst man es zuverlässig.

6:52 Fünf Regeln, und sie haben alle denselben Zweck: Sie sollen verhindern, dass zwei Wahrheiten entstehen. Nur in der Entwicklung ändern. Immer im Kontext einer Solution — sonst ist nichts transportierbar, und das merkt man erst, wenn man transportieren will. Eigener Herausgeber und Präfix, damit später erkennbar bleibt, was von wem stammt. Umgebungsvariablen für alles, was sich unterscheidet.

7:16 Und verwaltet ausliefern, außer in der Entwicklung — damit Änderungen nachvollziehbar bleiben und sich sauber entfernen lassen. Der erste Punkt ist der Anfang vom Ende jeder sauberen Bereitstellung: in der Produktion schnell etwas ändern und nie zurückspielen. Der zweite ist die vergessene Nachliste — Agent läuft, Kanal fehlt. Der dritte ist die unverwaltete Auslieferung, die sich später nicht sauber entfernen lässt.

7:41 Und der vierte ist der, der zu falschen Daten führt und trotzdem lange unbemerkt bleibt: Die Verbindungsverweise fehlen, und die Zielumgebung zeigt fröhlich auf das Testsystem.

Nutzung auswerten

7:51 Der Agent läuft. Jetzt beginnt der Teil, für den sich im Projektplan selten jemand zuständig fühlt — und der trotzdem darüber entscheidet, ob er in einem halben Jahr noch benutzt wird. Die Seite Monitor zeigt Kennzahlen, Themen und Sitzungsdetails — getrennt für Gespräche und für ereignisgesteuerte Läufe. Zwei Zahlen sollten Sie sich merken, weil sie Ihre Arbeitsweise bestimmen: Auswertungsdaten stehen bis zu 360 Tage zur Verfügung, Sitzungsdetails und Transkripte aber nur für die letzten 28 Tage.

8:21 Wer also einem Vorfall nachgehen will, hat vier Wochen Zeit — danach gibt es nur noch Zahlen, keine Gespräche mehr. Und alle Zeitangaben sind in koordinierter Weltzeit, was bei Tagesauswertungen gern für Verschiebungen sorgt. Das Muster dieser Tabelle: Jede Beobachtung hat mehrere mögliche Ursachen, und die Zahl allein sagt nicht welche.

8:42 Viele Abbrüche können an zu langen Vorgängen liegen — oder an unverständlichen Fragen. Viele Eskalationen können fehlendes Wissen bedeuten — oder einen zu eng geschnittenen Aufgabenbereich. Deshalb ist die Auswertung immer nur der Einstieg. Die Antwort steht in den Transkripten. Und die Fußzeile nennt eine Voraussetzung, die man leicht übersieht: Kennzahlen zu aktiven Nutzenden gibt es nur mit Anmeldung.

9:06 Vier Einschränkungen, die man kennen sollte. Testchat-Aktivität erscheint nicht — gut so, sonst würden Ihre eigenen Versuche die Zahlen verfälschen. Die Themenauswertung je Topic gibt es nur im klassischen Modus; im generativen Modus treten Gesprächsausgänge und Themen an ihre Stelle. Das ist wichtig, wenn Sie eine Auswertung aus einer älteren Anleitung erwarten.

9:27 Und Transkripte stehen erst einige Minuten nach Sitzungsende bereit — nicht sofort, was bei einer akuten Fehlersuche kurz irritiert. Der erste Punkt ist der verbreitetste Betriebsfehler überhaupt: einmal ansehen nach dem Start, danach nie wieder. Der zweite erklärt den ersten — es ist niemand benannt. Der dritte ist die Zahlengläubigkeit: Maßnahmen ableiten, ohne in die Transkripte zu sehen.

9:51 Und der vierte ist eine Berechtigungsfrage, die gern vergessen wird: Für Transkripte braucht es zusätzlich zur Auswertungsberechtigung eine eigene Rolle. Klären Sie das, bevor Sie die Transkripte brauchen.

Übung

10:04 Jetzt bringen wir das zusammen — in einer Liste, die man vor dem Start tatsächlich abarbeiten kann. Nicht als Formular für die Akte, sondern als das Papier, das Sie bei der Freigabe vorlegen. Der Lernlotse soll in Teams für alle 1.800 Beschäftigten der Ankerfeld GmbH bereitstehen. Das ist der Moment, in dem aus einem Übungsagenten eine Anwendung wird.

10:25 Und statt zu fragen, ob er fertig ist — diese Frage beantwortet jeder mit Ja —, füllen Sie eine Checkliste aus, die den Betrieb genauso abdeckt wie die Veröffentlichung. Der Betriebsteil ist der, den Sie später am meisten brauchen werden. Das Lernziel bringt es auf den Punkt: entlang prüfbarer Punkte vorbereiten statt entlang des Gefühls, fertig zu sein.

10:47 Sieben Positionen sind verlangt, von Kanal und Authentifizierung bis zu Beobachtungsrhythmus und Rückweg. Und der Zusatz im Erfolgskriterium ist der eigentliche Maßstab: jeder Punkt mit Nachweis oder benanntem Termin. Ein Haken ohne Nachweis ist nur ein Haken. Wer es möglich machen kann, erprobt den Agenten anschließend in einem freigegebenen Testkanal.

11:09 Schritt eins prüft Kanal und Authentifizierung gegeneinander — das ist die Kombination, an der es am häufigsten scheitert. Schritt zwei ist die Nachliste der nicht transportierbaren Einstellungen, über die wir vorhin gesprochen haben. Schritt drei holt den Testnachweis aus Modul 8; behaupten reicht nicht. Schritt vier benennt Rolle und Rhythmus.

11:29 Und Schritt fünf ist der, den man ungern aufschreibt und im Ernstfall dankbar liest: Wer schaltet ab, und woran erkennt er den Anlass? Der erste Punkt macht die ganze Übung wertlos: abhaken, ohne zu prüfen. Der zweite ist der fehlende Rhythmus — ein unbeobachteter Agent wird nicht schlechter, aber seine Quellen werden es.

11:48 Der dritte ist die vergessene Nachliste, deren Folgen wir kennen. Und der vierte ist der mündliche Rückweg: Im Vorfall sucht niemand nach einer Erinnerung, sondern nach einem Dokument. Im nächsten Modul rechnen wir aus, was der Betrieb eigentlich kostet.

Dieses Modul als Schulung für Ihr Team

Das Video zeigt den Stoff. In der Schulung arbeitet Ihr Team damit — an Ihrem eigenen Code, mit Übungen und mit den Fragen, die ein Video nicht beantwortet. Sie wählen die Module aus Microsoft Copilot Studio in der Praxis, wir bauen daraus ein Programm.

5 Tage·ab 900 EUR netto pro Tag (bis 3 Teilnehmende) ·Termin nach Vereinbarung

Als Team-Schulung anfragenWie eine Schulung abläuft →