Agenci AI [5/6] – Automatyzacja procesów w środowisku enterprise: Make.com vs Power Automate (część 1)

Z pierwszego wpisu tej serii dowiedziałeś się, jakie procesy biznesowe możesz relatywnie łatwo wesprzeć sztuczną inteligencją. Kolejne trzy wpisy były coraz bardziej praktyczne — od przeglądu narzędzi po konkretny tutorial krok po kroku pokazujący, jak zbudować własnego agenta AI (część I + część II). Na platformie Make.com budowaliśmy agenta AI do zastosowań osobistych, którego jednak bez problemu można przenieść do realiów biznesowych.

Make.com to bardzo elastyczne narzędzie, które pozwala integrować ze sobą tysiące różnych aplikacji i narzędzi od różnych dostawców. Świetnie sprawdza się w mniejszych firmach i startupach.

Co jeśli procesy Twojej firmy opierają się na Microsoft 365? Jeśli Twoja firma żyje w Excelu i Teamsach — Copilot Studio i Power Automate to naturalny wybór. Takie podejście umożliwia automatyzację wewnątrz ekosystemu MS Office, zapewniając przy tym korporacyjny standard bezpieczeństwa danych z najwyższymi certyfikatami. Dla średnich i dużych przedsiębiorstw poruszanie się w ramach ekosystemu Microsoft 365 może być jedyną dostępną opcją budowania własnych automatyzacji. 

Power Automate to narzędzie z pakietu MS Office, które umożliwia tworzenie automatycznych przepływów. Trochę tak, jak w Make.com z tym, że tutaj poruszamy się głównie po ekosystemie Microsoft, mamy mniejszą elastyczność i nieco “cięższy” interfejs. 

W Make.com budowaliśmy agenta AI jako cross-platformowe narzędzie osobiste.

Teraz wykorzystamy Power Automate, aby zbudować podobnego agenta koncepcyjnie, ale osadzonego w procesie biznesowym.

Architektura

Na początek krótkie przedstawienie narzędzia, które zbudujemy. Będzie to Agent AI do kategoryzowania i archiwizowania dokumentów. “Gubiące się” dokumenty to powszechny problem w wielu organizacjach. Jeśli problem np. brakujących faktur pod koniec miesiąca jest Ci znany — rozwiązanie, które tutaj zaprezentuję, powinno Cię zainteresować.

Idea jest następująca: Na dedykowany kanał Teams przesyłamy dowolne dokumenty, które “przechodzą nam przez ręce” w trakcie dnia — faktury, instrukcje itd. Dokumenty są analizowane przez asystenta AI, który określa kategorię dokumentu, generuje opis, słowa kluczowe oraz nazwę pliku. Następnie plik zapisywany jest na OneDrive w katalogu odpowiednim dla zdefiniowanej kategorii oraz wysyłany mailem do konkretnej grupy odbiorców (np. faktury trafiają do księgowości itd.). 

Automatyzacja konfigurowana jest przez plik Excel — tutaj znajdują się wszystkie kategorie dokumentów wraz z przypisanymi adresami email. Edycja kategorii w pliku przekłada się na output Asystenta AI. W pliku Excel prowadzona jest również ewidencja wszystkich zapisanych w ten sposób dokumentów (aby np. odnaleźć je łatwo po słowach kluczowych).

Na koniec na Teams pojawia się potwierdzenie przeprowadzonych operacji.

Przepływ w Power Automate będzie wyglądał mniej więcej tak:

1. “Przechwycenie” załączników z plikami przesłanymi na specjalny kanał w Microsoft Teams.
2. Odczytanie tabeli w Excelu z nazwami kategorii dokumentów oraz przypisanych do nich adresów e-mail.
3. Odczytanie zawartości dokumentu za pomocą narzędzia OCR.
4. Analiza dokumentu przez AI. Korzystamy z asystenta GPT, dla którego danymi wejściowymi jest lista kategorii oraz tekst dokumentu (odczytany przez OCR).
5. Zapisanie pliku w katalogu o nazwie odpowiadającej kategorii.
6. Dodanie wpisu do tabeli z rejestrem wszystkich plików.
7. Odczytanie adresu E-mail właściwego dla danej kategorii.
8. Wysłanie maila, jeśli adres E-mail był podany w pliku.
9. Potwierdzenie na Teams o zakończeniu przetwarzania dokumentu.

