Power Automate: wzorzec „kompensacji” (undo) w procesach — jak cofać zmiany bez ręcznego sprzątania

1. Czym jest wzorzec „kompensacji” (undo) i dlaczego warto go stosować

Wzorzec kompensacji (często nazywany też „undo”) to sposób projektowania procesu w Power Automate, w którym dla kluczowych kroków przewidujesz działania odwracające skutki wykonanych operacji. Zamiast liczyć na „transakcyjność” (czyli automatyczne wycofanie wszystkiego, gdy coś pójdzie nie tak), zakładasz, że proces może zatrzymać się w połowie, a Ty nadal chcesz móc wrócić do spójnego stanu bez ręcznego sprzątania.

W praktyce oznacza to, że gdy przepływ wykona serię zmian w różnych miejscach (np. pliki, listy, wpisy, zadania, rekordy, powiadomienia), a potem pojawi się błąd lub warunek unieważniający operację, proces uruchamia kontrolowane cofanie tego, co zdążył już zrobić — w zakresie, w jakim to możliwe i potrzebne.

Warto odróżnić kompensację od prostego „obsłużenia błędu”. Obsługa błędu często kończy się wysłaniem alertu i zatrzymaniem przepływu. Kompensacja idzie krok dalej: przywraca porządek w systemach dotkniętych procesem, tak aby nie zostawiać „pół-produktów” automatyzacji.

Po co to w Power Automate?

Power Automate bardzo często łączy wiele usług, które nie działają jak jedna wspólna baza danych z mechanizmem transakcji. W rezultacie:

• część kroków może wykonać się poprawnie, a kolejny się wywróci (i wcześniejszych zmian nie da się automatycznie cofnąć „magicznie”),
• przepływ może zostać przerwany przez limity, uprawnienia, chwilowe błędy połączeń lub walidacje biznesowe,
• proces może utworzyć lub zmodyfikować zasoby, które potem blokują kolejne próby (np. duplikaty, niekompletne rekordy, błędne statusy).

Wzorzec kompensacji pozwala zaplanować takie sytuacje i zminimalizować chaos po nieudanych uruchomieniach.

Co dokładnie „cofamy” w kompensacji?

Nie chodzi wyłącznie o „usunąć to, co utworzyliśmy”. Kompensacja może oznaczać również:

• przywrócenie poprzedniej wartości (np. statusu, właściciela, przypisania),
• wycofanie publikacji lub oznaczenie czegoś jako nieważne,
• odłączenie powiązań (np. relacji między rekordami),
• zrobienie kroku korygującego, który neutralizuje skutki uboczne (np. wysłanie sprostowania, anulowanie zadania).

Kluczowe jest, że kompensacja jest świadomie zaprojektowanym elementem procesu, a nie improwizacją, gdy pojawi się problem.

Dlaczego warto stosować ten wzorzec

• Mniej ręcznego sprzątania po błędach i przerwanych przebiegach — proces sam dąży do uporządkowania skutków.
• Większa spójność danych w różnych systemach i mniejsza liczba „osieroconych” artefaktów (plików, rekordów, zadań).
• Łatwiejsze ponowne uruchamianie automatyzacji — gdy poprzednia próba nie zostawiła bałaganu, retry ma większą szansę powodzenia.
• Lepsza kontrola biznesowa — proces może świadomie wycofywać się, gdy wykryje niespełnione warunki lub konflikt, zamiast pozostawiać częściowo zrealizowaną operację.
• Większa przewidywalność działania przepływów w środowisku, gdzie nie wszystko jest w pełni niezawodne (połączenia, limity, integracje).

Największa wartość wzorca ujawnia się w procesach wieloetapowych oraz takich, które dotykają kilku usług jednocześnie — tam, gdzie „zatrzymanie się w połowie” jest realnym scenariuszem, a konsekwencje częściowo wykonanych zmian są kosztowne.

Historia i kontekst powstania wzorca

Wzorzec „kompensacji” (często opisywany jako compensating transaction lub „undo”) wyrósł z praktycznego problemu: jak zachować spójność procesu, gdy składa się on z wielu kroków wykonywanych w różnych systemach, które nie wspierają wspólnego, atomowego „zatwierdzenia” i „wycofania” całej operacji. W świecie pojedynczej bazy danych można polegać na klasycznych transakcjach ACID. W procesach rozproszonych — typowych dla integracji aplikacji, usług i automatyzacji — takie podejście często nie jest dostępne albo jest nieopłacalne.

