Jak AI może nadzorować przepływy w Power Automate, wyjaśniać błędy i odpowiadać na pytania o dane w Dataverse?

Tak, AI można podłączyć do Power Automate i Dataverse przez gotowe API Microsoftu. Asystent na własnym serwerze może odpytać historię uruchomień przepływów, wyciągnąć błędy z ostatniego tygodnia, sprawdzić dane w tabelach Dataverse i listach SharePoint, a potem odpowiedzieć człowiekowi w zwykłym języku: "Ten przepływ padał trzy razy w tym tygodniu, bo wygasło połączenie z SharePoint i nikt go nie odnowił." Firma przestaje zależeć od jednej osoby, która wiedziała, jak to wszystko działa.

Skąd bierze się problem: dziesiątki przepływów, brak dokumentacji i jeden człowiek, który to rozumiał

Każda firma, która używa Power Automate od roku lub dłużej, trafia w ten sam punkt. Ktoś, nazwijmy go Tomkiem, zbudował przez kilka lat kilkadziesiąt przepływów. Teraz Tomek odszedł albo zmienił dział. Przepływy działają... chyba. Nikt w firmie nie wie, które z nich faktycznie coś robią, a które od dawna milczą.

W portalu Power Automate są zakładki Moje przepływy i Przepływy zespołu, ale żaden z nich nie ma opisu. Nazwy to "Approval final v2 USE THIS", "Kopia wysyłka maila stare", "Test Jan kopiować". Historia uruchomień jest, ale żeby ją przejrzeć, trzeba klikać przez każdy przepływ osobno. Pole runHistory w API ma wszystko, ale nikt tam nie zagląda, bo po prostu nikt nie wiedział, że to jest możliwe.

Typowo wygląda to tak: spada jakaś automatyzacja, klient albo pracownik zgłasza problem, ktoś z IT otwiera Power Automate i przez 40 minut szuka, który przepływ jest odpowiedzialny. Potem czyta JSON definicji przepływu i próbuje rozgryźć logikę, która powstawała przez dwa lata. Właśnie tutaj wchodzi AI.

Jak fizycznie podłączyć AI do Power Platform: API, uprawnienia i to, czego Microsoft nie daje

Power Platform ma otwarte API, z którego większość firm nigdy nie korzysta bezpośrednio. Są trzy główne wejścia.

Power Automate Management API to REST API od Microsoftu. Pozwala wylistować wszystkie przepływy w środowisku, pobrać ich definicje jako JSON (triggery, akcje, warunki), a przede wszystkim pobrać historię uruchomień z polami: data startu, czas trwania, status (Succeeded / Failed / Running), nazwa kroku, gdzie wystąpił błąd i komunikat błędu. Odpytanie daje np.: "Krok 'Get item' na liście 'Zamówienia' zwrócił 403 Forbidden o 09:14". Można też wyciągnąć pole createdBy, żeby zobaczyć właściciela przepływu, oraz lastModifiedTime, kiedy przepływ był ostatnio zmieniany.

Dataverse OData v4 to API do bazy danych Power Platform. Każda tabela: standardowa jak accounts, contacts, incidents, albo własna firmy jak zlecenia_serwisowe czy wnioski_urlopowe, jest dostępna pod adresem https://{org}.api.crm.dynamics.com/api/data/v9.2/. Zapytanie może zawierać filtr ($filter), wybór pól ($select), sortowanie ($orderby) i stronicowanie. AI może odpytywać tę bazę w odpowiedzi na pytanie użytkownika, bez konieczności budowania raportu w Power BI.

Microsoft Graph API daje dostęp do list SharePoint: elementy, pola niestandardowe, załączniki, historia zmian. Jeśli firma trzyma dane w listach SharePoint zamiast w Dataverse, to tędy.

Co trzeba mieć, żeby to działało? Rejestracja aplikacji w Azure Active Directory, czyli nadanie asystentowi tożsamości w ekosystemie Microsoftu. Do tego odpowiednie uprawnienia API: Flow.Read.All do przepływów, Dynamics CRM user_impersonation albo uprawnienia do konkretnych tabel Dataverse, Sites.Read.All do SharePoint. Wszystko po stronie Azure AD, bez instalowania czegokolwiek w środowisku Power Platform. Wygenerowany Client ID i Client Secret wchodzą do konfiguracji asystenta na własnym serwerze.

Czego Microsoft nie daje swobodnie: pełne wewnętrzne logi łączników premium (np. SAP, Salesforce) są ograniczone w API. Widać, że krok padł i jaki błąd zwrócił, ale nie zawsze widać, co dokładnie poszło po stronie zewnętrznego systemu. Definicja przepływu jako JSON jest dostępna, ale jej format bywa złożony przy dużych przepływach z wieloma zagnieżdżonymi warunkami: czytanie jej ręcznie jest żmudne, ale AI radzi sobie z tym dobrze.