Po dotychczasowym doświadczeniu z Make może Ci się wydawać, że zadanie to nie jest specjalnie skomplikowane. Trzymając się analogii z poprzednich wpisów, można by powiedzieć, że wystarczy połączyć ze sobą (i skonfigurować) kilka klocków LEGO.

W praktyce Make i Power Automate to dwa różne narzędzia. Przeskakując z jednego w drugie, możesz na początku czuć się lekko zagubiony.

Start-upowy Make vs. enterprisowy Power Automate

Jeśli masz już doświadczenie z Make.com, wejście w Power Automate może być… zaskakujące. Nie dlatego, że jedno narzędzie jest „lepsze” od drugiego — tylko dlatego, że są projektowane z zupełnie inną filozofią.

Na pierwszy rzut oka oba rozwiązania robią to samo: łączą aplikacje, reagują na zdarzenia, przerzucają dane między systemami. W praktyce jednak Make i Power Automate grają w dwóch różnych ligach.

Low-code, ale nie low-complexity

Make.com to narzędzie, które świetnie wpisuje się w realia startupowe. Pracujesz na payloadach, webhookach i prostych strukturach danych. Masz URL → pobierasz plik → robisz z nim, co chcesz. Wszystko jest namacalne, łatwe do podejrzenia i debugowania.

Power Automate działa inaczej. Tu nie tyle pracujesz na danych, tylko — w pewnym sensie — na zasobach.

Plik nie jest „plikiem”, tylko tożsamością zasobu w SharePoint. Załącznik z Teamsa nie jest fizycznie przesyłany w workflow — dostajesz jedynie informację, że gdzieś w SharePoint istnieje obiekt, do którego musisz się poprawnie odwołać.

I to jest pierwsze zderzenie z rzeczywistością enterprise.

Zasoby zamiast payloadów

Akcje, które w UI wyglądają niewinnie („Get file content”, „Convert Word document to PDF”), są w rzeczywistości cienką nakładką na Microsoft Graph API. Jeśli nie rozumiesz, jak Graph identyfikuje zasoby — zaczynają się schody.

W dużym uproszczeniu: Graph API to wspólny interfejs, przez który Power Automate komunikuje się z usługami Microsoft 365 — SharePointem, OneDrive’em, Teamsem, Excelem. Każda akcja w Power Automate („Get file content”, „Convert Word document to PDF”) jest w rzeczywistości wywołaniem konkretnej metody tego API.

Problem w tym, że Graph nie identyfikuje plików „po ludzku”. Nie interesuje go nazwa ani to, że plik „przyszedł z Teamsa”. Liczy się tożsamość zasobu i jego dokładne umiejscowienie w strukturze SharePointa.

Do tego dochodzi pojęcie tenanta — czyli izolowanego środowiska Twojej organizacji w Microsoft 365. Każdy tenant ma własne identyfikatory zasobów, własne polityki bezpieczeństwa i własne ograniczenia. To, co działa w jednym środowisku, może nie zadziałać w innym, mimo identycznej konfiguracji w UI.

Efekt?
To samo działanie w Power Automate da się skonfigurować na kilka różnych sposobów — ale tylko jeden z nich faktycznie zadziała w Twoim konkretnym tenancie.

I to jest moment, w którym definitywnie kończy się „układamy klocki”, a zaczyna inżynieria.

Power Automate wymaga innego sposobu myślenia

Projektując ten agent AI, bardzo szybko zrozumiałem jedną rzecz: Power Automate nie wybacza „intuicyjnego klikania”.

Tutaj trzeba:

• świadomie parsować JSON-y zamiast polegać na dynamic content
• rozdzielać dane runtime od danych konfiguracyjnych
• upraszczać architekturę, nawet kosztem „elegancji”
• testować każdy krok osobno, bo UI nie zawsze mówi prawdę
  

To nie jest narzędzie do szybkich demo. To jest narzędzie do procesów, które mają działać miesiącami w środowisku korporacyjnym.

Dlaczego mimo wszystko Power Automate?

Bo w zamian dostajesz coś, czego Make.com nie oferuje na tym poziomie:

• pełną integrację z Microsoft 365
• bezpieczeństwo danych zgodne z politykami enterprise
• pracę wewnątrz jednego tenanta
• możliwość budowania automatyzacji jako elementu procesu biznesowego, a nie osobnego bytu