Pierwotnie idea kompensacji była rozwijana w kontekście systemów rozproszonych i architektur, w których jedna „transakcja biznesowa” obejmuje wiele niezależnych operacji: rezerwacje, aktualizacje, wysyłki, powiadomienia czy tworzenie rekordów w odrębnych usługach. Jeśli jeden z późniejszych kroków kończy się błędem, nie da się po prostu „cofnąć czasu” w każdej usłudze. Zamiast tego projektuje się działania kompensujące — osobne operacje, które semantycznie odwracają (w całości lub w części) skutki wcześniej wykonanych kroków.

Rozwój podejścia przyspieszył wraz z popularyzacją integracji w modelu API-first, usług chmurowych oraz wzorców takich jak orkiestracja i choreografia procesów. Zamiast oczekiwać globalnego mechanizmu rollback, zaczęto przyjmować, że proces może być chwilowo niespójny, a rolą logiki procesu jest doprowadzenie go do stanu końcowego: sukcesu albo kontrolowanego wycofania. W tym ujęciu „kompensacja” jest bardziej strategią biznesową niż mechanizmem technicznym, bo zależy od znaczenia danych i reguł domenowych (np. anulowanie rezerwacji vs. wystawienie korekty).

W ekosystemie Power Automate kontekst jest szczególnie widoczny, ponieważ przepływy bardzo często:

• dotykają wielu konektorów i usług (Microsoft 365, SharePoint, Dataverse, Teams, poczta, systemy zewnętrzne),
• wykonują kroki asynchronicznie i podlegają limitom, opóźnieniom oraz transient errors,
• operują na działaniach, które nie mają „naturalnego” cofnięcia (np. wysłany e-mail, opublikowana wiadomość, utworzony dokument udostępniony dalej).

To sprawia, że wzorzec „undo” w Power Automate nie jest luksusem, tylko odpowiedzią na realia automatyzacji procesów: błędy po drodze są normalne, a brak planu na odwrócenie skutków prowadzi do ręcznego sprzątania, duplikatów, niespójnych stanów i trudnych do audytu wyjątków. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj.

Ważne jest też rozróżnienie, które ukształtowało sposób myślenia o kompensacji: kompensacja nie zawsze oznacza idealny powrót do stanu sprzed procesu. Często jest to „odwrócenie biznesowe” (np. oznaczenie rekordu jako anulowany, utworzenie zapisu korygującego, cofnięcie uprawnień), a nie techniczny rollback bajt w bajt. To podejście dobrze pasuje do narzędzi automatyzacji, gdzie liczy się kontrola skutków i przejrzysty ślad działań, a nie abstrakcyjna transakcyjność.

3. Kluczowe elementy i zasady działania wzorca

Wzorzec „kompensacji” (undo) w Power Automate polega na tym, że zamiast próbować „cofać” cały proces transakcyjnie (jak w bazie danych), projektujesz proces jako serię kroków, z których każdy ma jawnie zdefiniowaną akcję kompensującą. Gdy później wystąpi błąd lub warunek biznesowy unieważni wykonanie, uruchamiasz sekwencję kompensacji, która przywraca możliwie spójny stan w systemach zewnętrznych.

3.1. Dwie ścieżki: wykonanie i kompensacja

Rdzeniem wzorca są dwie logiczne ścieżki:

• Ścieżka „do przodu” (forward) — wykonuje efekty w systemach (np. zapis rekordu, wysłanie wiadomości, utworzenie pliku).
• Ścieżka kompensacji (rollback/undo) — wykonuje odwracanie skutków (np. usunięcie rekordu, przywrócenie poprzedniej wartości, oznaczenie jako anulowane).

Istotna zasada: kompensacja zwykle nie jest „matematycznym odwróceniem” każdej operacji. Często ma charakter business undo (np. zamiast kasować fakturę, wystawiasz korektę albo zmieniasz status na anulowany).

3.2. Punkt odniesienia: stan i metadane potrzebne do cofania

Żeby móc coś cofnąć, musisz przechwycić minimalny zestaw informacji, które pozwolą wykonać kompensację. W praktyce są to:

• Identyfikatory zasobów utworzonych/zmienionych w trakcie procesu (np. ID elementu listy, ID rekordu w Dataverse, ścieżka pliku).
• Poprzednie wartości (gdy zamiast „usuń” potrzebujesz „przywróć stan”).
• Kontekst decyzyjny — dlaczego krok został wykonany i jaką strategię kompensacji wybrać (np. flaga „wysłano maila”, „utworzono zamówienie”).

Te dane warto traktować jako dziennik zmian (log), nawet jeśli jest to tylko prosta struktura w zmiennej lub zapis w systemie pośrednim. Kluczowe jest, aby były dostępne po wystąpieniu błędu lub przerwaniu procesu.

