Równoległość w Power Automate bez duplikatów w SharePoint: ustawienia, które ratują dane

Skąd biorą się duplikaty w SharePoint, gdy Power Automate działa równolegle?

Duplikaty pojawiają się wtedy, gdy kilka równoległych wykonań przepływu lub kilka równoległych iteracji przetwarza ten sam rekord niemal w tym samym czasie i każda z nich „widzi”, że element jeszcze nie istnieje. W praktyce wygląda to jak klasyczny problem wyścigu: dwa procesy wykonują sprawdzenie typu Get items lub podobny warunek, oba dostają wynik „brak wpisu”, a następnie oba wykonują Create item. SharePoint nie blokuje automatycznie takiej logiki na poziomie biznesowym, więc jeśli przepływ nie ma własnego mechanizmu kontroli unikalności, powstają dwa lub więcej identycznych rekordów.

Najczęstsze źródło problemu to założenie, że odczyt i zapis są jedną operacją, podczas gdy w rzeczywistości są to osobne kroki. Między sprawdzeniem a utworzeniem elementu inny równoległy przebieg może wykonać dokładnie to samo. Im większa równoległość w wyzwalaczu, pętli Apply to each albo kilku jednoczesnych uruchomieniach przepływu, tym większe ryzyko takiej kolizji. Problem nasila się także wtedy, gdy dane wejściowe zawierają powtarzające się identyfikatory, a logika przepływu nie wymusza jednoznacznego klucza po stronie listy SharePoint.

Istotne jest też to, że samo filtrowanie po polu tekstowym lub wcześniejsze wyszukiwanie rekordu nie daje gwarancji braku duplikatu. To tylko stan odczytany w danym ułamku sekundy. Jeśli kilka instancji działa równocześnie, każda podejmuje decyzję na podstawie nieaktualnego z perspektywy innych instancji obrazu danych. Dlatego duplikaty nie wynikają zwykle z błędu SharePoint jako takiego, tylko z równoczesnego wykonania logiki „najpierw sprawdź, potem utwórz” bez zabezpieczenia przed konfliktem.

Jak działa Concurrency control i kiedy samo ograniczenie równoległości nie wystarczy?

Concurrency control w Power Automate określa, ile przebiegów danej pętli lub ile wywołań triggera może być wykonywanych jednocześnie. W praktyce jest to mechanizm ograniczania równoległości: zamiast uruchamiać wiele operacji naraz, przepływ może przetwarzać je sekwencyjnie albo w mniejszych partiach. Dzięki temu maleje ryzyko, że dwa przebiegi jednocześnie odczytają ten sam stan danych w SharePoint i niezależnie zapiszą sprzeczne lub zduplikowane wyniki.

To jednak nie jest mechanizm blokady danych. Concurrency control nie pilnuje integralności rekordu, tylko reguluje tempo i liczbę równoległych operacji. Jeżeli logika przepływu opiera się na schemacie „najpierw sprawdź, czy element istnieje, a potem go utwórz”, to nawet przy ograniczonej równoległości nadal może dojść do wyścigu, gdy kilka niezależnych uruchomień pracuje na tych samych danych wejściowych albo gdy źródło zdarzeń wygeneruje kilka podobnych wywołań w krótkim czasie.

Samo ograniczenie równoległości nie wystarczy przede wszystkim wtedy, gdy problem dotyczy unikalności danych, a nie tylko wydajności wykonania. Jeśli dwa przebiegi próbują dodać element o tym samym kluczu biznesowym, to bez dodatkowego zabezpieczenia nadal mogą powstać duplikaty. W takiej sytuacji potrzebny jest mechanizm, który egzekwuje regułę na poziomie danych lub zapisu, a nie wyłącznie na poziomie kolejności wykonywania akcji.

• Wystarcza częściowo, gdy chcesz zmniejszyć liczbę jednoczesnych zapisów i ograniczyć kolizje wynikające z dużej liczby równoległych operacji.
• Nie wystarcza, gdy kilka uruchomień może przetwarzać ten sam rekord lub ten sam identyfikator biznesowy.
• Nie wystarcza, gdy logika typu „Get items → jeśli brak, to Create item” ma zapewnić brak duplikatów bez dodatkowej kontroli unikalności.
• Nie wystarcza, gdy przepływ jest wyzwalany wielokrotnie przez zbliżone zdarzenia i każde uruchomienie działa niezależnie.

