W poprzednim odcinku cyklu przygotowaliśmy listę SharePoint jako fundament systemu zgłoszeń IT. Teraz przyszedł czas na „silnik" całego rozwiązania — dwa przepływy Power Automate, które sprawią, że system zacznie żyć własnym życiem. Jeden będzie przechwytywał zgłoszenia przychodzące mailem, drugi informował użytkowników o zmianach statusu ich zgłoszeń.
Pierwszy przepływ: zgłoszenie z maila trafia prosto do systemu
Punktem wejścia jest trigger reagujący na nową wiadomość e-mail. W realiach firmowych byłaby to wspólna skrzynka działu IT (np. pomoc-it@firma.pl) — w wersji demonstracyjnej używamy skrzynki prywatnej, ale mechanizm jest identyczny.
Przepływ wykonuje dwa zadania jednocześnie:
- Tworzy wpis na liście SharePoint — temat maila staje się tematem zgłoszenia, a podgląd treści trafia do pola opisu.
- Wysyła powiadomienie do działu IT — od razu w mailu widać numer zgłoszenia (ID elementu), temat, opis oraz adres nadawcy. Dział IT nie musi zaglądać do listy, żeby wiedzieć, co wpłynęło.
Konfiguracja jest prosta: w akcji SharePoint „Create item" mapujemy dynamiczne wartości z triggera mailowego na odpowiednie kolumny listy. Całość zajmuje kilka minut i nie wymaga żadnego kodu.
Connection references — czemu warto o nich wiedzieć
Pracując w ramach solucji (solution), Power Automate automatycznie tworzy tzw. connection references — osobne obiekty przechowujące dane połączeń z zewnętrznymi usługami (skrzynka mailowa, SharePoint). Dlaczego to ważne?
- Połączenia są wydzielone z logiki przepływu — widać z jakich kont korzysta rozwiązanie.
- Przy przenoszeniu rozwiązania między środowiskami (dev → test → prod) można podmienić connection reference bez ruszania logiki przepływu.
- Jedno połączenie może być współdzielone przez wiele przepływów w tej samej solucji.
Drugi przepływ: powiadomienie o zmianie statusu
Samo zbieranie zgłoszeń to za mało — użytkownik chce wiedzieć, kiedy ktoś zajął się jego problemem. Tu pojawia się drugi automat, który reaguje na modyfikację elementu na liście SharePoint.
Wyzwanie polega na tym, że trigger „element zmieniony" odpala się przy każdej edycji — czy ktoś zmienił status, czy tylko dopisał notatkę. Żeby nie zasypywać użytkowników zbędnymi mailami, stosujemy dwie techniki:
- Dodatkowa kolumna „Stary status" na liście — przechowuje poprzednią wartość statusu.
- Warunek w triggerze (trigger conditions) — przepływ uruchamia się tylko wtedy, gdy element faktycznie został zmodyfikowany (a nie stworzony).
Dalej przepływ sprawdza w warunku (Condition), czy wartość pola Status różni się od wartości pola Stary status. Jeśli nie — przepływ kończy się statusem „Cancelled", bez wysyłki maila. Jeśli tak — użytkownik dostaje powiadomienie z numerem zgłoszenia, tematem, opisem i nowym statusem.
Testowanie przepływów — dobre praktyki
Power Automate oferuje dwa tryby testowania: manualny (czekamy na rzeczywiste zdarzenie) i automatyczny (korzystamy z danych poprzedniego wykonania). Oba są przydatne na różnych etapach:
- Test manualny — idealny na początku, gdy chcemy zobaczyć jak przepływ reaguje na prawdziwe dane.
- Test z wcześniejszymi danymi — szybszy przy poprawkach logiki, bo nie trzeba ręcznie generować zdarzenia triggera.
Po uruchomieniu pierwszego przepływu warto od razu sprawdzić, czy na liście SharePoint pojawił się nowy wpis oraz czy w skrzynce działu IT wylądował mail powitalny. Dla drugiego przepływu testy należy przeprowadzić dwukrotnie: raz zmieniając inną kolumnę (np. priorytet) — przepływ powinien anulować się bez wysyłki; drugi raz zmieniając faktyczny status — mail powinien trafić do zgłaszającego.
Podsumowanie: co zbudowaliśmy
Po tym odcinku system zgłoszeń IT ma działający backend — dwa przepływy, które obsługują cały cykl komunikacji:
- Nowe zgłoszenie mailowe → wpis na liście + alert do IT.
- Zmiana statusu zgłoszenia → mail do użytkownika z informacją o postępie.
W kolejnym odcinku zbudujemy warstwę interfejsu użytkownika — aplikację Power Apps, dzięki której dział IT będzie mógł przeglądać zgłoszenia, filtrować je według statusu i aktualizować dane bezpośrednio w przeglądarce.