3.3. Zasada kolejności: cofanie w odwrotnej kolejności

Kompensację wykonuje się zazwyczaj w odwrotnej kolejności do wykonania kroków (model „stosu”): ostatnia zmiana jest cofana jako pierwsza. Minimalizuje to problemy z zależnościami, np. nie próbujesz usunąć „rodzica”, gdy istnieją jeszcze „dzieci”.

W praktyce sprowadza się to do reguły:

• Najpierw kompensuj działania najbardziej „na końcu” i najbardziej zależne.
• Dopiero potem kompensuj wcześniejsze kroki.

3.4. Idempotencja kompensacji i bezpieczne ponawianie

W Power Automate ponowienia (retry), duplikaty wyzwalaczy czy ręczne uruchomienia naprawcze są realne. Dlatego akcje kompensujące powinny być możliwie idempotentne, czyli ich wielokrotne wykonanie prowadzi do tego samego efektu końcowego.

Przykłady praktycznej idempotencji:

• Zamiast „usuń”, stosuj „ustaw status na anulowany”, jeśli to akceptowalne biznesowo.
• Przed usunięciem sprawdź, czy zasób istnieje.
• Przed aktualizacją sprawdź, czy wartość już jest docelowa.

3.5. Klasyfikacja kroków: odwracalne, kompensowalne i nieodwracalne

Nie każdą akcję da się cofnąć. Warto rozróżnić typy kroków, aby świadomie dobrać mechanikę kompensacji:

Już na etapie projektowania warto identyfikować kroki nieodwracalne i umieszczać je możliwie późno lub opakować w dodatkowe zabezpieczenia.

3.6. Granice i spójność: „eventual consistency” zamiast transakcji

W środowisku integracji (wiele konektorów, systemy zewnętrzne) spójność często jest osiągana z opóźnieniem. Wzorzec kompensacji zakłada, że:

• Nie masz jednej transakcji obejmującej wszystkie systemy.
• Możesz chwilowo mieć stan częściowo wykonany.
• Kompensacja doprowadza systemy do stanu akceptowalnego, niekoniecznie identycznego z „jak było”.

To wymaga jasnej definicji, jaki stan końcowy jest poprawny w scenariuszu wycofania (np. „zamówienie anulowane” i „zwolniona rezerwacja”, nawet jeśli wysłany e-mail pozostaje wysłany).

3.7. Sterowanie przepływem w Power Automate: sygnał błędu i uruchomienie kompensacji

W ujęciu architektonicznym potrzebujesz mechanizmu, który:

• Wykrywa błąd/warunek anulowania (np. nieudana akcja, walidacja, limit, brak uprawnień).
• Przełącza wykonanie na ścieżkę kompensacji.
• Zapewnia, że kompensacja ma dostęp do zebranych identyfikatorów i wartości.

Implementacyjnie w Power Automate jest to zwykle realizowane przez odpowiednią strukturę bloków (np. logiczne sekcje, przechwytywanie rezultatów, ustawianie flag/zmiennych), ale kluczowa pozostaje zasada: kompensacja to zaplanowana część procesu, a nie improwizacja po awarii.

// Pseudologika (schematycznie)
1) Wykonaj krok A; zapisz dane do cofnięcia
2) Wykonaj krok B; zapisz dane do cofnięcia
3) Jeśli błąd lub „cancel” → wykonaj undo B, potem undo A

4. Najczęstsze zastosowania wzorca w praktyce

W Power Automate wzorzec „kompensacji” (undo) sprawdza się wszędzie tam, gdzie proces wykonuje kilka zależnych od siebie kroków, a na końcu może się okazać, że trzeba cofnąć skutki jednego lub wielu z nich (np. przez błąd, brak zgody, limit, rozbieżność danych). Zamiast „ręcznego sprzątania” po awarii, przepływ ma zaplanowane działania odwracające. Doświadczenie Cognity pokazuje, że rozwiązanie tego problemu przynosi szybkie i zauważalne efekty w codziennej pracy.

Typowe scenariusze w organizacji