Desktop Flows, czyli Power Automate Desktop do automatyzacji na komputerze, mają osobne API zarządzania. Historia uruchomień jest, ale szczegóły wykonania na poziomie kroków są bardziej ograniczone niż przy Cloud Flows. Dane z Desktop Flows najlepiej zbierać przez logi sesji lub tabelę Dataverse, do której przepływ sam wpisuje wyniki.

Co AI robi z przepływami i historią uruchomień

Gdy asystent ma dostęp do API, może robić rzeczy, których nie da się zrobić ręcznie bez godzin pracy.

Tłumaczenie przepływu po ludzku. AI pobiera definicję JSON danego przepływu, czyta akcje, warunki i triggery, i wyjaśnia: "Ten przepływ uruchamia się automatycznie, gdy ktoś prześle formularz w Power Apps. Sprawdza pole Kwota: jeśli jest powyżej 10 000 zł, wysyła prośbę o zatwierdzenie do menedżera z pola MenedżerEmail. Czeka na odpowiedź. Gdy menedżer zatwierdzi, tworzy wpis w tabeli Dataverse 'zlecenia' i wysyła potwierdzenie do wnioskodawcy. Gdy odrzuci, wysyła mail z polem UzasadnienieOdrzucenia." Nie trzeba być programistą, żeby to zrozumieć.

Automatyczna dokumentacja przepływów. Każdy przepływ w firmie powinien mieć opis: co robi, kto go zbudował, jakie tabele i listy dotyka, jakie warunki sprawdza. W praktyce tego opisu nie ma. AI czyta JSON definicji i generuje go automatycznie w formacie, który można wkleić do wiki firmy albo do pliku przy przepływie. Dla 50 przepływów zajmuje to kilka minut, nie kilka dni.

Przegląd błędów z tygodnia. Zapytanie do runHistory z filtrem status eq 'Failed' i zakresem dat z ostatnich 7 dni, pogrupowane po flowId. AI dostaje zestawienie: który przepływ, ile razy padł, na którym kroku, jaki komunikat. Dla każdego błędu daje zwięzłą diagnozę i sugestię, co sprawdzić.

U jednego klienta, firmy dystrybucyjnej, asystent wyłapał, że przepływ "Powiadomienie o nowej ofercie od dostawcy" padał 11 razy w tygodniu na kroku "Send an email (V2)". Błąd: "SMTP authentication failed". Okazało się, że skrzynka serwisowa, na której działał łącznik, miała włączone MFA i token wygasł trzy tygodnie wcześniej. Nikt w firmie nie wiedział, bo nikt nie przeglądał historii. Asystent wyłapał to przy pierwszym przeglądzie.

Przepływy, które milczą od za długo. Oprócz przepływów z błędami są przepływy, które nie uruchomiły się od np. 14 dni, choć powinny działać cyklicznie. Pole lastRunTime dla każdego przepływu pozwala wyłapać te, które "zasnęły" bez błędu, bo np. trigger przestał otrzymywać dane wejściowe albo ktoś wyłączył przepływ i zapomniał go włączyć.

Odpowiedzi na pytania o dane w Dataverse. "Ile mamy otwartych spraw serwisowych z priorytetem 1 przypisanych do Kowalskiego?" AI odpytuje tabelę incidents z filtrem statecode eq 0 and prioritycode eq 1 i warunkiem na właściciela, dostaje liczbę i wraca z odpowiedzią. Bez budowania raportu, bez czekania na IT.

Kroki, które dziś zatrzymują się na człowieku: formularze, maile i zatwierdzenia

Power Automate świetnie radzi sobie z logiką warunkową. Ale jest kategoria kroków, gdzie warunek nie wystarczy: trzeba ocenić, zrozumieć albo sklasyfikować tekst.

Zatwierdzanie z dokumentem PDF. Przepływ wysyła prośbę o zatwierdzenie do kierownika z załączonym zamówieniem. Kierownik musi przeczytać PDF, ocenić pozycje, zdecydować. Przy powtarzalnych zamówieniach AI może to zrobić: pobrać PDF przez Graph API (jeśli jest w SharePoint), odczytać treść, sprawdzić wg kryteriów firmy (producent na liście zatwierdzonych, kwota w limicie działu, opis pasuje do budżetu projektu), i albo zatwierdzić automatycznie, albo dać kierownikowi gotowe podsumowanie z rekomendacją zamiast surowego pliku.

Formularz Power Apps z opisem problemu. Pracownik w terenie wypełnia formularz serwisowy. Pole "Opis usterki" to wolny tekst. Dziś trafia do kolejki i ktoś musi to przeczytać, żeby przypisać priorytet i dział. AI klasyfikuje opis, przypisuje tagi, ustawia pole priorytet i kieruje do właściwej kolejki. Bez człowieka w środku.

