Power Automate: jak zbudować audyt „kto co zatwierdził” zgodny z wymaganiami compliance

1. Cel i wymagania audytu akceptacji w Power Automate (kto, co, kiedy, podstawa, wynik)

Audyt akceptacji w Power Automate ma odpowiedzieć na jedno kluczowe pytanie compliance: czy dana decyzja została podjęta przez właściwą osobę, we właściwym momencie, na właściwej podstawie i z możliwym do udowodnienia wynikiem. W praktyce oznacza to zbudowanie spójnego śladu dowodowego (audit trail) dla procesów zatwierdzania realizowanych w przepływach, tak aby można go było wykorzystać w kontroli wewnętrznej, audycie zewnętrznym, postępowaniu wyjaśniającym lub analizie incydentu.

Warto odróżnić dwa poziomy oczekiwań:

• Widoczność operacyjna (dla właścicieli procesu): szybka informacja, na jakim etapie jest akceptacja i kto „trzyma piłkę”.
• Dowód audytowy (dla compliance/ryzyka): kompletna, wiarygodna i odporna na manipulacje historia decyzji, możliwa do odtworzenia nawet po miesiącach.

Power Automate daje podstawowe informacje o uruchomieniach i akcjach, ale wymagania compliance zwykle idą dalej: oczekują powiązania decyzji z kontekstem biznesowym (czego dotyczyła), uzasadnieniem (dlaczego) oraz jednoznacznej identyfikacji podmiotu podejmującego decyzję (kto), wraz z czasem i wynikiem (kiedy, co się stało).

Minimalny zestaw pytań audytowych

Dobrze zaprojektowany audyt akceptacji powinien umożliwiać udzielenie odpowiedzi na poniższe pytania bez domysłów i bez ręcznego „sklejania” danych z wielu miejsc:

• Kto zatwierdził/odrzucił (tożsamość, typ podmiotu: użytkownik, konto techniczne, grupa; a także kontekst organizacyjny, np. dział/rola, jeśli jest wymagany).
• Co zostało zatwierdzone (jednoznaczny identyfikator obiektu biznesowego i jego wersji/zakresu: dokument, wniosek, zamówienie, zmiana, wyjątek).
• Kiedy zapadła decyzja (czas wysłania prośby o akceptację, czas odpowiedzi, ewentualne terminy SLA i opóźnienia).
• Podstawa decyzji (na jakiej podstawie formalnej lub proceduralnej: reguła, polityka, próg kwotowy, delegacja, wyjątek; w praktyce często także uzasadnienie i komentarz oraz odniesienia do załączników/źródeł).
• Wynik (zaakceptowano/odrzucono/anulowano/wygasło; oraz co wynik uruchomił dalej, np. publikację, wysyłkę, aktualizację rekordu).

Zakres zdarzeń, które zwykle podlegają audytowi

Compliance rzadko zadowala się samym „approved/rejected”. W typowym procesie zatwierdzania znaczenie dowodowe mają również zdarzenia pośrednie i wyjątkowe, bo to one tłumaczą „dlaczego” i „co się stało po drodze”. Minimalny zakres zwykle obejmuje:

• Inicjację: kto i co uruchomiło proces (np. zgłoszenie, zmiana statusu, nowy plik).
• Utworzenie prośby o akceptację: do kogo została skierowana, jaką ścieżką i według jakiej logiki (np. pierwszy przełożony, następnie finanse).
• Dostarczenie/powiadomienie: czy i kiedy odbiorca mógł realnie podjąć decyzję (ważne przy sporach o termin).
• Decyzję: wynik, czas, komentarz/uzasadnienie, ewentualnie informacja o delegacji/zastępstwie.
• Wyjątki: timeout, anulowanie, ponowienie, błąd techniczny, brak uprawnień, zmiana danych w trakcie akceptacji.

Wymagania jakościowe: kompletność, jednoznaczność, odtwarzalność

Żeby zapis miał wartość audytową, musi spełniać cechy, które odróżniają go od „logu na potrzeby debugowania”:

• Kompletność: brak luk w kluczowych etapach i brak sytuacji, w której decyzja nie ma przypisanego obiektu biznesowego lub osoby.
• Jednoznaczność: możliwość bezbłędnego powiązania decyzji z konkretną instancją procesu i konkretnym artefaktem (bez ryzyka, że dwa równoległe procesy „pomieszają się” w raporcie).
• Chronologia: zdarzenia muszą układać się w linię czasu, a strefy czasowe i formaty muszą być spójne.
• Odtwarzalność: po czasie da się odtworzyć, jaka była treść prośby o akceptację i jakie dane były dostępne w momencie podejmowania decyzji (w granicach zasad retencji i minimalizacji danych).

Wymagania compliance: tożsamość, uprawnienia, prywatność i retencja

Audyt „kto co zatwierdził” dotyka danych osobowych i informacji wrażliwych procesowo, dlatego w wymaganiach trzeba uwzględnić nie tylko rejestrowanie faktów, ale też zasady ich przetwarzania:

• Wiarygodna identyfikacja „kto”: audyt powinien opierać się o tożsamość z systemu tożsamości (np. konto użytkownika), a nie o deklaratywne pola tekstowe.
• Zasada najmniejszych uprawnień: dostęp do logów audytowych powinien być ograniczony do ról, które tego potrzebują (audyt, compliance, właściciel procesu w zakresie read-only).
• Minimalizacja danych: rejestrować tyle, ile jest konieczne do dowodu; np. komentarze mogą zawierać dane wrażliwe i powinny mieć jasno określone zasady przechowywania.
• Retencja i usuwanie: wymagany czas przechowywania musi wynikać z polityk i regulacji; równie ważne jest kontrolowane usuwanie po upływie okresu retencji.
• Rozliczalność: musi być jasne, kto jest właścicielem audytu (odpowiedzialność biznesowa), a kto administruje rozwiązaniem (odpowiedzialność techniczna).

Co oznacza „zgodny z wymaganiami compliance” w praktyce

W kontekście Power Automate „zgodny” audyt nie polega tylko na tym, że dane gdzieś są zapisane. Oznacza to, że potrafisz:

• przedstawić spójny zapis „kto/co/kiedy/podstawa/wynik” dla dowolnej instancji zatwierdzania,
• wykazać, że zapis jest kompletny i nie był modyfikowany w sposób nieuprawniony,
• udostępnić go w kontrolowany sposób (dla audytora, właściciela procesu, bezpieczeństwa),
• utrzymać go przez wymagany okres, bez utraty zdolności do analizy i raportowania.

2. Model zdarzeń i korelacja: runy przepływu, instancje akceptacji, kroki, decyzje, komentarze

Aby audyt „kto co zatwierdził” był wiarygodny i użyteczny w kontekście compliance, trzeba z góry przyjąć model zdarzeń (co uznajemy za zdarzenie audytowe) oraz korelację (jak łączymy zdarzenia w spójną historię). Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj. W Power Automate szczególnie ważne jest rozdzielenie tego, co dzieje się na poziomie uruchomienia przepływu, od tego, co dzieje się w samym procesie akceptacji.

Run przepływu (flow run) – „obudowa” procesu

Run przepływu to pojedyncze wykonanie flow, uruchomione przez wyzwalacz (np. utworzenie elementu, żądanie HTTP, ręczne uruchomienie). Jest naturalnym „kontenerem” audytu, bo ma jednoznaczne atrybuty czasu i kontekstu uruchomienia.

• Do czego służy w audycie: pozwala odpowiedzieć „kiedy i dlaczego w ogóle rozpoczęto proces” oraz z czym był powiązany (rekord biznesowy, dokument, zgłoszenie).
• Na co uważać: jeden run nie zawsze oznacza jeden proces biznesowy; mogą wystąpić ponowienia, równoległe gałęzie lub wznowienia po błędzie, które trzeba umieć odróżnić w korelacji.

Instancja akceptacji – „życie” konkretnej prośby o zatwierdzenie

Instancja akceptacji to pojedyncza prośba o zatwierdzenie wysłana do akceptujących (np. przez akcję Approvals). To ona odpowiada na pytanie: „jakie zatwierdzenie zostało utworzone i jaki ma status”.

• Do czego służy w audycie: grupuje wszystkie zdarzenia dotyczące tej samej akceptacji (utworzenie, przypisanie, przypomnienia, finalny wynik).
• Różnica względem runu: w ramach jednego runu może powstać wiele instancji akceptacji (np. różne etapy), a pojedyncza instancja może być obsługiwana asynchronicznie i kończyć się później niż sam run w danym kroku.

Kroki akceptacji – etapy i reguły (sekwencyjne vs równoległe)

Krok to logiczny etap procesu akceptacji, np. „akceptacja menedżera” albo „akceptacja compliance”. Kroki pozwalają modelować akceptacje wieloetapowe, gdzie wynik jednego etapu warunkuje uruchomienie kolejnego.

• Do czego służą w audycie: umożliwiają wykazanie, że obowiązująca ścieżka decyzyjna została dochowana (kolejność, kompletność, wymagane role).
• Warianty: kroki sekwencyjne (najpierw A, potem B) oraz równoległe (A i B niezależnie). W audycie istotne jest rozróżnienie, czy wymagano jednomyślności, większości czy „pierwsza odpowiedź wygrywa”.

Decyzje – zdarzenia „kto, co, kiedy, wynik”

Decyzja to pojedyncze zdarzenie podjęte przez konkretnego akceptującego (np. zaakceptował/odrzucił). To rdzeń audytu, bo bezpośrednio odpowiada na „kto co zatwierdził”.

• Co musi być możliwe do odtworzenia: tożsamość decydenta, czas decyzji, typ decyzji, powiązanie z konkretną instancją akceptacji i krokiem.
• Co bywa mylące: „finalny status” instancji akceptacji nie zawsze jest sumą wszystkich decyzji w intuicyjny sposób (np. przy regule większości lub zakończeniu po pierwszej odpowiedzi). Dlatego w modelu zdarzeń decyzje powinny być rejestrowane jako osobne fakty.

Komentarze i uzasadnienie – kontekst dowodowy

Komentarz (uzasadnienie) nie jest tylko „notatką” – w audycie często stanowi element dowodowy, pokazujący podstawę merytoryczną decyzji. Komentarze mogą pojawić się przy decyzji, ale też jako osobne dopiski w trakcie procesu.

• Do czego służą w audycie: dokumentują motywację, zastrzeżenia, warunki akceptacji lub przyczyny odrzucenia.
• Na co uważać: komentarz bywa wrażliwy (dane osobowe, informacje poufne), więc w modelu zdarzeń warto traktować go jako element, który może podlegać odrębnym zasadom widoczności i retencji.

Korelacja – jak spiąć wszystko w jedną narrację

Największym ryzykiem w audycie jest sytuacja, w której mamy „logi”, ale nie potrafimy jednoznacznie odpowiedzieć, które zdarzenia należą do tej samej sprawy. Korelacja powinna działać na kilku poziomach:

• Korelacja biznesowa: wspólny identyfikator obiektu, którego dotyczy akceptacja (np. ID rekordu, numer wniosku, identyfikator dokumentu). To oś, względem której audyt jest najczęściej przeglądany.
• Korelacja techniczna: identyfikator runu przepływu oraz identyfikator instancji akceptacji. Pozwala przejść od „sprawy” do konkretnego wykonania automatyzacji i konkretnej akceptacji.
• Korelacja etapów: identyfikator kroku/etapu, aby rozdzielić decyzje w procesach wielostopniowych i uniknąć mieszania zdarzeń z różnych etapów.
• Korelacja zdarzeń: identyfikator zdarzenia i powiązanie „rodzic–dziecko” (np. utworzenie instancji → przypisanie → decyzja). Ułatwia odtworzenie osi czasu oraz analizę przyczyn (np. opóźnień, ponowień, wyjątków).

Tak zdefiniowany model (run → instancja akceptacji → krok → decyzja/komentarz) pozwala budować audyt, który jest jednocześnie zrozumiały dla biznesu i precyzyjny technicznie: od rekordu biznesowego, przez przebieg automatyzacji, aż po indywidualne decyzje osób zatwierdzających.

3. Gdzie przechowywać logi: Dataverse vs SharePoint vs Azure (SQL/Storage/Log Analytics) – kryteria wyboru