• Onboarding / offboarding: utworzenie konta, dodanie do grup, nadanie licencji, wygenerowanie zasobów — przy przerwaniu procesu wykonujesz kroki cofające (odebranie licencji, usunięcie członkostwa, dezaktywacja/ukrycie konta).
• Akceptacje i ścieżki zatwierdzeń: po odrzuceniu wniosku lub braku odpowiedzi w czasie — wycofanie zmian w danych, odwrócenie statusów, usunięcie tymczasowych artefaktów (np. szkiców, rezerwacji).
• Provisioning zasobów (SharePoint/OneDrive/Teams): utworzenie listy, biblioteki, kanału, uprawnień — przy błędzie w kolejnych krokach: cofnięcie uprawnień, archiwizacja/usunięcie zasobu, odpięcie integracji.
• Synchronizacja danych między systemami: zapis rekordu w kilku miejscach (np. Dataverse + SharePoint + system zewnętrzny) — gdy jeden zapis się nie powiedzie: usunięcie/oznaczenie jako nieaktywne wcześniej utworzonych rekordów, korekta relacji.
• Automatyzacje finansowo-zamówieniowe: rezerwacje, preliminarze, noty, zamówienia — przy niespójności (np. limit budżetu): anulowanie rezerwacji, odwrócenie statusów, wycofanie dokumentu z obiegu.
• Obsługa zgłoszeń (ITSM) i workflow serwisowe: utworzenie zgłoszenia, powiązanych zadań, powiadomień — przy eskalacji lub anulowaniu: zamknięcie/wycofanie zadań, usunięcie przypisań, oznaczenie jako „unieważnione”.

Kompensacja w zależności od rodzaju „skutku”

W praktyce „undo” najczęściej dotyczy kilku klas zmian. Każda z nich ma inne, typowe podejście kompensacyjne (bez wchodzenia w implementacyjne detale):

Kiedy kompensacja jest praktycznie konieczna

• Proces jest wieloetapowy i częściowo „nieodwracalny” (np. powiadomienia, integracje), więc trzeba przynajmniej odwrócić to, co się da i zasygnalizować korektę.
• Występują limity i ryzyka błędów (limity API, uprawnienia, blokady, walidacje), przez które przepływ może przerwać się w połowie.
• Efekty uboczne mają koszt (licencje, zasoby, dostęp do danych), więc pozostawienie „osieroconych” zmian jest drogie lub niebezpieczne.
• Wymagana jest spójność audytowa: organizacja musi umieć wykazać, co zostało cofnięte i dlaczego, zamiast ręcznych poprawek poza procesem.

Typowe cele biznesowe stosowania wzorca

• Zmniejszenie pracy operacyjnej (mniej ręcznego usuwania rekordów, cofania uprawnień, czyszczenia zasobów).
• Kontrola ryzyka (ograniczenie przypadkowego dostępu, redukcja „pół-utworzonych” bytów).
• Lepsza jakość procesów (przewidywalne zachowanie przy błędach i wyjątkach, mniej „dziwnych stanów pośrednich”).
• Większa odporność automatyzacji (proces może bezpiecznie przerwać się i wrócić do znanego stanu).

Szybka wskazówka: kompensacja vs. ponawianie

W praktyce kompensacja często pojawia się obok mechanizmów ponawiania (retry). Ponawianie służy „dokończeniu” kroku mimo chwilowych problemów, natomiast kompensacja jest potrzebna, gdy proces nie powinien iść dalej lub nie może zostać ukończony i trzeba cofnąć już wykonane skutki.

5. Przykłady wdrożenia wzorca (krok po kroku)

Poniższe scenariusze pokazują, jak w Power Automate zbudować „kompensację” (undo) w praktyce. Każdy przykład opiera się na tym samym schemacie: wykonaj zmiany → zapisz minimalne dane do cofnięcia → w razie błędu uruchom akcje kompensujące w odwrotnej kolejności.

Przykład A: SharePoint + Teams — utworzenie elementu, a potem publikacja (z cofnięciem)

Cel: Flow tworzy element na liście SharePoint, a następnie wysyła wiadomość do kanału Teams. Jeśli wysyłka do Teams się nie powiedzie, element w SharePoint ma zostać usunięty (żeby nie zostawić „osieroconego” wpisu).

• Krok 1: Utwórz przepływ (np. wyzwalacz „When an HTTP request is received” albo „When an item is created”).
• Krok 2: Dodaj akcję Create item (SharePoint). Zapisz zwrócone ID elementu (np. do zmiennej spItemId lub bezpośrednio używaj dynamic content).
• Krok 3: Dodaj akcję wysłania wiadomości do Teams (np. Post a message in a chat or channel).
• Krok 4: Dodaj blok Scope „Kompensacja”. W jego środku dodaj akcję Delete item (SharePoint) używając spItemId.
• Krok 5: Skonfiguruj Run after dla „Kompensacji”, aby uruchamiała się, gdy scope/akcje „główne” Failed lub Timed out (opcjonalnie także Skipped, jeśli masz warunki).
• Krok 6: Dodaj „Zakończenie” (np. Terminate) z czytelnym statusem i opisem błędu po wykonaniu kompensacji.