Jeśli Twoja firma „żyje w Excelu i Teamsach”, Power Automate nie jest opcją — jest naturalnym wyborem.

Zanim zaczniemy

Jeśli przychodzisz z Make.com, pierwsze dni z Power Automate mogą być frustrujące.
I to jest normalne.

To nie jest kwestia umiejętności.
To jest kwestia przestawienia sposobu myślenia — z automatyzacji „narzędzi” na automatyzację „zasobów i procesów”.

W dalszych rozdziałach pokażę, jak świadomie uprościłem architekturę tego agenta AI, gdzie odpuściłem „ładne” rozwiązania na rzecz stabilnego MVP i co zrobiłbym inaczej w wersji produkcyjnej.

Skoro wiemy już, z jakim typem narzędzia mamy do czynienia, czas zejść poziom niżej.

W kolejnym rozdziale nie będziemy jeszcze budować agenta krok po kroku. Zamiast tego zrobię krótkie wprowadzenie techniczne do Power Automate — tak, żebyś wiedział:

• jak myśleć o przepływach,
• czym są konektory i akcje,

Ten fragment potraktuj jak mapę terenu przed wejściem w góry.
Nie musisz zapamiętać wszystkiego — wystarczy, że będziesz się orientować w interfejsie Power Automate.

Dopiero potem przejdziemy do właściwej budowy agenta AI.

Wprowadzenie techniczne do Power Automate

Zanim zaczniemy budować agenta AI, warto na chwilę zatrzymać się przy samym Power Automate. Głównie po to, żeby zrozumieć jak Microsoft myśli o automatyzacjach i gdzie w tym wszystkim jesteśmy my jako autorzy przepływów.

Power Automate działa w ramach Microsoft 365. Najprostsza droga to: https://make.powerautomate.com

Po zalogowaniu trafiasz do panelu głównego, który — w zależności od uprawnień w Twoim tenancie — może wyglądać mniej lub bardziej „korporacyjnie”. Już na tym etapie widać pierwszą różnicę względem Make.com: Power Automate nie jest osobnym produktem, tylko częścią większego ekosystemu.

Connections, czyli uprawnienia

Zanim jakikolwiek przepływ zacznie działać, Power Automate musi wiedzieć w czyim imieniu wykonuje akcje. Służą do tego tzw. connections.

Connection to nic innego jak zapisane połączenie z daną usługą — np. SharePoint, Teams, Excel, OneDrive. Przy pierwszym użyciu konektora Power Automate poprosi Cię o zalogowanie się i nadanie odpowiednich uprawnień.

Warto zapamiętać, że connections są współdzielone w obrębie środowiska (environment), a więc — raz dodane — będą działać dla wszystkich Twoich przepływów.

Cloud flows vs Desktop flows

Power Automate oferuje kilka typów automatyzacji, ale w kontekście agentów AI interesują nas głównie Cloud flows.

• Cloud flows — automatyzacje uruchamiane w chmurze, reagujące na zdarzenia (np. wiadomość w Teams, nowy plik w SharePoint).
• Desktop flows — automatyzacje typu RPA, sterujące aplikacjami na komputerze użytkownika.

W tym artykule (i całej serii) skupiamy się wyłącznie na Cloud flows. Desktop flows to zupełnie inna kategoria problemów i narzędzi.

Tworzenie przepływu i triggery

Każdy Cloud flow zaczyna się od triggera — zdarzenia, które uruchamia przepływ.

Power Automate oferuje kilka głównych typów triggerów:

• Automated — reagują na zdarzenia (np. „When a new message is added to a channel” w Teams),
• Instant — uruchamiane ręcznie (przycisk, Power Apps),
• Scheduled — uruchamiane cyklicznie (harmonogram).

Trigger definiuje kontekst wejściowy całego przepływu. To on dostarcza pierwsze dane, na których później pracujesz. Warto pamiętać, że nie każdy trigger zwraca komplet informacji — często jest to tylko „sygnał”, że coś się wydarzyło, a szczegóły trzeba pobrać w kolejnych akcjach.

Akcje — co tak naprawdę robimy w flow

Po triggerze dodajemy akcje. Akcja to pojedynczy krok, który:

• pobiera dane,
• przetwarza dane,
• zapisuje dane,
• albo wywołuje inną usługę.