W audycie „kto co zatwierdził” miejsce składowania logów determinuje nie tylko koszt i wydajność, ale też to, jak łatwo udowodnisz kompletność i wiarygodność danych, jak szybko zbudujesz raporty oraz jak bezpiecznie udostępnisz wgląd audytorom. Najczęściej spotkasz cztery klasy magazynów: Dataverse, SharePoint oraz komponenty Azure (SQL/Storage/Log Analytics).

Kryteria wyboru (co realnie ma znaczenie)

• Charakter danych: czy log to zdarzenia transakcyjne (rekordy „append-only”), czy też logi techniczne/telemetryczne o dużej wolumenowości.
• Wolumen i tempo zapisu: liczba akceptacji/dzień, liczba kroków na akceptację, potrzeba zapisu „per zdarzenie” vs agregaty.
• Zapytania i raportowanie: filtry po osobie, obiekcie biznesowym, czasie, statusie; potrzeba relacji i joinów; szybkość odpowiedzi.
• Uprawnienia i separacja obowiązków: czy logi mają być dostępne dla właścicieli procesu, IT, czy tylko dla compliance.
• Odporność na manipulacje: ograniczenie edycji, wersjonowanie, retencja, możliwość niezależnego archiwum.
• Łatwość integracji z Power Automate: gotowe konektory, proste wstawianie rekordów, obsługa błędów.
• Koszt i operacyjność: licencje, utrzymanie, monitoring, backup/restore, dostępność środowisk.

Porównanie opcji (kiedy co wybrać)

Praktyczne heurystyki wyboru

• Jeśli audyt ma być blisko danych biznesowych w Power Platform i wymaga relacji (np. wniosek → akceptacje → decyzje), najczęściej wygrywa Dataverse.
• Jeśli priorytetem jest najprostsze wdrożenie i wolumen jest umiarkowany, a raporty będą podstawowe, rozważ SharePoint.
• Jeśli potrzebujesz mocnej analityki SQL, integracji z ekosystemem danych lub centralnego repozytorium audytów z wielu źródeł, celuj w Azure SQL.
• Jeśli kluczowe są koszt, retencja i archiwizacja dużej ilości surowych zdarzeń, rozważ Azure Storage (często jako warstwa archiwum).
• Jeśli chcesz szybko wykrywać problemy operacyjne i anomalia w uruchomieniach, a audyt ma też wymiar „observability”, dodaj Log Analytics dla logów technicznych (często równolegle do repozytorium audytu).

Wzorce łączenia (często najlepsza jest architektura hybrydowa)

W praktyce audyt compliance bywa realizowany w modelu „system of record + system of insight”:

• System of record: Dataverse lub Azure SQL jako główne, ustrukturyzowane repozytorium zdarzeń audytowych.
• System of insight: Log Analytics dla diagnostyki i alertów, Power BI dla raportów.
• Archiwum: Azure Storage jako długoterminowa, tańsza warstwa przechowywania (opcjonalnie).

Taki podział pozwala jednocześnie spełnić potrzeby audytowe (spójne, relacyjne dane „kto-co-kiedy”) oraz operacyjne (monitoring, alerty, analiza błędów) bez przeciążania jednego narzędzia zadaniami, do których nie jest optymalne.

4. Integralność danych i niezmienność: podpisy/hashy, WORM/retencja, uprawnienia, ślad zmian, odporność na manipulacje

Audyt „kto co zatwierdził” ma wartość compliance tylko wtedy, gdy można wykazać, że zapis zdarzeń jest kompletny, autentyczny (pochodzi z właściwego źródła), spójny (nie został „podmieniony”) oraz trwały (da się go odtworzyć po czasie). W praktyce oznacza to połączenie kontroli technicznych (hash/podpis, niezmienność, retencja) i organizacyjnych (role, rozdział obowiązków, procedury dostępu). Zespół trenerski Cognity zauważa, że właśnie ten aspekt (udowodnienie niezmienności i wiarygodności logów) sprawia uczestnikom najwięcej trudności.

Niezmienność: czego oczekuje compliance

• Wykrywalność zmian – jeśli ktoś edytuje rekord logu, musi pozostać ślad (albo zmiana ma być technicznie niemożliwa).
• Odporność na kasowanie – rekordów nie powinno dać się usuwać „po cichu”, a jeśli jest to dozwolone, musi podlegać silnej kontroli i śladowi audytowemu.
• Kontrolowany okres przechowywania – logi muszą być przechowywane zgodnie z retencją (minimalny czas), a po jej upływie usuwane zgodnie z polityką (np. prawo do usunięcia vs obowiązki regulacyjne).
• Łańcuch dowodowy – możliwość wykazania, kto miał dostęp administracyjny, kto nadawał uprawnienia i jakie były zmiany konfiguracji.

Hashe i podpisy: po co i jak je stosować

Hash (np. SHA-256) pozwala wykryć zmianę treści rekordu: jeśli pola rekordu zostaną zmodyfikowane, wartość hash przestanie się zgadzać. Podpis cyfrowy idzie krok dalej: potwierdza nie tylko integralność, ale też autentyczność (kto „podpisał” rekord), o ile klucz prywatny jest odpowiednio chroniony.

• Hash rekordu – liczony z kanonicznej reprezentacji pól istotnych dla audytu (np. identyfikator zdarzenia, czas, identyfikator osoby/systemu, wynik, komentarz, podstawa biznesowa).
• Łańcuch hashy (hash chaining) – każdy kolejny rekord zawiera hash poprzedniego (lub skrót dzienny), co utrudnia usunięcie/wniesienie „w środku” bez wykrycia.
• Podpis (opcjonalnie) – gdy wymagane jest silne potwierdzenie źródła; typowo realizowane przez zewnętrzną usługę kluczy (HSM/Key Vault) zamiast przechowywania sekretu w przepływie.

W kontekście Power Automate najczęściej spotyka się podejście: hash + niezmienny magazyn + ograniczone uprawnienia. Podpisy cyfrowe stosuje się tam, gdzie audyt ma charakter dowodowy o podwyższonym rygorze (np. środowiska regulowane) i gdzie istnieje formalny proces zarządzania kluczami.

// Przykład ideowy: co obejmować hashem (nie jest to gotowa implementacja)
canonical = ApprovalId + "|" + StepId + "|" + ActorId + "|" + Decision + "|" + TimestampUtc + "|" + BusinessBasis
recordHash = SHA256(canonical)
chainedHash = SHA256(recordHash + "|" + previousChainedHash)