Efekt: jeśli Teams nie zadziała, SharePoint zostanie „odkręcony” przez usunięcie świeżo utworzonego elementu.

Przykład B: Excel/Dataverse + plik w OneDrive — dwa zasoby i cofanie „wstecz”

Cel: Flow (1) tworzy plik w OneDrive, (2) zapisuje rekord (np. Dataverse). Jeśli zapis rekordu się nie uda, plik ma zostać usunięty. Jeśli rekord się uda, ale później padnie kolejny krok (np. aktualizacja), to kompensacja ma usunąć rekord i plik.

• Krok 1: Akcja Create file (OneDrive). Zapisz File Identifier (np. fileId).
• Krok 2: Akcja Add a new row (Excel) lub Add a new row/Create a new record (Dataverse). Zapisz Row ID/Record ID (np. recordId).
• Krok 3: Kolejne kroki biznesowe (np. aktualizacja, wysyłka maila, nadanie uprawnień).
• Krok 4: Zbuduj dwa scopes kompensacji, odzwierciedlające kolejność „odkręcania”:

• Krok 5: Ustaw Run after tak, by w razie błędu wykonać kompensację w kolejności: najpierw usunięcie rekordu, potem usunięcie pliku.

Efekt: minimalizujesz „śmieci” w dwóch systemach, a cofanie jest uporządkowane i deterministyczne.

Przykład C: Integracja z API (HTTP) — log kompensacji jako lista akcji do odtworzenia

Cel: Flow wywołuje kilka endpointów HTTP (np. utwórz zasób A, przypisz do B, ustaw status). Jeżeli 3. wywołanie się nie uda, chcesz automatycznie wywołać endpointy „odkręcające” (np. usuń przypisanie, usuń zasób A). Podejście: log kompensacji jako tablica kroków do wykonania przy błędzie.

• Krok 1: Zainicjalizuj zmienną typu Array, np. undoSteps (pusta tablica).
• Krok 2: Po każdym udanym kroku „do przodu” dopisz do undoSteps wpis opisujący, jak go cofnąć (np. metoda + URL + body dla „undo”).
• Krok 3: Gdy pojawi się błąd, przejdź do scope „Kompensacja”, odwróć kolejność i wykonaj zapamiętane kroki.

// Pseudostruktura wpisu w undoSteps
{
  "method": "DELETE",
  "url": "https://api.example.com/resources/@{variables('resourceId')}",
  "body": null
}

• Krok 4: W scope „Kompensacja” użyj pętli po tablicy (np. Apply to each) i wykonuj akcję HTTP zgodnie z wpisem.
• Krok 5: Zadbaj o to, by kompensacja była „odporna” na częściowe niepowodzenia (np. jeśli DELETE zwróci 404, potraktuj to jako „już odkręcone”).

Efekt: możesz skalować liczbę kroków bez ręcznego dopisywania osobnych ścieżek cofania dla każdego przypadku.

Przykład D: Proces wieloetapowy z akceptacją — cofanie po „ludzkiej” decyzji

Cel: Po akceptacji tworzysz zasób (np. element/rekord) i wysyłasz powiadomienia. Jeśli akceptacja zostanie wycofana (np. odrzucona w późniejszym kroku, anulowanie w systemie źródłowym), chcesz cofnąć skutki: usunąć rekord i wysłać informację korygującą.

• Krok 1: Trzymaj identyfikatory utworzonych zasobów (ID elementu, ID rekordu) w jednym miejscu (zmienne lub zapis w źródłowej encji).
• Krok 2: Zrób osobną gałąź/flow obsługującą zdarzenie „anuluj/wycofaj” (np. webhook/zmiana statusu).
• Krok 3: W gałęzi „wycofaj” odtwórz stan: znajdź zasoby po zapisanych ID i wykonaj akcje kompensujące (delete/revert), a następnie wyślij powiadomienie korygujące.

Efekt: cofanie nie jest tylko reakcją na błąd techniczny, ale też na zmianę decyzji w procesie.

Minimalny szablon układu w Power Automate (do skopiowania jako struktura)

Poniżej przykładowy układ scopes, który ułatwia budowę „do przodu” + „undo” bez mieszania logiki:

Scope: MAIN
  - Step 1 (create/update)
  - Step 2 (notify/integrate)
  - Step 3 (finalize)

Scope: COMPENSATION (Run after: MAIN failed/timed out)
  - Undo step 2
  - Undo step 1

Scope: FINALLY (Run after: MAIN succeeded/failed/timed out)
  - log/telemetry/cleanup

Taki szkielet można zastosować zarówno do prostych automatyzacji (1–2 akcje), jak i do dłuższych orkiestracji, gdzie „undo” musi objąć kilka systemów.