Każda akcja pochodzi z konkretnego konektora (SharePoint, Teams, Excel itd.) i — co istotne — jest mapowaniem na konkretną operację API. W UI wygląda to jak proste formularze, ale pod spodem Power Automate buduje wywołania do Microsoft Graph lub innych backendów.

Konfigurując akcje spotkasz się z pojęciami dynamic content oraz expressions. Będą to zazwyczaj dwie ikonki przy polach do wprowadzania danych (rys. 1).

Dynamic content to dane wyjściowe z poprzednich kroków, które możesz wstrzykiwać do kolejnych akcji.

Dynamic content działa świetnie… dopóki działa.

W momencie, gdy:

• dane są zagnieżdżone,
• pracujesz na tablicach (arrays),
• albo musisz coś przekształcić,

wchodzisz w świat Expressions.

Expressions to wbudowany język wyrażeń Power Automate, inspirowany Azure Logic Apps. To tutaj pojawiają się funkcje typu:

• split()
• join()
• equals()
• contains()
• body()
• items()

W praktyce większość bardziej złożonych przepływów łączy oba podejścia: dynamic content tam, gdzie się da — expressions tam, gdzie trzeba.

Testowanie przepływów

Power Automate pozwala testować przepływy bezpośrednio z poziomu edytora (ikonka w górnym prawym rogu ekranu). Po uruchomieniu testu dostajesz pełną historię wykonania:

• które akcje się wykonały,
• jakie miały inputy,
• jakie zwróciły outputy.

To absolutnie kluczowe narzędzie pracy — szczególnie w środowisku, gdzie wiele rzeczy dzieje się „pod maską”.

W kontekście debugowania jedna z najbardziej użytecznych funkcji Power Automate to możliwość skopiowania całego body akcji do schowka po wykonaniu przepływu (rys. 2).

Po teście możesz:

1. wejść w szczegóły akcji,
2. skopiować body,
3. wkleić je do dowolnego JSON formattera online.

To pozwala:

• zobaczyć pełną strukturę danych,
• zrozumieć, dlaczego coś nie pojawia się w dynamic content,
• przygotować poprawny schema do akcji Parse JSON.

Takie podejście oszczędza ogromną ilość czasu i frustracji.

W sekcji My flows znajdziesz listę wszystkich utworzonych przepływów. Po kliknięciu w wybrany flow przechodzisz do widoku jego zarządzania, gdzie dostępna jest m.in. historia uruchomień (rys. 3).

Każde uruchomienie można rozwinąć, aby zobaczyć status wykonania poszczególnych akcji i dokładnie prześledzić, jak zachowywała się automatyzacja krok po kroku.

Podstawowe akcje, które warto znać

Na potrzeby budowy agenta AI w Power Automate będziemy regularnie korzystać z kilku podstawowych akcji:

• Initialize variable / Set variable — do przechowywania danych w trakcie przepływu,
• Parse JSON — do pracy z odpowiedziami API i zagnieżdżonymi strukturami,
• Condition — klasyczne if/else,
• Apply to each — pętla po elementach tablicy.

Warto zwrócić uwagę na jedną rzecz:
Power Automate automatycznie dodaje pętlę Apply to each, jeśli użyjesz dynamic content, który jest tablicą (array). Czasami jest to dokładnie to, czego potrzebujesz — a czasami źródło nieporozumień. Dobrze wiedzieć, że to zachowanie jest intencjonalne.

Kilka słów na koniec

Power Automate nie jest trudny — ale jest inny.
Im szybciej zaakceptujesz, że:

• pracujesz na zasobach,
• UI jest tylko uproszczonym widokiem na API,
• a debugowanie to codzienność,

tym łatwiej będzie Ci budować stabilne automatyzacje.

Jeśli interesuje Cię przede wszystkim praktyka, poniżej zaczynamy budowę przepływu krok po kroku — wcześniejsza część ma dać Ci kontekst, dlaczego w Power Automate pewne rzeczy robi się inaczej.

W kolejnym rozdziale przejdziemy już do praktyki i zaczniemy składać pierwsze elementy naszego agenta AI — krok po kroku, świadomie upraszczając architekturę tam, gdzie ma to sens.

Jak zbudować inteligentny przepływ dokumentów w Power Automate — część praktyczna

Po solidnym wprowadzeniu teoretycznym przejdźmy płynnie do najefektywniejszej formy nauki, jaką niewątpliwie jest praktyka. Wpis o Power Automate będzie składał się z dwóch części — tej i jeszcze kolejnej, która zamknie całą serię o Agentach AI. 