WORM i retencja: niezmienność w czasie

WORM (Write Once, Read Many) oznacza, że po zapisie danych nie da się ich zmodyfikować ani usunąć przez określony czas. Dla logów akceptacji to mechanizm, który buduje zaufanie: nawet administrator nie powinien móc „poprawić historii”. Retencja natomiast definiuje, jak długo dane mają być utrzymywane i w jakich warunkach mogą zostać skasowane.

• Retencja „twarda” (immutable retention) – blokuje usuwanie/edycję w okresie retencji.
• Retencja „miękka” – wspiera procesy governance, ale nie zawsze technicznie uniemożliwia zmianę przez uprzywilejowane role.
• Legal hold – zamrożenie usuwania na czas postępowania/doch. audytu, niezależnie od standardowej retencji.

Praktyczny wniosek: jeśli audyt ma spełniać wymogi niezmienności, warto preferować mechanizmy, które wymuszają ją technicznie, a nie jedynie proceduralnie.

Uprawnienia i rozdział obowiązków (SoD)

Najczęstsza słabość audytu nie wynika z braku logów, tylko z tego, że zbyt wiele osób może je edytować lub usuwać. Dla „kto co zatwierdził” kluczowe są: minimalne uprawnienia i rozdział obowiązków (Separation of Duties).

• Oddzielenie ról: osoba administrująca przepływem nie powinna mieć możliwości modyfikacji magazynu logów (i odwrotnie).
• Write-only dla aplikacji: przepływ zapisuje logi, ale nie ma uprawnień do ich aktualizacji i usuwania (o ile platforma to umożliwia).
• Ograniczony odczyt: dostęp do pełnych logów (z danymi wrażliwymi) tylko dla ról audytowych; użytkownicy biznesowi mogą widzieć jedynie agregaty lub własne sprawy.
• Uprzywilejowane operacje: nadawanie uprawnień, zmiany retencji i eksport danych muszą być kontrolowane i rejestrowane (administracyjny audit trail).

Ślad zmian: co powinno być rejestrowane poza samą akceptacją

Compliance zwykle wymaga nie tylko logów samej decyzji akceptacyjnej, ale też dowodów, że system działał w kontrolowany sposób. Warto zadbać o rejestrowanie:

• Zmian konfiguracji przepływów (kto opublikował zmianę, kiedy, jaki zakres zmiany).
• Zmian uprawnień do magazynu logów i komponentów procesu.
• Prób odczytu/eksportu (zwłaszcza masowych), jeśli środowisko tego wymaga.
• Incydentów i wyjątków wpływających na kompletność logów (np. niedostępność konektora, błędy zapisu).

Nie chodzi o to, by logować „wszystko”, ale by pokryć te obszary, które mogłyby umożliwić manipulację historią zatwierdzeń lub podważyć wiarygodność procesu.

Odporność na manipulacje: typowe scenariusze i zabezpieczenia

Minimalny zestaw zasad (baseline) dla audytu akceptacji

• Logi są append-only (brak edycji i usuwania przez proces zapisujący).
• Istnieje techniczny mechanizm wykrywania ingerencji (hash lub łańcuch hashy; podpis gdy wymagany).
• Retencja jest zdefiniowana i egzekwowana (w tym procedura legal hold).
• Dostęp jest ograniczony i rozdzielony między właścicieli procesu, administratorów i audytorów.
• Zmiany konfiguracji i uprawnień są rejestrowane w śladzie administracyjnym.

5. Wzorzec danych: schemat tabeli/listy logów audytowych (pola, klucze, relacje, indeksy) + przykład rekordu

Dobry audyt „kto co zatwierdził” wymaga spójnego wzorca danych, który pozwala: (1) odtworzyć pełną historię decyzji, (2) powiązać ją z uruchomieniem przepływu i obiektem biznesowym, (3) filtrować i raportować bez kosztownych transformacji. Poniżej jest wzorzec neutralny technologicznie (tabela w Dataverse/SQL lub lista w SharePoint), oparty na zdarzeniach oraz korelacji po identyfikatorach.

5.1. Minimalny model: dziennik zdarzeń + encje referencyjne

W praktyce najlepiej sprawdza się podejście event log: każda istotna czynność (utworzenie akceptacji, przypisanie, decyzja, eskalacja, timeout, błąd, anulowanie) jest osobnym wpisem. Dodatkowo trzymasz encje referencyjne, aby nie duplikować danych (np. „sprawa”/„wniosek”).

• AuditEvent – centralna tabela/lista z wpisami zdarzeń audytowych (append-only).
• BusinessObject (opcjonalnie) – referencja do obiektu biznesowego, jeśli nie wystarczy przechować jego identyfikator.
• Actor (opcjonalnie) – słownik aktorów, gdy chcesz normalizować użytkowników/serwisy i unikać rozbieżności w nazwach.

5.2. Schemat tabeli/listy AuditEvent (pola i znaczenie)

Poniższy zestaw pól pokrywa typowe wymagania compliance: kto, co, kiedy, podstawa, wynik oraz możliwość rekonstrukcji przebiegu (korelacja i kolejność).

5.3. Klucze i relacje (jak to spiąć, żeby dało się odtworzyć „kto co zatwierdził”)

• PK: EventId.
• Naturalny klucz deduplikacyjny (zalecany): (CorrelationId, EventType, ApprovalInstanceId, ApprovalStepId, ActorId, Outcome, ClientRequestId). W praktyce pozwala wykryć duplikaty przy ponowieniach.
• Relacja do obiektu biznesowego: (BusinessObjectType, BusinessObjectId) – najczęściej wystarcza jako „foreign key logiczny” (nawet jeśli fizycznie to tekst).
• Relacja do uruchomień: FlowRunId i FlowId umożliwiają powiązanie audytu z telemetrią wykonania (kontekst techniczny).
• Relacja do akceptacji: ApprovalInstanceId grupuje zdarzenia wokół jednej instancji; ApprovalStepId różnicuje kroki/etapy w ramach instancji.

5.4. Indeksy (pod typowe zapytania audytowe i raporty)

Indeksy dobieraj pod najczęstsze ścieżki: przegląd zdarzeń dla sprawy, dla instancji akceptacji oraz dla aktora w zakresie czasu.