6. Zalety, ograniczenia i typowe pułapki

Zalety

• Mniej ręcznego „sprzątania” po błędach – proces samodzielnie odwraca część skutków ubocznych (np. utworzone elementy, wysłane zapisy, przydzielone uprawnienia), zamiast zostawiać je do poprawy człowiekowi.
• Większa odporność na awarie w środku procesu – gdy jeden krok się nie powiedzie, możesz „cofnąć” poprzednie kroki w kontrolowany sposób, zamiast przerywać pracę i zostawiać system w stanie pośrednim.
• Lepsza spójność danych między systemami – szczególnie gdy przepływ dotyka kilku konektorów/usług, a nie ma transakcji obejmującej całość.
• Przewidywalne ścieżki obsługi błędów – kompensacja wymusza zaplanowanie tego, co ma się stać po porażce, co zwykle poprawia jakość procesu.
• Możliwość stopniowania „odwracalności” – możesz kompensować tylko to, co ma największy koszt (np. rezerwacje zasobów), zamiast próbować cofać wszystko.
• Audytowalność – dobrze zaprojektowane akcje kompensujące ułatwiają udowodnienie „co zostało zrobione i co zostało odkręcone” (logika jest częścią przepływu).

Ograniczenia

• To nie jest transakcja ACID – kompensacja nie gwarantuje atomowości; to strategia „best effort” w środowisku rozproszonym.
• Nie wszystko da się odwrócić – wysłanego e-maila czy powiadomienia push nie „cofniesz” w sensie ścisłym; co najwyżej wyślesz komunikat korygujący.
• Opóźnienia i okna niespójności – między akcją a kompensacją systemy mogą przez chwilę widzieć stan nieidealny (np. wpis utworzony, po chwili skasowany).
• Ograniczenia konektorów i uprawnień – czasem nie ma akcji „delete/undo”, są limity API, brakuje możliwości przywrócenia poprzedniej wartości lub wymagane są dodatkowe role.
• Wzrost złożoności – trzeba zaprojektować dodatkowe kroki, warunki i przechowywanie identyfikatorów (ID) obiektów, by wiedzieć co odkręcić.
• Koszt utrzymania – zmiana w logice głównej często wymaga aktualizacji odpowiadającej jej logiki kompensacji.

Typowe pułapki (i jak ich unikać)

• Brak „śladów” potrzebnych do kompensacji
  • Pułapka: proces tworzy rekordy, ale nie zapisuje ich ID/kluczy korelacyjnych; później nie wiadomo, co usunąć lub odwrócić.
  • Wskazówka: zapisuj minimalny zestaw identyfikatorów i wartości „przed” (tam, gdzie przewidujesz rollback).
• Kompensacja nieidempotentna
  • Pułapka: ponowne uruchomienie kompensacji powoduje kolejne skutki uboczne (np. wielokrotne usuwanie, wielokrotne „odpinanie” licencji, podwójne korekty).
  • Wskazówka: projektuj akcje kompensujące tak, by wielokrotne wykonanie było bezpieczne (sprawdzenia „czy istnieje”, „czy już cofnięte”).
• Zbyt agresywne cofanie (rollback „na ślepo”)
  • Pułapka: kompensacja usuwa obiekty, które w międzyczasie zostały zmienione przez użytkownika lub inny proces.
  • Wskazówka: stosuj warunki ochronne (np. cofaj tylko jeśli status/znacznik nadal wskazuje na obiekt „tymczasowy”).
• Brak rozróżnienia: błąd trwały vs. chwilowy
  • Pułapka: proces od razu uruchamia kompensację przy błędach przejściowych (timeout, throttling), mimo że retry by wystarczył.
  • Wskazówka: rozdziel obsługę błędów na „spróbuj ponownie” i „kompensuj”, zależnie od typu awarii.
• Nieprzemyślana kolejność kompensacji
  • Pułapka: cofanie w tej samej kolejności co wykonanie; kończy się to błędami zależności (np. próbujesz usunąć rekord nadrzędny przed podrzędnymi).
  • Wskazówka: zwykle kompensuj w kolejności odwrotnej do wykonania (od najbardziej „zewnętrznych” skutków do wewnętrznych).
• „Kompensacja też może się wywalić”
  • Pułapka: założenie, że rollback zawsze się uda; w praktyce mogą wystąpić te same limity API, uprawnienia, konflikty.
  • Wskazówka: przewiduj ścieżki awaryjne dla kompensacji (logowanie, oznaczenie do ręcznej interwencji, powiadomienie).