W części pierwszej zajmiemy się utworzeniem i skonfigurowaniem triggera, przechwyceniem dokumentów z wiadomości uruchamiającej przepływ. Już ten pierwszy etap doskonale zobrazuje całą specyfikę Power Automate, o której pisałem wcześniej. Będzie to też solidny fundament i dobry punkt wyjścia do tematów, którymi zajmiemy się w części drugiej, a więc m.in: dołączenie OCR i sztucznej inteligencji oraz praca z plikami Excel.

Przechwycenie linków dokumentów z triggera

Zacznij od utworzenia osobnego kanału w Microsoft Teams — tutaj będziemy przekazywać dokumenty do agenta. Teraz utwórz pierwszy przepływ (New Flow → Automated Cloud flow) i dodaj trigger z konektora Microsoft Teams — When a new message is added to a chat or channel. W parametrach wyzwalacza wybierz:

• Message type — Channel,
• Kanały — utworzony wcześniej kanał Teams,
• Zespół — nazwa grupy, do której przypisany jest kanał.

Na początku Power Automate poprosi Cię zapewne o utworzenie połączenia ze swoim kontem Microsoft Teams. Jak się zalogujesz, wszystkie dane powinny dać się uzupełnić za pomocą list rozwijanych. 

Zdarza się, że listy rozwijane nie są dostępne od razu. Czasami trzeba chwilę poczekać/zapisać flow/wyłączyć i włączyć — jednym słowem: pokombinować. Niestety, Power Automate jest pod tym względem nieco kapryśny — przynajmniej u mnie.

Zanim przetestujesz działanie triggera dodaj jeszcze jedną akcję — Initialize variable: nazwa zmiennej: trigger_msg_id, typ: String, wartość: zostaje pusta. Teraz zrób test: wejdź w tryb testowania ikonką w prawym górnym rogu ekranu, a następnie prześlij dowolny plik na kanał Teams skojarzony z triggerem. Przepływ powinien wykonać się błyskawicznie. W sekcji OUTPUT możesz podejrzeć body triggera — możesz je też skopiować w formacie JSON i odczytać dane w narzędziu typu JSON formatter (rys. 5).

Do części elementów z body akcji, można się w kolejnych krokach odwoływać poprzez Dynamic content. Nas interesują załączniki. Intuicja podpowiada, że w kolejnym kroku po prostu je pobierzemy do dalszej analizy. W Make.com pewnie tak by to wyglądało.

Niestety, na wyjściu triggera nie ma informacji o załącznikach. Jest za to messageId, z którego skorzystamy. To doskonale pokazuje specyfikę pracy z Power Automate oraz tego jak narzędzie to odwołuje się do tożsamości zasobów znajdujących się w różnych częściach ekosystemu Microsoft.

Zapisz ID wiadomości do zmiennej trigger_msg_id korzystając z akcji Set variable. Dokonasz tego wybierając Identyfikator komunikatu przez Dynamic content (rys. 6).

Zwróć uwagę na dwie rzeczy:

• Akcja Set variable automatycznie została “zapakowana” w pętlę For each, ponieważ messageId jest zagnieżdżone w zakresie value (wszystko widać na rys. 5) — to niuans techniczny, którym nie musisz się przejmować.
• Identyfikator komunikatu to polskie tłumaczenie. Ustawiając kursor na tym obiekcie zobaczysz rzeczywistą nazwę klucza, który zawiera się w wyrażeniu: item()?[‘messageId’] — item() odwołuje się do elementu zakresu, po którym przeprowadzamy iterację pętlą For each.

Myślę, że ten etap mamy wyjaśniony. Idziemy dalej już bez takiej drobiazgowości. Kontynuujemy poszukiwania załączników naszej wiadomości. Wykorzystamy w tym celu akcję Get message details. Dodaj teraz cztery kolejne akcje:

• Initialize variable — nazwa: attachments, typ: array, wartość: brak
• Initialize variable — nazwa: content_links, typ: array, wartość: brak
• Get message details — Message: trigger_msg_id, pozostała konfiguracja analogicznie jak w przypadku triggera.
• Set variable —  do zmiennej attachments przypisz JSON spod klucza attachments, z OUTPUT-u Get message details. Za pomocą Insert expression wstaw takie wyrażenie: body('Get_message_details')?['attachments']