• IDX_1: (BusinessObjectType, BusinessObjectId, EventTimeUtc) – „pokaż historię decyzji dla sprawy”.
• IDX_2: (ApprovalInstanceId, EventTimeUtc) – oś czasu dla jednej akceptacji.
• IDX_3: (FlowRunId) – szybkie odnalezienie zdarzeń dla runu.
• IDX_4: (ActorId, EventTimeUtc) – „co zatwierdzał dany użytkownik w okresie”.
• IDX_5: (EventType, Outcome, EventTimeUtc) – statystyki decyzji/błędów.

Uwaga praktyczna: w listach SharePoint indeksy są ograniczone i mają znaczenie głównie dla kolumn filtrujących/widoków. W tabelach (Dataverse/SQL) możesz pozwolić sobie na bardziej klasyczne indeksowanie.

5.5. Przykład rekordu (zdarzenie decyzji)

{
  "EventId": "b7a5c9ef-6b8c-4c35-9c2c-3c91c6a0e1a4",
  "EventTimeUtc": "2026-03-24T10:42:13Z",
  "EventSequence": 17,
  "CorrelationId": "7f3b2b9a-6a2a-4c10-8a8b-4b9f1d8f2f21",
  "EnvironmentId": "Default-...",
  "FlowId": "1f2d3c4b-...",
  "FlowRunId": "0858601234567890123456789012345678901234567890",
  "ApprovalInstanceId": "approval-00012345",
  "ApprovalStepId": "Finance-01",
  "EventType": "Decision",
  "Outcome": "Approved",
  "Severity": "Info",
  "ActorType": "User",
  "ActorId": "user@domain.tld",
  "ActorDisplay": "Użytkownik, Dział Finansów",
  "BusinessObjectType": "InvoiceApproval",
  "BusinessObjectId": "INV-2026-000987",
  "BusinessObjectRefUrl": "https://.../invoices/INV-2026-000987",
  "PolicyBasis": "POL-AP-INV-001; threshold=10000; role=FinanceApprover",
  "Justification": "Zgodne z budżetem i umową",
  "Connector": "Approvals",
  "ClientRequestId": "dec-INV-2026-000987-Finance-01",
  "Payload": {
    "slaHours": 24,
    "assignedTo": ["user@domain.tld"],
    "channel": "Teams"
  }
}

Ten pojedynczy wpis odpowiada na pytania audytu: kto (ActorId), co (BusinessObjectId/Type), kiedy (EventTimeUtc), podstawa (PolicyBasis + Justification) i wynik (Outcome), a jednocześnie pozwala go osadzić w pełnym kontekście procesu (CorrelationId, ApprovalInstanceId, FlowRunId).

6. Implementacja w przepływach: jak rejestrować zdarzenia akceptacji i błędy, identyfikatory korelacyjne, transakcyjność

Implementacja audytu „kto co zatwierdził” w Power Automate sprowadza się do konsekwentnego emitowania zdarzeń audytowych w kilku punktach przepływu oraz do utrzymania identyfikatorów korelacyjnych, które pozwolą później powiązać: run przepływu, żądanie akceptacji, decyzję, komentarze i ewentualne błędy. Na tym etapie kluczowe jest ustalenie gdzie i kiedy zapisujesz log, a nie dopracowanie docelowego schematu danych.

6.1. Punkty kontrolne: co logować i w którym miejscu przepływu

Najpraktyczniejszy wzorzec to logowanie minimalnego zestawu zdarzeń wzdłuż „ścieżki życia” akceptacji. W typowym scenariuszu (utworzenie wniosku → wysłanie do akceptacji → decyzja → dalsze akcje) dodaj zapisy audytowe w następujących momentach:

• Start runu (inicjalizacja korelacji): zapis identyfikatorów runu i kontekstu biznesowego (np. ID wniosku).
• Utworzenie żądania akceptacji: zapis, że wygenerowano akceptację (kto był inicjatorem, do kogo wysłano, jaki obiekt dotyczy).
• Odpowiedź/rozstrzygnięcie: zapis decyzji (Approve/Reject), czasu, osoby decydującej, komentarza.
• Skutek biznesowy: zapis, że na podstawie decyzji wykonano konkretną akcję (np. zmiana statusu dokumentu).
• Błąd (techniczny) lub niepowodzenie walidacji (biznesowe): zapis przyczyny i miejsca w procesie.

6.2. Identyfikatory korelacyjne: jak spiąć run, akceptację i obiekt biznesowy

W praktyce potrzebujesz co najmniej dwóch osi korelacji:

• Run/techniczna: identyfikator instancji uruchomienia przepływu (run) oraz ewentualnie ID akcji, która zawiodła.
• Biznesowa: identyfikator obiektu, którego dotyczy akceptacja (np. numer wniosku, ID rekordu w systemie źródłowym) oraz identyfikator samej akceptacji.

Rekomendacja implementacyjna:

• Na początku przepływu ustaw zmienne/kompozycje, które będą przenoszone do każdego wpisu logu, np. BusinessObjectId, BusinessProcessId (jeśli istnieje), RunId.
• Po akcji tworzącej akceptację (np. „Create an approval”) przechwyć zwrócone Approval ID i zapisuj je w logach kolejnych zdarzeń.
• Jeśli jedna sprawa może mieć wiele akceptacji (np. etapowo), generuj i propaguj ApprovalInstanceId (np. bazując na Approval ID) jako „klucz wspólny” dla zdarzeń w ramach jednej instancji akceptacji.

6.3. Wzorzec emisji logów: inline vs przepływ pomocniczy (child flow)

Są dwa najczęściej stosowane sposoby rejestrowania audytu w Power Automate. Różnią się wpływem na czytelność, obsługę błędów i spójność zapisu:

W obu wariantach ważne jest, by format zdarzenia i zestaw pól były identyczne w całej organizacji (ten temat rozwijają kolejne elementy architektury).

6.4. Obsługa błędów: rejestrowanie awarii akcji i ścieżek wyjątków

W Power Automate błędy najczęściej „uciekają” w dwóch sytuacjach: gdy przepływ kończy się przed zapisem logu albo gdy zapis logu jest uzależniony od sukcesu poprzednich kroków. Dlatego zastosuj prosty układ sterowania:

• Grupuj kroki w Scope (np. „Main”) oraz osobny Scope „Error handler”.
• W „Error handler” ustaw Run after na: has failed, has timed out (opcjonalnie is skipped), aby log błędu wykonał się niezależnie.
• W logu błędu zapisuj: etap (np. nazwa scope), typ błędu, komunikat, a także korelatory (RunId, BusinessObjectId, ApprovalId o ile dostępne).

Minimalny przykład wyciągnięcia komunikatu błędu (w zależności od akcji i konektora struktura może się różnić):

// Przykład: odczyt błędu z wyniku akcji o nazwie "Create_an_approval"
outputs('Create_an_approval')?['body']
outputs('Create_an_approval')?['error']

W praktyce lepiej logować zarówno skrócony komunikat dla raportów, jak i „surowe” szczegóły techniczne (np. payload błędu) w polu przeznaczonym na dane diagnostyczne.

6.5. Akceptacje: rejestrowanie decyzji i komentarzy

Najczęściej spotkasz dwa modele działania:

• Synchroniczny: przepływ tworzy akceptację i „czeka” na wynik (np. „Wait for an approval”). Logujesz utworzenie akceptacji, a potem logujesz decyzję w tym samym runie.
• Asynchroniczny: osobny przepływ reaguje na zdarzenie związane z akceptacją (np. gdy ktoś odpowie). Logujesz decyzję w innym runie, ale łączysz to przez Approval ID i BusinessObjectId.

W obu modelach zwróć uwagę na spójność:

• Decyzję loguj jako zdarzenie „ApprovalResponded” (lub równoważne), z polami: Outcome, Responder, ResponseTime, Comment.
• Jeśli akceptacja ma wielu approverów (np. „Everyone must approve”), loguj każdą odpowiedź osobno jako osobne zdarzenie, a potem opcjonalnie loguj zdarzenie „ApprovalCompleted” z wynikiem zbiorczym.

6.6. Transakcyjność i spójność: jak nie zgubić audytu

Power Automate nie jest systemem transakcyjnym w sensie ACID dla wielu kroków i wielu systemów. „Transakcyjność” audytu osiąga się przez wzorce, które minimalizują ryzyko brakujących wpisów:

• Najpierw loguj intencję, potem wykonuj efekt: np. przed zmianą statusu wniosku zapisz zdarzenie „StatusChangeRequested”, a po sukcesie „StatusChanged”.
• Co najmniej raz (at-least-once) zamiast „dokładnie raz”: zakładaj, że zapis może się powtórzyć (retry). Projektuj zdarzenia tak, by dało się je odróżnić i zredukować duplikaty po kluczu korelacyjnym (np. EventId).
• Retry policy: dla zapisu logów ustaw sensowne ponawianie (tam gdzie dostępne), ale równoważ to z ryzykiem duplikatów.
• Fallback: jeśli zapis logu jest krytyczny, rozważ osobną ścieżkę awaryjną (np. druga lokalizacja zapisu lub kolejka) – bez rozbudowy szczegółów na tym etapie.

6.7. Minimalny „szkielet” przepływu pod audyt

Poniższy układ pokazuje, gdzie wpiąć logowanie bez wchodzenia w szczegóły docelowego magazynu logów:

• Initialize: ustaw RunId, BusinessObjectId, (opcjonalnie) CorrelationId.
• Log: FlowStarted
• Main scope:
  • Walidacje wejścia (w razie błędu log „ValidationFailed”)
  • Create approval → Log: ApprovalCreated
  • Wait for approval/response → Log: ApprovalResponded
  • Akcje po decyzji → Log: BusinessActionCompleted
• Error handler scope (Run after: failed/timed out): Log: FlowFailed + dane diagnostyczne
• Log: FlowCompleted (jeśli wymagane, jako domknięcie audytu runu)

Takie podejście daje przewidywalny, audytowalny ślad: wiesz kto (responder), co (obiekt/akcja), kiedy (znacznik czasu), jaka podstawa (kontekst/etap) i jaki wynik (approve/reject/success/failure), a przy tym zachowujesz możliwość korelacji między wieloma runami i wieloma instancjami akceptacji.

7. Raportowanie i analityka: Power BI, zapytania/filtry, KPI, alerty i wykrywanie anomalii

Audyt „kto co zatwierdził” ma wartość dopiero wtedy, gdy da się go szybko odczytać, przefiltrować i udowodnić w razie kontroli. Warstwa raportowania powinna umożliwiać dwa tryby pracy: operacyjny (monitoring bieżących akceptacji i wyjątków) oraz compliance (odtwarzalny, spójny obraz decyzji wraz z kontekstem, w tym zgodność z politykami i terminami). Kluczowe jest też rozdzielenie: raportów dla biznesu (KPI i trendy) od widoków dochodzeniowych (drill-through do pojedynczych zdarzeń i ścieżki decyzyjnej).

Power BI: jakich widoków potrzebujesz

Power BI sprawdza się jako warstwa prezentacji i eksploracji, o ile dane audytowe są modelowane pod zapytania i mają stabilne identyfikatory korelacyjne. Typowe zestawy raportów obejmują:

• Pulpit zgodności – poziom spełnienia SLA, kompletność wymaganych atrybutów audytowych, udział wyjątków i decyzji „warunkowych”.
• Przegląd przepływów i procesów – wolumen akceptacji, czas cyklu, rozkład po typach wniosków/procesach, obciążenie na jednostki organizacyjne.
• Ścieżka decyzji (audit trail) – widok „od wniosku do decyzji” z możliwością przejścia do szczegółu pojedynczej akceptacji, kroków i komentarzy (drill-through).
• Ryzyko i nadużycia – wskaźniki i sygnały ostrzegawcze (np. nietypowe wzorce zatwierdzeń, konflikty ról, anomalie czasowe).

W kontekście compliance ważna jest kontrola dostępu do raportów: użytkownicy powinni widzieć tylko to, do czego mają uprawnienia, a wrażliwe pola (np. komentarze zawierające dane osobowe) wymagają świadomej polityki ekspozycji.

Zapytania i filtry: szybkie odtwarzanie „kto, co, kiedy i dlaczego”

Raporty audytowe muszą pozwalać na błyskawiczne zawężenie zestawu zdarzeń bez utraty spójności ścieżki. W praktyce filtry powinny obejmować co najmniej:

• Zakres czasu (zdarzenie vs data utworzenia wniosku vs data finalizacji) i strefę czasową prezentacji.
• Identyfikatory korelacyjne procesu/wniosku/instancji akceptacji, aby odtwarzać pełny ciąg decyzji.
• Osoba/rola (zatwierdzający, zastępca, właściciel procesu) oraz jednostka organizacyjna.
• Obiekt biznesowy (typ wniosku, kategoria, krytyczność) oraz wynik (zaakceptowano/odrzucono/wygasło/anulowano).
• Podstawa decyzji rozumiana jako kontekst: reguła/polityka, próg, uzasadnienie, wymagane załączniki lub warunki formalne (na poziomie metadanych).

Ważne: w analizie audytowej „brak danych” też jest sygnałem. Filtry i miary powinny odróżniać sytuację, gdy atrybut nie dotyczy, od sytuacji, gdy powinien wystąpić, ale go nie zarejestrowano.

KPI, które mają sens w audycie akceptacji

Wskaźniki powinny odpowiadać na pytania kontrolne: czy proces działa zgodnie z polityką, czy decyzje są terminowe, czy ścieżki decyzyjne są kompletne i odporne na obejścia. Najczęściej przydatne KPI to:

• Czas do decyzji (średnia, mediana, percentyle) oraz odsetek decyzji po terminie.
• Współczynnik wyjątków (eskalacje, ponowne przypisania, zastępstwa, ręczne korekty) oraz ich trend.
• Kompletność śladu audytowego – udział rekordów z brakującymi wymaganymi atrybutami (np. brak identyfikatora wniosku, brak roli zatwierdzającego, brak wyniku).
• Zgodność ze ścieżką uprawnień – udział decyzji podjętych przez osoby poza oczekiwanym zakresem ról (sygnał do weryfikacji, nie automatyczny dowód naruszenia).
• Stabilność procesu – liczba błędów technicznych wpływających na akceptacje, odsetek powtórzeń, odsetek przerwanych przebiegów.
• Obciążenie zatwierdzających – wolumen decyzji na osobę/rolę i sezonowość (pomaga wykrywać wąskie gardła i ryzyko „hurtowych” zatwierdzeń).

Dobrą praktyką jest rozdzielenie KPI „biznesowych” (np. czas cyklu) od KPI stricte „dowodowych” (kompletność, zgodność z regułami, spójność korelacji), aby raporty nie mieszały efektywności z kontrolą.

Alerty: szybka reakcja na ryzyko i przerwy w kontroli

Alertowanie w audycie akceptacji powinno obejmować zarówno zdarzenia operacyjne, jak i naruszenia reguł kontrolnych. Typowe scenariusze alertów to:

• Przekroczenie SLA dla decyzji lub dla kluczowych kroków procesu.
• Wzrost odsetka odrzuceń/wygaśnięć w krótkim czasie (może wskazywać problem z jakością danych wejściowych, komunikacją lub działaniem automatyzacji).
• Nieciągłość śladu audytowego – pojawiające się rekordy bez wymaganych powiązań albo nagły spadek wolumenu logów (sygnał awarii rejestrowania).
• Nietypowe zachowanie zatwierdzającego – skok wolumenu decyzji, decyzje podejmowane poza typowymi godzinami pracy, seria identycznych decyzji w krótkim oknie czasowym.
• Sygnalizacja ryzyka uprawnień – decyzje podejmowane przy nietypowym przypisaniu roli lub przy częstych zastępstwach.

Alerty powinny być projektowane z myślą o niskiej liczbie fałszywych alarmów: lepiej mniej, ale takich, które uruchamiają konkretną procedurę weryfikacji i zostawiają ślad w obsłudze incydentu.

Wykrywanie anomalii: od prostych reguł do analizy trendów

Wykrywanie anomalii w kontekście „kto co zatwierdził” zwykle zaczyna się od prostych reguł jakości i spójności, a dopiero potem przechodzi do analizy behawioralnej i trendów. Przykładowe kategorie anomalii, które warto obserwować:

• Anomalie czasowe – decyzje w nienaturalnie krótkim czasie (np. „sekundowe” akceptacje), nietypowe pory dnia, nietypowe okna tygodnia.
• Anomalie wolumenowe – nagły wzrost liczby akceptacji w roli lub w konkretnym typie wniosku, „zrywy” po okresach ciszy.
• Anomalie ścieżki – pominięte kroki, nietypowa kolejność zdarzeń, częste cofnięcia i ponowne uruchomienia wniosków.
• Anomalie decyzyjne – odchylenia od typowych proporcji zaakceptowano/odrzucono dla danej kategorii, koncentracja decyzji na pojedynczej osobie.
• Anomalie danych – powtarzające się identyczne komentarze, brak wymaganych uzasadnień w przypadkach, gdzie powinny wystąpić, niespójne wartości atrybutów biznesowych.

W analizie anomalii liczy się kontekst: część wzorców może wynikać z sezonowości, zmian organizacyjnych albo zdarzeń jednorazowych. Dlatego raporty powinny wspierać porównania okresów, segmentację po procesach oraz szybkie przejście od sygnału do pełnej historii zdarzeń.

Przygotowanie materiału dowodowego na potrzeby kontroli

Raportowanie compliance powinno umożliwiać przygotowanie spójnego zestawu dowodowego: od listy zdarzeń spełniających kryteria kontroli, przez widok ścieżki decyzyjnej, po eksport wyników z zachowaniem filtrów i kryteriów. W praktyce oznacza to nacisk na jednoznaczne definicje miar, konsekwentne filtrowanie po identyfikatorach korelacyjnych oraz prezentację metadanych, które pozwalają obronić odpowiedź na pytanie: kto podjął decyzję, co zostało zatwierdzone, kiedy, na jakiej podstawie i z jakim wynikiem.

Checklist compliance i operacyjne utrzymanie

Audyt „kto co zatwierdził” ma wartość tylko wtedy, gdy jest użyteczny dowodowo i utrzymany procesowo. Poniższa lista kontrolna pomaga upewnić się, że logi akceptacji spełniają oczekiwania compliance (w tym RODO/GDPR) oraz że da się je bezpiecznie obsługiwać w cyklu życia rozwiązania. W Cognity łączymy teorię z praktyką – dlatego te obszary rozwijamy również w formie ćwiczeń na szkoleniach, na przykład na bazie rzeczywistych scenariuszy audytowych i operacyjnych.