• Ukryte skutki uboczne: powiadomienia, integracje, automaty
  • Pułapka: utworzenie rekordu wyzwala inne automaty/flow; usunięcie go nie „odkręca” działań, które już zaszły.
  • Wskazówka: oznaczaj operacje „robocze” (np. flagą) i ogranicz wyzwalacze downstream, aby nie reagowały na stany przejściowe.
• Komplikowanie procesu na siłę
  • Pułapka: próba kompensowania każdego kroku, nawet gdy koszt niespójności jest niski.
  • Wskazówka: kompensuj głównie te działania, które generują realny koszt (dane, uprawnienia, rezerwacje, finanse), a resztę rozwiązuj komunikacją lub oznaczaniem stanu.

Szybkie zestawienie: kiedy kompensacja działa najlepiej

7. Porównanie z alternatywnymi podejściami

Wzorzec kompensacji (undo) to sposób na „odwracanie” skutków wcześniej wykonanych kroków, gdy proces nie może zostać dokończony. W Power Automate często jest to najpraktyczniejsza opcja, bo wiele działań dotyka systemów, które nie wspierają transakcji w klasycznym rozumieniu. Warto jednak rozumieć, czym kompensacja różni się od innych podejść do niezawodności i kontroli skutków ubocznych.

• Transakcje (ACID) w bazach danych — zapewniają atomowość: albo wszystko się zapisuje, albo nic. To idealne w obrębie jednego silnika bazodanowego, ale rzadko możliwe w procesach obejmujących wiele usług (SharePoint, Dataverse, Outlook, Teams, API zewnętrzne). Kompensacja jest „zamiennikiem” transakcji w świecie rozproszonym, gdzie nie da się zablokować i spiąć wszystkich zasobów jednym commit/rollback.
• Ręczne sprzątanie / interwencja operacyjna — polega na tym, że po błędzie ktoś usuwa rekordy, cofa uprawnienia, odtwarza pliki. Działa w małej skali, ale jest wolne, kosztowne i podatne na pomyłki. Kompensacja przenosi to sprzątanie do procesu, dzięki czemu cofanie jest powtarzalne i mierzalne.
• Retry i odporność na błędy (ponawianie, timeouty) — podejście nastawione na „dowieźć sukces mimo problemów”. Retry rozwiązuje błędy przejściowe, ale nie cofa skutków już wykonanych akcji, jeśli proces utknie później. Kompensacja uzupełnia retry: gdy ponawianie nie pomoże, potrzebujesz kontrolowanego wycofania zmian.
• Idempotencja (bezpieczne powtarzanie) — projektowanie kroków tak, by wielokrotne uruchomienie dało ten sam efekt (np. „utwórz jeśli nie istnieje”). To ogranicza duplikaty i chaos po restartach, ale nadal nie odpowiada na pytanie: „co zrobić, jeśli utworzyłem zasób A, a na B się wywaliło?”. Kompensacja adresuje tę lukę, bo pozwala aktywnie odwrócić A.
• Soft delete / wersjonowanie / kosz — zamiast usuwać, oznaczasz rekord jako nieaktywny albo przywracasz z historii. To świetne, gdy system natywnie wspiera wersje lub kosz, ale nie zawsze jest dostępne i nie obejmie skutków w innych systemach (np. wysłanych wiadomości, nadanych ról, utworzonych zadań). Kompensacja bywa wtedy warstwą spajającą: może korzystać z „soft delete” tam, gdzie to możliwe, a gdzie nie — wykonywać inne działania odwracające.
• Event sourcing i odtwarzanie stanu — zamiast przechowywać „stan”, przechowujesz zdarzenia i liczysz stan na ich podstawie. To daje silną audytowalność i możliwość odtworzeń, ale jest cięższe architektonicznie i rzadko wdrażane w prostych automatyzacjach. Kompensacja jest bardziej pragmatyczna: działa na poziomie efektów ubocznych, bez przebudowy całego modelu danych.
• Mechanizmy „approval / checkpoint” — wprowadzasz punkty kontrolne (np. zatwierdzenie) zanim wykonasz nieodwracalne kroki. To zmniejsza ryzyko, ale spowalnia proces i nie eliminuje awarii po checkpointach. Kompensacja jest podejściem „po fakcie” i pozwala wrócić do spójnego stanu nawet wtedy, gdy błąd pojawi się późno.

W praktyce najczęściej nie wybiera się jednej techniki, tylko łączy je: retry i idempotencję do stabilizacji wykonania, checkpointy do ograniczenia ryzykownych kroków, a kompensację jako plan awaryjny na wypadek niepowodzenia w procesach wielosystemowych. Dzięki temu automatyzacja nie zostawia „śladów” do ręcznego sprzątania i zachowuje przewidywalność nawet w trudnych scenariuszach.