Teraz kilka słów wyjaśnienia, co tutaj się wydarzyło. Analizując OUTPUT z Get message details można wywnioskować, że do zmiennej attachments zapisaliśmy tak naprawdę tablicę (dlatego typ zmiennej to array) JSON’ów o takiej strukturze:

[
    {
      "id": "8a2488a6-643c-4694-be81-a99e92fce7e6",
      "contentType": "reference",
      "contentUrl": "https://companyname.sharepoint.com/teams/pih_prod-DocuAssistantInput/Freigegebene Dokumente/DocuAssistantInput/Database_Management_System_Documentation_CompanyApp_v2.1.docx",
      "content": null,
      "name": "Database_Management_System_Documentation_CompanyApp_v2.1.docx",
      "thumbnailUrl": null,
      "teamsAppId": null
    }
]

Z powyższych danych szczególnie interesuje nas contentUrl, czyli link do pliku, który po przesłaniu na kanał Teams automatycznie zapisał się na Share Point. Po raz kolejny mamy przyjemność doświadczyć specyfiki Power Automate — dostajemy link, a nie plik. Ale link to już coś, z linkiem coś zrobimy.

Niestety, jesteśmy dopiero w połowie drogi do stworzenia tablicy z linkami. Za moment wyjaśnię, dlaczego potrzebowaliśmy aż tylu kroków, ale najpierw dokończymy tę część przepływu. Dodaj dwie akcje:

• Parse JSON — content: zmienna attachments, schemat danych: wygeneruj na podstawie próbki znajdującej się powyżej. Ważne: skopiuj te dane razem z zewnętrznymi nawiasami kwadratowymi, ponieważ wynikiem ma być tablica danych z osobnym elementem, dla każdego załącznika.
• Append to array variable — do zmiennej content_links dodaj contentUrl z poprzedniej akcji. Tutaj Power Automate znów powinien automatycznie “owinąć” tę akcję w For each, o ile Parse JSON jest skonfigurowana poprawnie. Dzięki temu wszystkie linki contentUrl zostaną dodane do tablicy.

Dlaczego korzystałem z akcji Parse JSON? Ponieważ UI Power Automate nie pozwalał odwoływać się do attachments oraz contentUrl z Get message details za pomocą Dynamic content. Teraz wszystkie pola, które zostały zdefiniowane w Parse JSON możemy dynamicznie wykorzystywać w dalszej części automatyzacji. 

Ten przykład dokładnie pokazuje, jak ważna jest tutaj świadoma praca z tym, co dzieje się “pod spodem” i nie poleganie tylko na tym co “da się kliknąć”. Zapewne też nie wszystkie zmienne wykorzystane w przepływie są niezbędne. Wydaje mi się jednak, że zwiększają one czytelność przepływu — szczególnie dla osób początkujących.

Na koniec zadbajmy jeszcze o to, żeby przepływ zakończył działanie, jeśli wiadomość z triggera nie zawiera żadnych załączników.

Dodaj akcję Condition, gdzie za pomocą wyrażenia: length(variables('content_links')) sprawdzisz, czy zmienna content_links jest pusta (less or equal to 0). Jeśli tak za pomocą akcji Terminate zakończ program (ze statusem Succeeded). Cały przepływ powinien wyglądać mniej więcej tak:

Na tym zakończę część praktyczną w tym artykule.

Możesz teraz przetestować przepływ wysyłając wiadomości z oraz bez załączników.

Wskazówka: Możesz przetestować przepływ w trybie automatycznym na poprzednich danych: Test → Automatically → With a recently used trigger.

Podsumowanie

Mam nadzieję, że ten wpis pokazał Ci czym jest Power Automate. Myślę, że część praktyczna była świetnym uzupełnieniem teorii od której wyszedłem. Rozumiem, że pierwsze zderzenie ze specyfiką Power Automate może być wyzwaniem. 

Dobra wiadomość jest taka, że jeśli rozumiesz przepływ zbudowany w tym tutorialu dalej będzie tylko łatwiej. Zachęcam Cię więc do jego samodzielnego przeanalizowania.

W kolejnej części — a zarazem ostatnim wpisie całej serii o Agentach AI — dokończymy ten przepływ dodając elementy AI, OCR i inne. Tam też będzie miejsce na podsumowanie dwóch części o Power Automate. Już teraz zapraszam do lektury i życzę powodzenia we wdrażaniu własnych automatyzacji!