RODO/GDPR: minimalizacja, podstawa, przejrzystość

• Cel przetwarzania: zdefiniuj, że logi służą do rozliczalności, audytu, wykrywania nadużyć i obsługi sporów.
• Podstawa prawna: określ właściwą podstawę (np. obowiązek prawny, prawnie uzasadniony interes) oraz udokumentuj ją w rejestrze czynności przetwarzania.
• Minimalizacja danych: zapisuj tylko to, co niezbędne do dowodu akceptacji; unikaj zbędnych pól opisowych i danych wrażliwych w komentarzach.
• Ograniczenie treści komentarzy: wprowadź zasady, by nie umieszczać w komentarzach danych szczególnych kategorii ani informacji nieadekwatnych do procesu.
• Transparentność: zapewnij informację o tym, że decyzje akceptacyjne są rejestrowane i jak długo dane są przechowywane (np. polityka prywatności/intranet).

Retencja i legal hold

• Polityka retencji: ustal okresy przechowywania osobno dla logów audytowych, treści biznesowej i załączników; dopasuj je do wymogów regulacyjnych i ryzyka.
• Automatyzacja egzekwowania: upewnij się, że retencja jest egzekwowana systemowo (a nie ręcznie), z jasnymi zasadami usuwania lub anonimizacji.
• Wyjątki i spory: przewidź mechanizm wstrzymania usunięcia (legal hold) na potrzeby dochodzeń, reklamacji lub postępowań.
• Spójność: dopilnuj, aby retencja obejmowała także kopie zapasowe i eksporty (częsty punkt niezgodności).

Dostęp, segregacja obowiązków i kontrola uprawnień

• Need-to-know: ogranicz dostęp do logów do wąskiej grupy ról (compliance, audyt, bezpieczeństwo, wybrane IT).
• Segregacja obowiązków: osoby rozwijające przepływy nie powinny mieć nieograniczonej możliwości modyfikowania lub kasowania logów.
• Kontrola dostępu do eksportu: traktuj eksport jako osobny wektor ryzyka; ogranicz, loguj i zatwierdzaj udostępnienia poza system.
• Przeglądy uprawnień: cyklicznie weryfikuj członkostwa w rolach, grupach i uprawnieniach do zasobów z logami.

eDiscovery, audyty wewnętrzne i gotowość dowodowa

• Możliwość wyszukiwania: upewnij się, że audyt da się przeszukać po kluczowych atrybutach (np. identyfikator sprawy, osoba, okres, status).
• Eksport kontrolowany: zdefiniuj ścieżkę przygotowania materiału dowodowego (zakres, autoryzacja, format, rejestr wydania).
• Łańcuch przekazania: prowadź rejestr kto i kiedy pobrał materiał, w jakim celu oraz gdzie został przekazany.
• Kompletność: ustal, jakie elementy stanowią „pełny pakiet dowodowy” (np. logi akceptacji, metadane uruchomień, powiązania z obiektem biznesowym).

Zarządzanie zmianą i środowiskami (governance)

• Kontrola zmian: każda zmiana w przepływach wpływających na audyt powinna przechodzić przez proces wnioskowania, testów i akceptacji.
• Rozdział środowisk: utrzymuj odseparowane środowiska dla rozwoju/testów/produkcji i pilnuj, by dane audytowe produkcyjne nie trafiały do środowisk nieprodukcyjnych.
• Rejestrowanie zmian konfiguracji: dokumentuj istotne ustawienia wpływające na audyt (np. retencja, polityki dostępu, integracje).
• Zależności i konektory: weryfikuj ryzyko i zgodność użytych połączeń oraz uprawnień serwisowych.

Testy, przeglądy i kontrola jakości audytu

• Testy kompletności: okresowo sprawdzaj, czy dla wszystkich decyzji akceptacyjnych powstają wpisy audytowe (w tym odrzucenia, anulowania i wyjątki).
• Testy odporności: weryfikuj, jak system zachowuje się przy błędach, ponowieniach i częściowych awariach, aby nie powstawały „dziury” w audycie.
• Testy uprawnień: wykonuj kontrolowane próby nieautoryzowanego dostępu i modyfikacji logów oraz oceniaj wyniki.
• Przeglądy cykliczne: co najmniej raz na kwartał oceniaj zgodność z politykami (retencja, dostępy, eksporty) oraz aktualność dokumentacji.

Operacyjne utrzymanie: monitoring, incydenty, ciągłość działania

• Monitoring: utrzymuj bieżącą obserwację awarii i opóźnień w rejestrowaniu zdarzeń; audyt bez monitoringu szybko traci wiarygodność.
• Obsługa incydentów: zdefiniuj procedurę postępowania, gdy logi są niekompletne, gdy wykryto podejrzenie manipulacji lub gdy nastąpił wyciek danych.
• Ciągłość działania: zapewnij plan odtwarzania oraz jasne RTO/RPO dla komponentów przechowujących logi.
• Wskaźniki operacyjne: śledź podstawowe metryki, takie jak odsetek brakujących wpisów, czas opóźnienia rejestracji, liczba nieudanych rejestracji i liczba eksportów.

Checklist do wdrożenia (skrót)

• Zdefiniowane: cel, podstawa prawna, zakres danych i zasady komentarzy.
• Ustalona i egzekwowana: retencja, legal hold, zasady usuwania/anonimizacji.
• Wdrożone: minimalne uprawnienia, segregacja obowiązków, przeglądy dostępów.
• Gotowość eDiscovery: wyszukiwanie, kontrolowany eksport, rejestr udostępnień.
• Governance: kontrola zmian, separacja środowisk, przegląd konektorów i kont serwisowych.
• Utrzymanie: monitoring, procedury incydentowe, testy okresowe, metryki jakości audytu.

Wykrywanie trendów i sezonowości bez ‘czarnej skrzynki’: STL i wizualne diagnostyki 20 kwietnia 2026

Analiza przeżycia (survival) w biznesie: churn, retencja i ‘czas do zdarzenia’ krok po kroku 18 kwietnia 2026