Najważniejsze jest więc rozróżnienie: Concurrency control zmniejsza prawdopodobieństwo konfliktu, ale nie zastępuje zabezpieczenia przed duplikatem. Jeśli wymagasz gwarancji, że dany rekord nie pojawi się dwa razy, potrzebujesz także reguły, która jednoznacznie odrzuci lub zablokuje drugi zapis tego samego klucza.

Jak zbudować wzorzec upsert w SharePoint, żeby flow aktualizował zamiast dodawać?

Wzorzec upsert w SharePoint polega na tym, że flow najpierw jednoznacznie sprawdza, czy rekord już istnieje, a dopiero potem wykonuje jedną z dwóch operacji: Update item dla istniejącego elementu albo Create item dla nowego. Kluczowe jest to, żeby identyfikacja rekordu nie opierała się na przypadkowym podobieństwie danych, tylko na stabilnym kluczu biznesowym, na przykład numerze zamówienia, identyfikatorze z systemu źródłowego albo innym polu, które powinno być unikalne.

Najbezpieczniejszy układ jest prosty: flow odbiera dane, wykonuje Get items z filtrem po tym kluczu, a następnie sprawdza, czy zwrócono element. Jeśli tak, pobiera jego ID i używa Update item. Jeśli nie, tworzy nowy element przez Create item. W praktyce warunek decyzyjny opiera się zwykle na liczbie znalezionych rekordów, czyli czy wynik ma 0 czy więcej niż 0 pozycji. To właśnie odróżnia upsert od schematu, który zawsze dodaje nowy wpis.

Żeby ten wzorzec naprawdę chronił przed duplikatami, samo wyszukiwanie nie wystarczy. Pole używane jako klucz powinno mieć w SharePoint wymuszoną unikalność. Bez tego dwa równoległe przebiegi mogą jednocześnie nie znaleźć elementu i oba spróbują go utworzyć. Unikalna kolumna powoduje, że drugi zapis zakończy się błędem zamiast wprowadzić duplikat. Dzięki temu flow nadal realizuje logikę upsert, a nie „search then maybe duplicate”.

Istotne jest też, by filtr w Get items był możliwie precyzyjny i zwracał maksymalnie jeden rekord dla danego klucza. Jeżeli zapytanie może zwrócić kilka pozycji, oznacza to problem z modelem danych, bo flow nie będzie wiedziało, który element należy aktualizować. W poprawnym wzorcu upsert wynik powinien być jednoznaczny: albo brak rekordu, albo dokładnie jeden rekord do aktualizacji.

W praktyce warto zapisywać klucz biznesowy w osobnej kolumnie tekstowej i traktować go jako główny punkt odniesienia dla integracji. Nie należy opierać upsertu wyłącznie na tytule, dacie czy zestawie pól, które mogą się zmienić. Jeśli identyfikator zewnętrzny jest stały, flow zawsze będzie wiedziało, który element zaktualizować, nawet gdy pozostałe dane ulegną zmianie.

Jeżeli środowisko pracuje równolegle, poprawny wzorzec upsert to więc nie tylko sekwencja Get items → decyzja → Update item/Create item, ale też dobrze dobrany unikalny klucz w SharePoint. Dopiero połączenie tych dwóch elementów sprawia, że flow aktualizuje istniejący rekord zamiast dodawać kolejny.

Jak wykorzystać unikalny klucz i walidację przed zapisem, żeby zablokować duplikaty?

Najpewniejszy sposób to połączyć dwie warstwy ochrony: walidację w przepływie przed utworzeniem elementu oraz kolumnę z wymuszoną unikalnością po stronie listy SharePoint. Sama walidacja zmniejsza liczbę duplikatów, ale przy równoległych uruchomieniach nie daje pełnej gwarancji, bo dwa przebiegi mogą jednocześnie sprawdzić, że rekordu jeszcze nie ma, a potem oba spróbują go zapisać. Dopiero unikalny klucz na liście blokuje taki wyścig na poziomie danych.