Dobre praktyki i rekomendacje na zakończenie

Wzorzec „kompensacji” w Power Automate działa najlepiej wtedy, gdy traktujesz go jako świadomie zaprojektowaną ścieżkę kontrolowanego wycofania skutków, a nie jako „awaryjne sprzątanie” po błędach. Poniższe praktyki pomagają utrzymać procesy odporne na częściowe niepowodzenia, a jednocześnie przewidywalne operacyjnie.

• Projektuj proces jako ciąg kroków odwracalnych — zanim dodasz akcję, zastanów się, czy i jak da się odwrócić jej skutek (np. usunięcie, przywrócenie, oznaczenie jako nieaktywne).
• Minimalizuj „nieodwracalne” zmiany — tam, gdzie to możliwe, preferuj operacje miękkie (np. status, archiwizacja, przeniesienie) zamiast twardego usuwania; zmniejsza to ryzyko trwałej utraty danych.
• Trzymaj stan i identyfikatory zasobów — zapisuj kluczowe identyfikatory (ID rekordów, ścieżki plików, numery transakcji, wersje) w sposób, który umożliwi późniejsze cofnięcie. Bez tego kompensacja staje się zgadywaniem.
• Stosuj jednoznaczną korelację — każde uruchomienie procesu powinno mieć własny identyfikator, po którym łatwo połączysz wszystkie działania i ewentualne cofki z tym samym „przypadkiem biznesowym”.
• Utrzymuj idempotencję — zarówno kroki „do przodu”, jak i kompensacje powinny tolerować ponowne uruchomienie (np. gdy flow zostanie wznowione). To ogranicza duplikaty i „podwójne cofanie”.
• Oddzielaj kompensację od obsługi wyjątków — logika wykrywania błędu i decyzja „czy cofać” to co innego niż sama sekwencja działań kompensacyjnych. Takie rozdzielenie poprawia czytelność i utrzymanie.
• Wybierz strategię kompensacji adekwatną do ryzyka — czasem wystarczy cofnięcie częściowe lub oznaczenie do ręcznej weryfikacji, a czasem potrzebujesz pełnego rollbacku. Nie każda awaria wymaga „zera” stanu.
• Dbaj o obserwowalność — loguj nie tylko błąd, ale też: które kroki wykonano, które cofnięto, które pominięto i dlaczego. Bez telemetryki trudno odróżnić błąd logiczny od sytuacji środowiskowej.
• Dodaj kontrolowane punkty kontrolne — w procesach długich lub wielosystemowych ustal miejsca, w których można bezpiecznie przerwać lub wznowić pracę bez kosztownej kompensacji.
• Ustal limity i „bezpieczniki” — kompensacja nie może wpadać w pętle lub eskalować skutków (np. masowe usuwanie). Stosuj warunki, limity prób i jasne reguły zakończenia.
• Uwzględnij opóźnienia i spójność systemów — część usług działa asynchronicznie; zaplanuj, że „cofnięcie” może wymagać czasu, ponowienia lub weryfikacji stanu pośredniego.
• Myśl o uprawnieniach i zgodności — konto wykonujące kompensację musi mieć prawo nie tylko tworzyć, ale i cofać/usuwać/odwracać zmiany. To częsta przyczyna „rollbacku, który nie działa”.
• Testuj scenariusze porażki — weryfikuj nie tylko ścieżkę sukcesu, ale też awarie po każdym krytycznym kroku. Dopiero wtedy wiesz, czy kompensacja rzeczywiście przywraca oczekiwany stan.
• Dokumentuj kontrakty kompensacyjne — zapisz, co dokładnie jest „cofnięciem” dla danego kroku (pełne, częściowe, best-effort) oraz jakie są konsekwencje uboczne (np. utrata historii, zmiana statusu).

Najważniejsza rekomendacja: traktuj kompensację jako element projektowy jakości procesu. Dobrze zaprojektowana nie eliminuje wszystkich błędów, ale sprawia, że ich skutki są kontrolowane, przewidywalne i możliwe do odtworzenia bez ręcznego „sprzątania” w kilku systemach naraz.

Jeśli chcesz poznać więcej takich przykładów, zapraszamy na szkolenia Cognity, gdzie rozwijamy ten temat w praktyce.

Teams: projektowanie centrum wiedzy bez znikających plików — 7 zasad informacji między kanałem a SharePoint 04 maja 2026

PowerApps: 9 antywzorców w formularzach, które niszczą jakość danych (i jak je naprawić regułami) 02 maja 2026