Maile przychodzące jako trigger. Wiele przepływów startuje od maila: "Gdy mail trafi do folderu Zlecenia, utwórz rekord". Typowo przepływ tworzy pusty rekord albo kopiuje temat maila do pola Tytuł. AI może przeczytać treść maila, wyciągnąć z niej dane (numer zamówienia, ilość, termin, dane kontrahenta), uzupełnić odpowiednie pola rekordu w Dataverse i przypisać właściciela. Krok, który wcześniej kończył się na człowieku z notatnikiem, teraz idzie dalej automatycznie.

Kiedy Power Automate wystarcza, a kiedy lepiej asystent na własnym serwerze

To pytanie pada na każdym wdrożeniu. Dobrze, że pada.

Power Automate wystarcza, gdy logika jest przewidywalna i da się ją zapisać jako warunki. Jeśli faktura jest powyżej X, idzie do Y. Nowe zamówienie w Dataverse: wyślij mail. Data płatności minęła: zmień status. Przepływy zbudowane na takich warunkach będą działać przez lata bez AI.

Power Automate ma też wbudowany AI Builder: gotowe modele do ekstrakcji danych z faktur, formularzy i kart wizytowych. Jeśli firma przetwarza faktury w standardowym formacie i nie ma szczególnych wymagań co do poufności danych, AI Builder jest prostym startem. Jest jednak droższy niż standardowy plan, a dane przechodzą przez infrastrukturę Microsoft Azure AI.

Asystent na własnym serwerze ma sens w kilku sytuacjach:

• Firma przetwarza dane, które nie powinny wychodzić poza własny serwer: dane medyczne, umowy z klauzulami poufności, dane osobowe klientów w wrażliwych branżach.
• Logika wymaga oceny i kontekstu, a nie tylko warunku: "czy ta reklamacja jest zasadna", "czy ten opis pasuje do kategorii krytycznej", "co odpowiedzieć klientowi na tę wiadomość".
• Firma chce jednego asystenta, który "wie" o wszystkich procesach: Dataverse, SharePoint, przepływy, zamówienia, serwis, finanse. Nie dziesiątek osobnych przepływów AI, tylko jeden punkt kontaktu dla całego zespołu.
• Pracownicy chcą zadawać pytania o dane po polsku, bez kliknięć w Power BI: "Jaki był wynik serwisowy w październiku?" albo "Kto ma najwięcej otwartych zleceń?"
• Firma chce, żeby zarząd mógł zapytać asystenta o status operacji bez angażowania IT przy każdym pytaniu. Dziś: zarząd pyta, IT otwiera Power Automate, klika przez historię, pisze maila. Z asystentem: zarząd pyta wprost, asystent odpytuje API i odpowiada w ciągu minuty.

Obie rzeczy mogą współpracować. Przepływy Power Automate zostają i robią to, co robią dobrze: wyzwalają zdarzenia, przesyłają dane, wywołują akcje. Gdy przepływ natrafi na krok wymagający oceny albo odpowiedzi w języku naturalnym, wywołuje asystenta przez HTTP POST, dostaje odpowiedź i jedzie dalej. Asystent jest tu serwisem, który Power Automate woła, a nie zamiennikiem całego środowiska.

Od czego zaczynamy

Zaczynamy od audytu. Asystent odpytuje Power Automate Management API i generuje listę wszystkich przepływów w środowisku z ich statusem, właścicielem, datą ostatniego uruchomienia i liczbą błędów z ostatnich 30 dni. Z tej listy wybieramy przepływy z najwyższą częstotliwością błędów albo te, które przetwarzają dane krytyczne dla firmy.

Dla tych przepływów asystent przygotowuje dokumentację: co robi, kto jest właścicielem, jakie tabele Dataverse lub listy SharePoint dotyka, jak często normalnie się uruchamia. To, co kiedyś wymagało rozmowy z Tomkiem, teraz powstaje automatycznie.

Kolejny krok to alerty. Asystent raz dziennie sprawdza runHistory i przesyła podsumowanie do wskazanego czatu Teams albo na mail: "3 przepływy miały błędy, 1 nie uruchomił się od 10 dni, 1 nowy właściciel nie jest już w firmie". Bez klikania, bez ręcznego przeglądu.

Potem można rozszerzyć: odpowiedzi na pytania o Dataverse, obsługa kroków zatwierdzania, klasyfikacja formularzy z Power Apps. Każda funkcja to osobny moduł asystenta podłączony do tego samego API.

Jeśli chcecie zobaczyć, jak taki audyt wygląda na prawdziwych przepływach i danych Waszej firmy, zapraszamy na 15 minut rozmowy. Mamy też realne wdrożenia, w tym firmy, które zaczęły od przeglądu przepływów Power Automate i dziś mają asystenta odpowiadającego na pytania o operacje całej organizacji.