W praktyce najpierw trzeba zdefiniować, co oznacza duplikat. Jeśli ma być nim ten sam numer zamówienia, identyfikator z systemu źródłowego albo kombinacja kilku pól, utwórz dla tego jedną techniczną kolumnę, np. tekstową, i zapisuj w niej wartość klucza. Gdy duplikat zależy od kilku atrybutów, zbuduj klucz z tych pól w stałym formacie, np. Klient|Data|Typ. Taki klucz musi być deterministyczny: te same dane zawsze mają dawać dokładnie tę samą wartość.

Następnie w SharePoint włącz dla tej kolumny opcję wymuszania unikalnych wartości. To jest właściwe zabezpieczenie: jeśli dwa równoległe przebiegi spróbują dodać element z tym samym kluczem, pierwszy zapis się powiedzie, a drugi dostanie błąd konfliktu unikalności i nie utworzy duplikatu.

Walidacja przed zapisem nadal jest potrzebna, ale jako filtr wstępny. W przepływie przed akcją tworzenia elementu wykonaj wyszukanie po kluczu i sprawdź, czy rekord już istnieje. Jeśli tak, zakończ przebieg albo przejdź do aktualizacji zamiast tworzenia. To ogranicza liczbę niepotrzebnych prób zapisu i błędów, ale nie zastępuje unikalnego indeksu.

• Krok 1: oblicz unikalny klucz z danych wejściowych.
• Krok 2: sprawdź w SharePoint, czy element z tym kluczem już istnieje.
• Krok 3: jeśli nie istnieje, spróbuj utworzyć element z zapisanym kluczem.
• Krok 4: obsłuż błąd unikalności jako kontrolowany przypadek, a nie awarię logiki.

Kluczowe jest właśnie to ostatnie. Przy równoległości musisz założyć, że walidacja i zapis nie są jedną operacją atomową. Dlatego poprawny wzorzec brzmi: sprawdź przed zapisem, ale ufaj blokadzie unikalności. Jeśli zapis zwróci błąd, bo element już został dodany przez inny równoległy przebieg, potraktuj to jako sygnał, że duplikat został skutecznie zablokowany. W zależności od scenariusza możesz wtedy zakończyć przepływ statusem pominięcia albo pobrać istniejący rekord i pracować dalej na nim.

Żeby to działało stabilnie, klucz powinien być znormalizowany: bez przypadkowych spacji, z ujednoliconą wielkością liter i spójnym formatem dat lub liczb. Inaczej dwa logicznie identyczne rekordy mogą dostać różne klucze i przejść jako osobne wpisy.

Podsumowując: walidacja przed zapisem służy do wykrywania istniejących rekordów, a unikalny klucz w SharePoint jest ostateczną blokadą duplikatów. W środowisku z równoległym przetwarzaniem dopiero takie połączenie daje praktycznie bezpieczny mechanizm ochrony danych.

Jak radzić sobie z retry i ponownym uruchomieniem flow, żeby nie tworzyć kopii danych?

Podstawowa zasada jest prosta: flow musi być idempotentne, czyli wielokrotne wykonanie tego samego kroku nie może tworzyć nowego rekordu, jeśli rekord już istnieje. W praktyce oznacza to, że nie należy opierać logiki na samym akcjach Create item bez wcześniejszego sprawdzenia, czy dany wpis został już zapisany.

Najbezpieczniej jest nadać każdej operacji własny unikalny identyfikator biznesowy, na przykład ID dokumentu z systemu źródłowego, numer zamówienia albo kombinację pól, która jednoznacznie identyfikuje rekord. Następnie flow przed utworzeniem elementu powinno wyszukać wpis w SharePoint po tym identyfikatorze. Jeśli rekord istnieje, należy go zaktualizować albo pominąć tworzenie; jeśli nie istnieje, dopiero wtedy utworzyć nowy element.

To ważne szczególnie przy retry, ponieważ Power Automate może ponowić akcję po błędzie przejściowym, a przy resubmit lub ręcznym ponownym uruchomieniu cały przepływ może wykonać się jeszcze raz dla tych samych danych. Bez kontroli unikalności każda taka próba może zakończyć się duplikatem.

• Włącz kontrolę po kluczu unikalnym — przechowuj w SharePoint pole z wartością jednoznacznie identyfikującą rekord i traktuj je jako punkt odniesienia przy każdym uruchomieniu.
• Najpierw sprawdzaj, potem zapisuj — schemat powinien być: odczyt po kluczu, decyzja, aktualizacja albo utworzenie. Samo ponawianie akcji zapisu bez tego kroku jest ryzykowne.
• Ogranicz retry tam, gdzie zapis nie jest bezpieczny — dla akcji tworzących rekord warto świadomie ustawić politykę ponawiania, jeśli system docelowy nie gwarantuje ochrony przed duplikatem.
• Zapisuj stan przetworzenia — jeśli flow obsługuje większy proces, dobrze jest oznaczać, że dany rekord został już przetworzony, aby kolejne uruchomienie mogło to rozpoznać.

W SharePoint dodatkowym zabezpieczeniem może być ustawienie kolumny jako unikalnej. Wtedy nawet jeśli flow spróbuje utworzyć kopię z tym samym kluczem, SharePoint odrzuci zapis. To nie zastępuje poprawnej logiki w flow, ale działa jako skuteczna warstwa ochronna.

Jeżeli flow już zapisuje dane i może być uruchamiane ponownie, bezpieczniejszy jest wzorzec update-or-create niż bezwarunkowe tworzenie. Dzięki temu retry i ponowne uruchomienie nie zmieniają wyniku biznesowego, tylko najwyżej doprowadzają rekord do właściwego stanu.

Jak obsłużyć konflikty aktualizacji (ETag) i uniknąć nadpisywania zmian innych osób?

ETag w SharePoint to identyfikator wersji elementu. Gdy Power Automate odczytuje element, pobiera też jego aktualny ETag. Jeśli w międzyczasie ktoś inny zmieni ten sam rekord, ETag przestaje być aktualny. Przy próbie zapisu z użyciem starego ETag SharePoint zwraca konflikt aktualizacji zamiast po cichu nadpisać nowsze dane. To jest mechanizm ochrony przed utratą zmian.

Aby nie nadpisywać pracy innych osób, przepływ powinien działać według zasady: odczytaj najnowszy stan, wprowadź zmianę możliwie szybko i zapisuj tylko wtedy, gdy wersja elementu nadal jest taka sama jak w momencie odczytu. W praktyce oznacza to unikanie długiej przerwy między pobraniem elementu a jego aktualizacją oraz ograniczenie równoległych modyfikacji tego samego wpisu. Im więcej kroków i opóźnień między odczytem a zapisem, tym większe ryzyko konfliktu.

Jeżeli konflikt ETag już wystąpi, poprawna obsługa nie polega na ślepym ponowieniu zapisu tymi samymi danymi. Najpierw trzeba ponownie pobrać element z SharePoint i porównać jego bieżący stan z tym, co przepływ chciał zapisać. Dopiero wtedy można zdecydować, czy bezpiecznie zastosować zmianę ponownie, czy przerwać operację i zgłosić konflikt. To ważne, bo automatyczne nadpisanie po ponownym odczycie może skasować legalną zmianę wprowadzoną przez innego użytkownika lub inny przepływ.

Najbezpieczniejsze podejście to aktualizować tylko te pola, które rzeczywiście mają zostać zmienione, i nie odtwarzać całego elementu na podstawie starego odczytu. Jeśli przepływ pobrał rekord, a później wysyła pełny zestaw pól, łatwo przypadkowo przywrócić starsze wartości w kolumnach zmodyfikowanych przez kogoś innego. Aktualizacja minimalnego zakresu danych znacząco zmniejsza ryzyko utraty zmian.

W scenariuszach wrażliwych na spójność danych warto traktować błąd konfliktu jako sygnał biznesowy, a nie tylko techniczny wyjątek. Jeżeli element został zmieniony po odczycie, przepływ powinien przejść do kontrolowanej ścieżki: ponowny odczyt, ocena różnic, ewentualnie nowa próba tylko wtedy, gdy logika procesu na to pozwala. Jeżeli nie ma pewności, że ponowienie jest bezpieczne, lepiej zakończyć operację błędem niż nadpisać cudze zmiany.

W skrócie: ETag służy do wykrywania, że zapisujesz nieaktualną wersję elementu. Aby uniknąć nadpisywania zmian innych osób, trzeba skrócić czas między odczytem a zapisem, ograniczyć równoczesne aktualizacje tego samego rekordu, ponownie pobierać element po konflikcie i zapisywać wyłącznie te pola, które faktycznie mają zostać zmienione.

Jak przetestować równoległość, żeby wyłapać duplikaty zanim pojawią się na produkcji?

Najpewniejszy test polega na sztucznym wywołaniu wielu uruchomień tego samego przepływu w tym samym czasie na danych, które celowo mają ten sam klucz biznesowy, czyli wartość, po której rozpoznajesz, że rekord powinien być tylko jeden. Jeśli przepływ ma tworzyć element w SharePoint tylko raz dla danego identyfikatora, to właśnie ten identyfikator musi być powtarzany w serii równoległych wywołań. Test z różnymi danymi nie pokaże problemu z duplikacją, bo nie odtworzy rzeczywistego wyścigu między instancjami.

W praktyce test powinien być wykonany w środowisku testowym, na osobnej liście SharePoint, z włączonym logowaniem wartości diagnostycznych. Dobrze jest zapisywać w historii przepływu lub w dodatkowych kolumnach czas rozpoczęcia, identyfikator uruchomienia, wartość klucza biznesowego oraz wynik operacji sprawdzania i tworzenia rekordu. Dzięki temu można odróżnić sytuację, w której dwa przebiegi jednocześnie odczytały brak rekordu, od sytuacji, w której jeden już zdążył zapisać dane, a drugi poprawnie wykrył istniejący element.

Kluczowe jest, aby testować nie tylko pojedynczy przebieg, ale serię równoczesnych prób. Jeśli przepływ przechodzi poprawnie przy jednym uruchomieniu, nie mówi to nic o odporności na race condition. Duplikaty pojawiają się zwykle wtedy, gdy kilka instancji niemal jednocześnie wykonuje sekwencję typu: Get items albo sprawdzenie istnienia rekordu, a zaraz potem Create item. Właśnie ten krótki odstęp czasowy trzeba odtworzyć pod obciążeniem.

Dobrym kryterium zaliczenia testu nie jest samo to, że przepływ zakończył się bez błędu, tylko to, że po serii równoległych wywołań w SharePoint nadal istnieje dokładnie jeden element dla danego klucza. Po teście trzeba więc sprawdzić nie tylko historię uruchomień, ale przede wszystkim zawartość listy: liczbę rekordów z tym samym identyfikatorem, ewentualne różnice w czasie utworzenia i to, czy błędy były kontrolowane, a nie losowe.

Jeżeli chcesz wykryć problem wcześniej, warto przeprowadzić dwa rodzaje prób. Pierwsza to test bezpośredniego zderzenia, czyli wiele identycznych wywołań na tej samej wartości. Druga to test mieszany, gdzie część danych jest unikalna, a część powtarzalna. Taki układ pomaga sprawdzić, czy mechanizm ochrony przed duplikatami działa selektywnie i nie blokuje poprawnych zapisów, gdy rekord faktycznie powinien zostać utworzony.

Bardzo ważne jest też sprawdzenie zachowania po kilku powtórzeniach testu, a nie tylko raz. Problemy z równoległością bywają nieregularne, bo zależą od momentu wykonania poszczególnych akcji i opóźnień po stronie SharePoint. Jeśli duplikat pojawia się raz na kilkanaście prób, to nadal jest realnym błędem produkcyjnym. Dlatego test trzeba wykonać wielokrotnie na tej samej logice i dopiero brak duplikatów w powtarzalnych seriach można uznać za sensowny sygnał, że przepływ jest zabezpieczony.

Najbardziej wiarygodny wynik daje połączenie testu równoczesnych uruchomień z kontrolą po stronie danych, na przykład przez unikalną kolumnę lub inny twardy mechanizm wymuszający niepowtarzalność. Wtedy test nie tylko pokazuje, czy logika przepływu działa, ale też czy w razie wyścigu system potrafi zablokować drugi zapis. Jeśli po takich próbach nie ma wielu rekordów z tym samym kluczem, a ewentualne odrzucone zapisy są przewidywalne i widoczne w logach, to znaczy, że ryzyko duplikatów zostało realnie sprawdzone przed produkcją.

Aplikacje webowe z Claude Code: gdzie AI oszczędza dni pracy, a gdzie psuje projekt 28 maja 2026

Debugowanie z Claude Code: najszybsza droga od błędu do poprawki 26 maja 2026