PowerApps offline: 8 wzorców cache, synchronizacji i konfliktów w terenie

1. Wprowadzenie: wymagania i ograniczenia aplikacji PowerApps działających offline

Tryb offline w Power Apps nie oznacza „pełnej pracy bez internetu” w każdym scenariuszu, lecz świadomie zaprojektowane zachowanie aplikacji, które pozwala użytkownikowi kontynuować kluczowe zadania w terenie mimo przerw w łączności. W praktyce aplikacja offline musi umieć: przechować dane lokalnie, umożliwić edycję bez dostępu do źródła, a po powrocie sieci bezpiecznie zsynchronizować zmiany.

Najważniejsza różnica względem aplikacji „online-first” polega na tym, że źródło prawdy chwilowo przenosi się na urządzenie. To wymusza inne podejście do danych: zamiast polegać na bieżących odczytach/zapisach do konektorów, aplikacja pracuje na kopii danych oraz rejestruje zmiany, które dopiero później trafiają do systemów backendowych.

Kluczowe wymagania scenariuszy terenowych

• Odporność na zrywanie połączenia – użytkownik nie może „utknąć” w połowie formularza; operacje muszą działać mimo chwilowej utraty internetu.
• Szybki start i płynność interfejsu – w terenie liczy się czas; aplikacja nie powinna zależeć od natychmiastowego pobrania danych z sieci.
• Praca na ograniczonym transferze – często obowiązują limity danych komórkowych; aplikacja powinna pobierać tylko to, co niezbędne.
• Jednoznaczność danych – aplikacja musi wiedzieć, które dane są „lokalne”, które „zsynchronizowane”, a które „w kolejce do wysłania”.
• Bezpieczeństwo i prywatność – lokalne przechowywanie danych powinno uwzględniać ryzyko utraty urządzenia, dostęp innych użytkowników oraz wrażliwość informacji.

Typowe ograniczenia i ryzyka w Power Apps offline

Projektowanie offline wiąże się z konkretnymi ograniczeniami platformy i urządzeń. Najczęściej problemem nie jest samo „brak internetu”, lecz konsekwencje tego stanu:

• Brak gwarancji dostępności konektorów – zapisy do źródeł danych mogą się nie powieść; aplikacja powinna zakładać niepowodzenia i działać dalej.
• Ograniczenia pamięci i trwałości danych na urządzeniu – lokalna przestrzeń jest skończona, a dane mogą zostać usunięte przez system, aktualizację aplikacji lub działania użytkownika.
• Niejednoznaczna „świeżość” danych – offline zwiększa ryzyko pracy na nieaktualnych informacjach; trzeba akceptować kompromisy między aktualnością a dostępnością.
• Konflikty edycji – te same rekordy mogą zostać zmienione na różnych urządzeniach lub w systemie centralnym, zanim nastąpi synchronizacja.
• Zmienność jakości łączności – częste są stany pośrednie: słaby zasięg, wysokie opóźnienia, portal captive; aplikacja musi reagować na wahania, a nie tylko na prosty podział online/offline.

Co warto ustalić przed implementacją trybu offline

Skuteczny offline zaczyna się od decyzji produktowych, nie od formuł. Jeszcze przed budową warto doprecyzować:

• Zakres funkcji dostępnych offline – które ekrany i procesy muszą działać bez sieci, a które mogą być „tylko online”.
• Zakres danych – jakie dane są krytyczne w terenie i w jakiej objętości mają być dostępne lokalnie.
• Model edycji – czy użytkownik ma tworzyć nowe rekordy, edytować istniejące, dodawać załączniki, wykonywać akcje zbiorcze.
• Wymagania dotyczące spójności – czy dopuszczalne jest „eventual consistency”, czy potrzebna jest blokada, rezerwacja lub rygorystyczna kontrola wersji.
• Oczekiwania operacyjne – jak aplikacja ma komunikować stan: brak sieci, kolejka zmian, błędy synchronizacji, konieczność ponowienia.

Te założenia determinują późniejszy dobór wzorców: sposób cache’owania, zapisu lokalnego, synchronizacji i radzenia sobie z konfliktami. W kolejnych częściach artykułu będą rozwijane konkretne podejścia, ale fundamentem pozostaje jedno: offline to osobny tryb pracy aplikacji, który wymaga jawnego modelu danych, stanów i odpowiedzialności za synchronizację.

2. Wzorce danych offline (1–3): cache danych, kolekcje robocze, lokalne zapisy (SaveData/LoadData)

Projektując PowerApps do pracy w terenie bez stałego połączenia, kluczowe jest rozdzielenie trzech ról danych: co użytkownik ma „widzieć” (cache referencyjny), na czym ma „pracować” (kolekcje robocze) oraz co ma „przetrwać” zamknięcie aplikacji i restart urządzenia (lokalny zapis). Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj. Te wzorce często współistnieją, ale każdy rozwiązuje inny problem i ma inne konsekwencje dla spójności, rozmiaru danych i doświadczenia użytkownika.

Wzorzec 1: Cache danych (dane referencyjne / do odczytu)

Cache to lokalna kopia danych potrzebnych głównie do wyświetlania i wyboru: listy słownikowe, katalogi, ostatnio oglądane rekordy, podstawowe metadane. Celem cache jest to, aby aplikacja w trybie offline nadal była użyteczna: użytkownik może przeglądać wcześniej pobrane informacje i wypełniać formularze z wykorzystaniem wartości referencyjnych.

• Zastosowania: listy wyboru, dane pomocnicze do walidacji, podgląd ostatnich zadań, uproszczone kartoteki.
• Charakter danych: zwykle „read-mostly” (rzadko zmieniane przez użytkownika), często aktualizowane dopiero po odzyskaniu sieci.
• Najważniejsza decyzja: jak szeroki ma być cache (pełna lista vs. tylko zakres potrzebny w danym rejonie/okresie) oraz kiedy uznawać go za przestarzały.

Cache nie powinien udawać źródła prawdy. To świadomy kompromis: lepsza dostępność i szybkość kosztem ryzyka, że część danych będzie nieaktualna do czasu synchronizacji.

Wzorzec 2: Kolekcje robocze (stan edycji i praca „w toku”)

Kolekcje robocze służą do przechowywania bieżącego stanu pracy użytkownika w aplikacji: wprowadzanych zmian, rekordów tworzonych offline, tymczasowych obliczeń, filtrów i selekcji. W praktyce są to dane, które mają być natychmiast dostępne dla UI i logiki aplikacji, niezależnie od łączności.

• Zastosowania: edycja formularzy offline, dodawanie pozycji do „koszyka” operacji, lokalne walidacje i podsumowania, praca na zestawie rekordów pobranych wcześniej.
• Charakter danych: dynamiczne, często zmieniane, ściśle powiązane z interakcją użytkownika.
• Najważniejsza decyzja: jak modelować stan: oddzielnie przechowywać dane „oryginalne” i „zmienione”, czy utrzymywać jeden zestaw i oznaczać elementy jako zmodyfikowane.

Kolekcje robocze poprawiają responsywność i pozwalają projektować interfejs tak, jakby działał „lokalnie”. Jednocześnie nie gwarantują trwałości — same w sobie nie zabezpieczają pracy przed utratą po zamknięciu aplikacji.

Wzorzec 3: Lokalny zapis (SaveData/LoadData) jako trwały cache

SaveData/LoadData to podejście do utrwalenia wybranych danych na urządzeniu, aby przetrwały restart aplikacji, rozładowanie baterii lub chwilowe problemy z systemem. Jest to naturalne uzupełnienie dwóch pierwszych wzorców: zapisujesz to, co musi zostać zachowane między sesjami.

• Zastosowania: przechowanie cache referencyjnego, zachowanie „pracy w toku”, magazyn lokalnych rekordów utworzonych offline, przechowanie ustawień użytkownika.
• Charakter danych: podzbiór tego, co aplikacja trzyma w pamięci; powinien być ograniczony do minimum potrzebnego do kontynuacji pracy.
• Najważniejsza decyzja: co zapisywać i jak często: zapis zbyt rzadki grozi utratą pracy, zbyt częsty może obniżać wydajność i zwiększać ryzyko niespójności.

Trwały zapis lokalny nie jest równoważny z centralną bazą danych: pomaga przetrwać brak sieci i przerwy w działaniu aplikacji, ale wymaga świadomego podejścia do wersjonowania przechowywanych struktur oraz odświeżania po odzyskaniu połączenia.

Jak dobrać wzorzec do potrzeby (w skrócie)

• Cache danych wybierz, gdy celem jest dostęp offline do informacji „do odczytu” i stabilnych słowników.
• Kolekcje robocze wybierz, gdy potrzebujesz płynnej edycji i natychmiastowego odzwierciedlania zmian w UI bez zależności od sieci.
• SaveData/LoadData dodaj, gdy musisz zapewnić ciągłość pracy między uruchomieniami aplikacji i ochronić dane przed utratą w razie przerwania sesji.

W dobrze zaprojektowanej aplikacji terenowej te trzy elementy tworzą „warstwę offline”: cache zapewnia kontekst, kolekcje robocze dają ergonomię pracy, a zapis lokalny gwarantuje trwałość tego, co nie może zniknąć.

3. Wzorce synchronizacji (4–5): kolejka zmian i synchronizacja po odzyskaniu połączenia

Synchronizacja offline w PowerApps zwykle opiera się na dwóch uzupełniających się wzorcach: kolejce zmian (rejestrowanie operacji wykonanych bez sieci) oraz synchronizacji po odzyskaniu połączenia (bezpieczne „wypchnięcie” zmian do źródeł i odświeżenie danych). Ich celem nie jest tylko „wysłanie danych”, ale zapewnienie spójności, odporności na błędy i przewidywalnego zachowania w terenie.

Wzorzec 4: Kolejka zmian (offline change queue)

Kolejka zmian przechowuje intencję użytkownika jako serię operacji (np. utwórz/edytuj/usuń), zamiast próbować od razu zapisywać do zewnętrznego źródła. Dzięki temu aplikacja pozostaje użyteczna offline, a synchronizacja staje się procesem kontrolowanym i powtarzalnym.

• Co trafia do kolejki: minimalny opis operacji (typ, identyfikator rekordu lokalny/zdalny, pola zmienione, znaczniki czasu, informacje o zależnościach).
• Po co: umożliwia pracę bez połączenia, obsługuje wielokrotne próby wysyłki, a także pozwala uporządkować kolejność zmian (np. „utwórz” przed „aktualizuj”).
• Kiedy działa najlepiej: przy formularzach terenowych, inspekcjach, inwentaryzacjach, gdy urządzenie często traci zasięg.
• Kluczowa decyzja projektowa: czy kolejkujemy operacje (zalecane), czy pełne snapshoty rekordów (prostsze, ale cięższe i bardziej podatne na konflikty).

Wzorzec 5: Synchronizacja po odzyskaniu połączenia (reconnect & sync)

Ten wzorzec opisuje, jak aplikacja wykrywa powrót łączności i uruchamia proces synchronizacji: najpierw wysyła zaległe zmiany z kolejki, a następnie odświeża dane referencyjne/robocze. Najważniejsza jest odporność: przerwanie połączenia w połowie nie powinno psuć stanu ani generować duplikatów.

• Wyzwalanie: ręczne (przycisk „Synchronizuj”), automatyczne (np. timer), zdarzeniowe (np. wykrycie, że połączenie wróciło).
• Przepływ wysokiego poziomu: (1) walidacja lokalna i przygotowanie paczki, (2) wysłanie zmian w kontrolowanej kolejności, (3) oznaczenie pozycji jako „zsynchronizowane” lub „do ponowienia”, (4) odświeżenie danych z serwera.
• Zasada bezpieczeństwa: synchronizacja powinna być restartowalna (po awarii można ją uruchomić ponownie bez szkód).
• Wymóg praktyczny: rozdzielenie „zapisu lokalnego” od „zapisu zdalnego” — użytkownik kończy pracę nawet bez sieci, a synchronizacja jest procesem technicznym.

Uwaga praktyczna: oba wzorce często występują razem. Sama kolejka bez procedury synchronizacji nie rozwiąże problemu „kiedy i jak wysłać”, a synchronizacja bez kolejki zwykle kończy się próbami zapisu „na żywo”, które są kruche w warunkach terenowych.

// Uzupełniający szkic (Power Fx):
// 1) Dodanie operacji do kolejki
// Collect(colQueue, {op:"Update", localId: ThisItem.LocalId, payload: {...}, ts: Now()})

// 2) Synchronizacja po odzyskaniu połączenia (idea):
// If(Connection.Connected, ForAll(colQueue, ... wysyłka ...));

4. Wzorzec rozwiązywania konfliktów (6): strategie, identyfikatory wersji i reguły scalania

W trybie offline konflikt pojawia się wtedy, gdy ta sama encja (rekord) została zmieniona niezależnie w dwóch miejscach: lokalnie na urządzeniu oraz na źródle danych (lub na innym urządzeniu), a następnie obie wersje próbują zostać zapisane jako „prawda”. W terenie to typowe: użytkownik edytuje dane bez sieci, a w tym czasie ktoś inny (albo automaty) zmienia rekord online.

Wzorzec rozwiązywania konfliktów składa się z trzech elementów:

• Strategia (jaką decyzję podejmujemy przy konflikcie),
• Identyfikator wersji (po czym wykrywamy, że konflikt zaszedł),
• Reguły scalania (jak łączymy zmiany, jeśli nie chcemy „wygrywa wszystko/ni nic”).

W czasie szkoleń Cognity ten temat bardzo często budzi ożywione dyskusje między uczestnikami, bo w praktyce „najlepsza” strategia zależy od wagi danych, częstotliwości konfliktów i tego, ile tarcia możesz zaakceptować w UX.

Strategie rozwiązywania konfliktów: kiedy która ma sens

Identyfikatory wersji: jak wykrywać konflikt

Sama informacja „rekord istnieje” nie wystarcza. Potrzebujesz sygnału, że od czasu pobrania danych lokalnych rekord na serwerze się zmienił. Najczęściej stosuje się:

• ETag / row version (optymistyczna kontrola współbieżności): zapis jest akceptowany tylko, jeśli wersja rekordu na serwerze zgadza się z tą, którą widział klient.
• Znacznik czasu modyfikacji (np. ModifiedOn): klient porównuje daty i wykrywa rozjazd; dobre do wykrywania, słabsze jako twarda blokada.
• Własny licznik wersji (Version = Version+1): prosty model do porównań i merge, o ile jest utrzymywany atomowo po stronie źródła danych.
• Hash/sumaryczny odcisk pól: wykrywa zmianę treści, ale utrudnia wskazanie, które pola się zmieniły.

W kontekście Power Apps kluczowe jest rozróżnienie: wykrycie konfliktu (porównanie wersji) vs rozstrzygnięcie konfliktu (co robimy dalej). Wzorzec zakłada, że już w danych roboczych przechowujesz minimalny „ślad wersji” (np. ETag/RowVersion lub ModifiedOn) razem z rekordem.

Reguły scalania: podstawowe podejścia

Jeśli nie chcesz prostego LWW/FWW, potrzebujesz reguł merge. Na poziomie wzorca warto przyjąć jedną z trzech dróg:

• Scalanie „lokalne wygrywa” dla wybranych pól: np. notatki terenowe zawsze z urządzenia, ale status i właściciel zawsze z serwera.
• Scalanie „serwer wygrywa” z dopisaniem lokalnych zmian jako komentarz/załącznik: gdy nie można stracić treści, ale nie wolno nadpisywać pól formalnych.
• Scalanie na podstawie „intencji” (zmiany jako operacje): zamiast wysyłać cały rekord, wysyłasz operacje typu „zwiększ licznik”, „dodaj pozycję”, „ustaw status” – łatwiej to scalać niż surowe wartości.

Praktyczna zasada: im bardziej dane są komutatywne (np. dopisywanie elementów listy, sumowanie), tym łatwiejszy merge automatyczny. Im bardziej są stanowe (np. pojedyncze pole Status), tym częściej potrzebujesz FWW albo ręcznej decyzji.

Minimalny „kontrakt” danych dla obsługi konfliktów

Aby wzorzec był wykonalny, rekord w warstwie roboczej zwykle niesie obok danych biznesowych kilka metapól (nawet jeśli są tylko w kolekcji, a nie w źródle):

• Id rekordu (stabilny klucz),
• VersionToken (ETag/RowVersion/ModifiedOn – cokolwiek, co pozwoli porównać wersje),
• DirtyFields lub flaga „zmieniono” (żeby wiedzieć, co scalać),
• LocalUpdatedAt (do UI i priorytetyzacji, nie jako jedyne źródło prawdy),
• ConflictState (np. None/Detected/Resolved) ułatwiający obsługę w interfejsie.

Sygnalizacja konfliktu w aplikacji (bez rozbudowy UI)

Na poziomie doświadczenia użytkownika najważniejsze jest, aby konflikt nie był „cichą porażką”. Nawet jeśli rozstrzygasz automatycznie, warto:

• oznaczyć rekord jako wymagający uwagi (np. ikoną lub statusem),
• zachować obie wersje (przynajmniej tymczasowo) dla audytu lub cofnięcia,
• pokazać krótką przyczynę: „Rekord zmienił się na serwerze od czasu pobrania”.

Uzupełniający przykład (Power Fx): porównanie tokenu wersji

Poniższy fragment ilustruje ideę: mamy lokalny rekord z zapisanym VersionToken oraz świeżo pobraną wersję z serwera. Jeśli tokeny się różnią, oznaczamy konflikt zamiast bezwarunkowo nadpisywać:

// Założenia: ThisItem zawiera lokalne dane i ThisItem.VersionToken
// serverRec pochodzi z odświeżenia danych (np. LookUp(...) po odzyskaniu sieci)
If(
    ThisItem.VersionToken <> serverRec.VersionToken,
    Patch(
        colWork,
        ThisItem,
        { ConflictState: "Detected" }
    ),
    // brak konfliktu - można kontynuować zapis lub merge
    Patch(
        colWork,
        ThisItem,
        { ConflictState: "None" }
    )
);

To nie jest pełna synchronizacja, tylko rdzeń wzorca: detekcja (porównanie wersji) i ustawienie stanu, który umożliwia wybraną strategię (LWW/FWW/merge/manual).

5. Wydajność i oszczędność transferu (7): minimalizacja payloadu, delta sync, batchowanie i retry

Tryb offline w Power Apps zwykle oznacza, że synchronizacja będzie wykonywana rzadziej, w trudniejszych warunkach sieciowych i często na urządzeniach o ograniczonych zasobach. Dlatego projekt danych i synchronizacji powinien minimalizować ilość przesyłanych informacji oraz redukować liczbę wywołań do źródeł danych. Ta sekcja zbiera najważniejsze wzorce optymalizacji: minimalizacja payloadu, delta sync, batchowanie i retry.

Minimalizacja payloadu: przesyłaj tylko to, co niezbędne

Najczęstszy błąd to traktowanie synchronizacji jak „pełnego odświeżenia” – pobieranie lub wysyłanie całych rekordów, mimo że użytkownik zmienił 1–2 pola. W offline-first celem jest: mniej danych i mniej pól.

• Ogranicz pola: pobieraj tylko atrybuty potrzebne na ekranach offline (np. identyfikator, nazwa, status, data modyfikacji). Pola ciężkie (opisy, załączniki) dociągaj na żądanie.
• Ogranicz liczbę rekordów: filtruj po obszarze pracy (np. przypisany użytkownik, region, ostatnie N dni), zamiast „wszystko”.
• Unikaj dużych binariów: zdjęcia/załączniki synchronizuj osobnym mechanizmem i osobnym harmonogramem (np. tylko na Wi‑Fi), a w podstawowym cache trzymaj jedynie metadane.
• Uważaj na zbyt szerokie kolekcje: nawet jeśli dane są „lokalne”, ich przygotowanie i serializacja wpływają na czas uruchomienia i pamięć urządzenia.

Delta sync: pobieraj i wysyłaj różnice zamiast pełnych zestawów

Delta sync polega na tym, że aplikacja pamięta punkt odniesienia (np. znacznik czasu lub numer wersji) i przy kolejnym połączeniu pobiera tylko rekordy zmienione od tego momentu, zamiast całego zbioru.

• Delta na pobieraniu: ściągaj zmiany od ostatniej udanej synchronizacji, a cache uzupełniaj/inwaliduj selektywnie.
• Delta na wysyłaniu: wysyłaj tylko listę zmodyfikowanych pól (jeśli architektura na to pozwala) lub minimalny rekord zmian (np. ID + pola edytowane).
• Wykrywanie zmian: najczęściej opiera się o LastModified, RowVersion/ETag lub licznik wersji rekordu.

Uwaga praktyczna: delta sync wymaga konsekwentnego prowadzenia „checkpointu” synchronizacji (np. ostatni znacznik czasu), ale nie przesądza jeszcze o tym, jak rozwiązać konflikty – to osobny temat.

Batchowanie: mniej wywołań, mniej narzutu

W terenie kosztowne jest nie tylko przesłanie danych, ale i sam „narzut” połączeń: handshake, autoryzacja, latency. Batchowanie polega na grupowaniu zmian i wysyłaniu ich paczkami.

• Grupowanie operacji: zamiast wysyłać 20 pojedynczych zapisów, wyślij 1 paczkę zawierającą 20 zmian.
• Ogranicz rozmiar paczki: dobierz wielkość batcha tak, by nie generować time-outów i nie blokować UI (np. paczki po 20–100 zmian, zależnie od danych).
• Batch per encja: często prościej utrzymać paczki osobno dla różnych typów danych (np. „inspekcje”, „zdjęcia”, „komentarze”), bo mają inne priorytety i rozmiary.

Retry: odporność na niestabilną sieć bez dublowania zapisów

Retry to kontrolowane ponawianie operacji, które mogły się nie udać z powodów chwilowych (brak zasięgu, timeout, chwilowe błędy serwera). W offline-first retry nie jest „miłym dodatkiem” – to podstawowy mechanizm zapewnienia dostarczenia zmian.

• Retry z backoff: każde kolejne ponowienie wykonuj po dłuższej przerwie (np. 2s, 5s, 15s…), aby nie przeciążać sieci i serwera.
• Retry tylko dla błędów przejściowych: nie ponawiaj w kółko błędów walidacji lub uprawnień – to wymaga interwencji użytkownika lub korekty danych.
• Idempotencja: jeśli ta sama zmiana może zostać wysłana ponownie, serwer/warstwa integracji powinna umieć rozpoznać duplikat (np. po unikalnym identyfikatorze operacji) i nie tworzyć podwójnych rekordów.
• Priorytety: ważniejsze operacje (np. zamknięcie zlecenia) mogą mieć wyższy priorytet niż dane pomocnicze.

Krótki przykład: „cienki” rekord zmiany i paczkowanie

Poniżej szkic idei (nie pełna implementacja): zamiast wysyłać cały rekord, utrzymuj listę zmian jako małe obiekty i wysyłaj je paczkami.

// Koncepcja: zmiana jako minimalny obiekt
// { opId, entity, recordId, fieldsChanged, changedAt }

W praktyce dobór technik jest kumulatywny: delta sync zmniejsza ilość pobieranych danych, minimalizacja payloadu redukuje „szerokość” rekordów, batchowanie ogranicza liczbę wywołań, a retry zapewnia dostarczenie w niestabilnych warunkach.

6. Obserwowalność (8): telemetria błędów, logi offline i diagnostyka synchronizacji

Aplikacja terenowa działająca offline potrafi „milczeć” dokładnie wtedy, gdy dzieje się najwięcej: użytkownik wprowadza dane bez zasięgu, kolejkuje zmiany, a po powrocie sieci synchronizacja może częściowo się udać, częściowo nie — i bez śladu w systemie. Dlatego obserwowalność w trybie offline oznacza świadome projektowanie: co rejestrować, gdzie to przechowywać bez sieci, jak wysłać po odzyskaniu połączenia oraz jak ułatwić diagnostykę bez ingerencji w logikę biznesową.

Co warto obserwować w scenariuszach offline

• Stan łączności i przejścia między stanami (online/offline, słaba sieć, częste rozłączenia).
• Jakość i wynik operacji lokalnych (odczyt/zapis cache, błędy zapisu lokalnego, brak miejsca).
• Przebieg synchronizacji (start/stop, liczba elementów w kolejce, sukcesy/porażki, czas trwania, liczba prób).
• Klasy błędów (walidacja, autoryzacja, błędy konektorów, limity, konflikty danych).
• Doświadczenie użytkownika (czy użytkownik widział komunikat, czy akcja została powtórzona, czy dane są „w toku”).

Telemetria vs logi offline: różnice i zastosowania

Minimalny „kontrakt” zdarzeń diagnostycznych

Żeby logi były użyteczne, każde zdarzenie powinno mieć stały zestaw pól. Nie chodzi o rozbudowany system APM, tylko o spójny format, który da się filtrować i łączyć.

• timestamp (czas zdarzenia na urządzeniu)
• correlationId (identyfikator jednej próby synchronizacji lub jednej akcji użytkownika)
• eventName (np. SyncStart, SyncItemFailed, CacheLoadError)
• severity (info/warn/error)
• entityType i entityId (czego dotyczy problem, jeśli ma sens)
• operation (create/update/delete, push/pull)
• result (success/fail/skip/retry)
• errorCode / httpStatus / connectorError (jeśli występuje)
• payloadSize lub itemCount (orientacyjnie, do analizy kosztów i wydajności)

Uwaga: unikaj zapisywania danych wrażliwych w logach (treści formularzy, identyfikatorów osobowych). Jeśli musisz, loguj skróty/metryki i identyfikatory techniczne.

Buforowanie telemetrii: „store-and-forward”

W offline kluczowy jest wzorzec: zapisz lokalnie teraz, a wyślij później. Telemetria i logi mogą korzystać z tego samego mechanizmu buforowania, ale z innymi priorytetami:

• Priorytet wysyłki: najpierw zdarzenia o błędach i nieudanych synchronizacjach, potem statystyki.
• Ograniczenie rozmiaru: rotacja logów (limit rekordów/rozmiaru), aby nie zapełnić pamięci.
• Ochrona przed „burzą logów”: throttling/dedup (np. nie loguj tego samego błędu 1000 razy w pętli).
• Odporność: jeśli wysyłka logów się nie uda, nie blokuj pracy użytkownika ani samej synchronizacji danych.

Diagnostyka synchronizacji: perspektywa użytkownika i perspektywa wsparcia

Obserwowalność nie jest tylko dla zespołu IT. W terenie liczy się szybka odpowiedź: „czy to się wysłało?” i „co mam zrobić?”. Minimalny zestaw elementów diagnostycznych w UI (bez wchodzenia w szczegóły implementacyjne) to:

• Widoczny status: offline/online, ostatnia udana synchronizacja, liczba zmian oczekujących.
• Historia prób: ostatnie N prób z informacją o wyniku (sukces/częściowy/nieudany).
• Lista elementów problematycznych: które rekordy nie przeszły i z jakiej kategorii powodu (np. uprawnienia/walidacja/konflikt).
• Akcje naprawcze: ponów, odśwież, wyślij później; w skrajnych przypadkach eksport logów.

Dla wsparcia technicznego przydaje się dodatkowo: identyfikator urządzenia/użytkownika (techniczny), wersja aplikacji oraz correlationId pozwalający powiązać logi lokalne z logami po stronie usług.

Przykładowy zapis zdarzenia (pomocniczo)

{
  "timestamp": "2026-03-23T10:15:21.123Z",
  "correlationId": "b7c2f1d0-2b1e-4c3d-9f0a-2c3a9c1d7a11",
  "eventName": "SyncItemFailed",
  "severity": "error",
  "entityType": "Inspection",
  "entityId": "INS-10492",
  "operation": "update/push",
  "result": "retry",
  "httpStatus": 409,
  "errorCode": "Conflict",
  "itemCount": 1
}

Najczęstsze pułapki obserwowalności w offline

• Brak korelacji: logi bez correlationId nie pozwalają odtworzyć przebiegu zdarzeń.
• Za dużo szczegółów: logowanie payloadu zamiast metryk prowadzi do problemów z prywatnością i rozmiarem.
• Logowanie tylko online: najcenniejsze informacje dzieją się bez sieci — muszą przetrwać offline.
• Brak rozróżnienia klas błędów: „coś nie działa” nie mówi, czy to konflikt, walidacja czy problem z uprawnieniami.
• Logi blokują działanie: zapisy i wysyłka telemetrii nie mogą spowalniać krytycznych akcji użytkownika.

Dobrze zaprojektowana obserwowalność w PowerApps offline daje dwie korzyści: użytkownik rozumie stan swoich danych, a zespół utrzymania ma materiał do szybkiej diagnozy przyczyn nieudanych synchronizacji i błędów działających „tylko w terenie”.

7. Przykłady: pseudokod/formuły Power Fx oraz diagram przepływu synchronizacji

Poniższe przykłady pokazują jak mogą wyglądać typowe fragmenty logiki offline w PowerApps: od pracy na danych w pamięci, przez zapis lokalny, aż po wysłanie zmian po odzyskaniu łączności. To nie są kompletne implementacje, tylko szkielety, które podkreślają różnice zastosowań: kolekcje do pracy w UI, magazyn lokalny do przetrwania zamknięcia aplikacji oraz kolejka zmian do późniejszej synchronizacji.

7.1. Minimalny „szkielet” uruchomienia aplikacji (start offline-first)

W wariancie offline-first logika startowa zwykle:

• ładuje dane robocze z pamięci lokalnej,
• ustawia stan połączenia,
• przygotowuje puste struktury (np. kolejkę zmian), jeśli nic nie było zapisane.

// OnStart (pseudokod Power Fx, bez szczegółów źródeł danych)
Set(varIsOnline, Connection.Connected);
LoadData(colCache, "cache_main", true);
LoadData(colOutbox, "outbox", true);
If(IsBlank(colCache), ClearCollect(colCache, {}));
If(IsBlank(colOutbox), ClearCollect(colOutbox, {}));

7.2. Edycja rekordu offline: kolekcja robocza + oznaczenie jako „zmienione”

Najczęstszy wzorzec w terenie to edycja na kopii w kolekcji roboczej, a nie bezpośrednio na źródle. Umożliwia to działanie bez sieci, walidację w UI i łatwe wykrywanie zmian.

// Zapis z formularza do kolekcji roboczej
Patch(
  colCache,
  LookUp(colCache, Id = varCurrentId),
  {
    FieldA: txtA.Text,
    FieldB: Value(txtB.Text),
    _dirty: true,
    _editedAt: Now()
  }
);
SaveData(colCache, "cache_main");

7.3. Dodanie operacji do kolejki zmian (Outbox)

Kolejka zmian przechowuje intencję (co zrobić) niezależnie od tego, czy serwer jest dostępny. Zwykle zapisuje się typ operacji (create/update/delete), identyfikator lokalny, znacznik czasu i minimalny payload.

// Dodanie wpisu do outbox przy edycji
Collect(
  colOutbox,
  {
    op: "update",
    entity: "Main",
    localId: varCurrentId,
    payload: {
      FieldA: txtA.Text,
      FieldB: Value(txtB.Text)
    },
    clientStamp: Now()
  }
);
SaveData(colOutbox, "outbox");

7.4. Synchronizacja po odzyskaniu połączenia (przetwarzanie outbox)

Synchronizacja to zwykle pętla po kolejce zmian: próba wysłania, a po sukcesie usunięcie wpisu z outbox oraz aktualizacja cache danymi zwróconymi z serwera. Różnica względem „zwykłego zapisu online” polega na tym, że synchronizacja działa asynchronicznie i wieloetapowo.

// Przycisk „Synchronizuj” lub logika przy powrocie online
If(
  Connection.Connected,
  ForAll(
    colOutbox As q,
    /* Wywołanie konektora / Power Automate / Patch do źródła (pseudokod) */
    With(
      { result: SyncOne(q) },
      If(
        result.ok,
        /* Zaktualizuj cache odpowiedzią serwera i usuń z kolejki */
        Patch(colCache, LookUp(colCache, Id = q.localId), result.serverRow);
        RemoveIf(colOutbox, localId = q.localId && op = q.op && clientStamp = q.clientStamp)
      )
    )
  );
  SaveData(colCache, "cache_main");
  SaveData(colOutbox, "outbox")
);

7.5. Sygnał konfliktu i prosta decyzja w UI (bez rozbudowanych reguł)

Gdy serwer odrzuci zapis (np. z powodu nowszej wersji danych), aplikacja zwykle:

• oznacza rekord jako konfliktowy,
• zatrzymuje automatyczne usuwanie wpisu z kolejki,
• pokazuje użytkownikowi wybór: ponów, nadpisz, scal, odrzuć lokalne zmiany.

// Oznaczenie konfliktu na podstawie odpowiedzi
If(
  result.conflict,
  Patch(
    colCache,
    LookUp(colCache, Id = q.localId),
    { _conflict: true, _serverVersion: result.serverVersion }
  )
);

7.6. Diagram przepływu synchronizacji (logika wysokopoziomowa)

Poniższy diagram pokazuje typowy przebieg: praca na cache, rejestrowanie zmian w outbox, a następnie próba wysłania po odzyskaniu sieci. Zwróć uwagę na rozgałęzienie dla błędów i konfliktów.

[Start / OnStart]
   |
   v
[LoadData cache + outbox]
   |
   v
[Użytkownik pracuje na cache]
   |
   v
[Zapis lokalny + dopisanie do outbox]
   |
   v
{Czy jest połączenie?}
   | Nie ------------------------------.
   v                                  |
[Tryb offline: kontynuuj pracę]        |
   |                                  |
   '-------------> (powrót online) <---'
                     |
                     v
             [Przetwarzaj outbox]
                     |
                     v
           {Wysłanie operacji OK?}
            | Tak                | Nie
            v                    v
   [Update cache z serwera]   {Konflikt?}
            |                 | Tak     | Nie
            v                 v         v
 [Usuń wpis z outbox]   [Oznacz konflikt] [Zostaw w outbox + retry]
            |
            v
      [SaveData cache/outbox]
            |
            v
          [Koniec]

8. Testowanie w terenie: checklista scenariuszy offline/online, awarie i regresje

Tryb offline w PowerApps rzadko psuje się „w laboratorium” — najczęściej ujawnia problemy dopiero w terenie: przy słabym zasięgu, na starszych urządzeniach, po wznowieniu aplikacji z tła albo gdy użytkownik wykonuje działania szybciej niż synchronizacja. Dlatego testy powinny obejmować nie tylko funkcje aplikacji, ale też zachowanie sieci, urządzenia, sesji użytkownika i źródeł danych. Celem jest potwierdzenie, że aplikacja pozostaje użyteczna bez łączności, a po jej odzyskaniu wraca do spójnego stanu bez utraty pracy użytkownika.

Poniższa checklista skupia się na scenariuszach, które najczęściej powodują błędy: rozjazdy danych, duplikaty, „znikające” zmiany, niejednoznaczne konflikty, a także regresje po zmianie formularzy, walidacji i uprawnień. To testy, które warto wykonywać cyklicznie, bo wiele usterek pojawia się dopiero po drobnych modyfikacjach UX lub logiki zapisu.

W Cognity łączymy teorię z praktyką – dlatego ten temat rozwijamy także w formie ćwiczeń na szkoleniach.

Zakres testów: co musi być sprawdzone w trybie offline

• Użyteczność bez sieci: czy kluczowe ekrany i procesy da się zrealizować bez połączenia (w jakim zakresie i z jakimi ograniczeniami).
• Trwałość pracy: czy dane wprowadzone offline nie znikają po zamknięciu aplikacji, przełączeniu aplikacji, restarcie telefonu, aktualizacji aplikacji, rozładowaniu baterii.
• Spójność stanu: czy użytkownik widzi, które elementy są lokalne, oczekują na wysyłkę, zostały wysłane lub wymagają reakcji (np. konflikt).
• Bezpieczeństwo i uprawnienia: czy brak sieci nie pozwala obejść ograniczeń ról, a po ponownym zalogowaniu/odświeżeniu tokenu aplikacja poprawnie reaguje.
• Przewidywalna degradacja: jeżeli jakaś funkcja wymaga sieci, aplikacja powinna komunikować to jasno i proponować alternatywę (np. zapis lokalny, kolejka).

Checklista scenariuszy przełączania offline/online

• Start online → przejście offline: rozpocznij pracę przy dobrym połączeniu, następnie wyłącz sieć i kontynuuj. Sprawdź, czy aplikacja nie „zawiesza się” na akcjach, które powinny działać lokalnie.
• Start offline: uruchom aplikację bez połączenia od samego początku. Zweryfikuj ładowanie danych lokalnych, komunikaty o ograniczeniach i dostępność krytycznych ekranów.
• Offline → odzyskanie sieci: przywróć łączność w trakcie pracy i sprawdź, czy synchronizacja uruchamia się w odpowiednim momencie, a użytkownik nie traci kontekstu.
• Flapping (częste zaniki): symuluj niestabilną sieć (naprzemiennie online/offline co kilkanaście sekund). Testuj, czy nie powstają duplikaty operacji i czy nie blokuje się UI.
• Tryb samolotowy / przełączanie Wi‑Fi ↔ LTE: sprawdź zachowanie przy zmianie interfejsu sieciowego, szczególnie gdy aplikacja jest w tle.
• Wznowienie z tła: przełącz aplikację do tła na kilka minut, wróć i zweryfikuj, czy stan offline/online jest poprawnie rozpoznany, a niedokończone operacje nie są powielane.

Scenariusze awarii, które najczęściej ujawniają błędy

• Zamknięcie aplikacji w trakcie zapisu lokalnego: wymuś zamknięcie (kill) w momencie finalizacji edycji. Po ponownym uruchomieniu dane powinny być w przewidywalnym stanie (albo zapisane, albo możliwe do odtworzenia bez „półrekordów”).
• Crash/wyczerpanie pamięci: na urządzeniach o mniejszej pamięci otwórz cięższe ekrany, wykonaj serię operacji, przełączaj widoki. Sprawdź, czy po ponownym wejściu nie ma utraconych zmian.
• Brak miejsca na urządzeniu: zasymuluj niski storage. Zweryfikuj, czy aplikacja rozpoznaje problem i potrafi bezpiecznie zatrzymać zapis lokalny, zamiast doprowadzić do korupcji danych.
• Odświeżenie sesji / wygaśnięcie tokenu: po dłuższym czasie bez sieci lub przy ponownym zalogowaniu sprawdź, czy aplikacja nie „utknie” w stanie, w którym nic nie wysyła i nic nie komunikuje.
• Zmienione uprawnienia w trakcie: użytkownik traci dostęp do części danych podczas pracy offline. Po powrocie online aplikacja powinna obsłużyć odmowę dostępu w sposób kontrolowany.
• Odrzucenie zapisu przez źródło danych: walidacje po stronie backendu (np. wymagane pole, zakresy, unikalność) mogą odrzucić część zmian. Sprawdź, czy użytkownik dostaje jasną informację i czy może poprawić dane bez ręcznego „czyszczenia” lokalnego stanu.

Testy konfliktów i spójności danych (regresje „ciche”)

• Równoległa edycja tego samego rekordu: jeden użytkownik edytuje offline, drugi online. Po synchronizacji sprawdź, czy rezultat jest deterministyczny i czy aplikacja sygnalizuje rozbieżność w sposób zrozumiały.
• Aktualizacja danych referencyjnych (słowniki, listy wyboru): zmień wartości w źródle danych w trakcie pracy offline. Po powrocie online zweryfikuj, czy formularze nie zapisują już niepoprawnych wartości.
• Usunięcie rekordu na serwerze: użytkownik offline edytuje element, który w międzyczasie został usunięty. Sprawdź, czy aplikacja potrafi zakończyć ten przypadek bez zapętlenia prób.
• Duplikaty przez ponowne wysłanie: celowo wywołaj sytuację, gdzie ta sama operacja może zostać wysłana dwa razy (np. powrót sieci w połowie). Zweryfikuj, czy backend i aplikacja zapobiegają podwójnym zapisom.
• Porządek operacji: wykonaj serię zależnych zmian (np. utworzenie elementu i powiązanie innych rekordów). Sprawdź, czy po synchronizacji relacje są poprawne i kompletne.

Scenariusze wydajnościowe w warunkach polowych

• Duża liczba zmian offline: wprowadź kilkadziesiąt/kilkuset modyfikacji bez sieci. Po odzyskaniu połączenia sprawdź czas synchronizacji, responsywność UI i zużycie baterii.
• Wolne łącze: testuj na ograniczonej przepustowości. Aplikacja powinna zachowywać się stabilnie, a użytkownik powinien rozumieć, że „wysyłanie trwa”.
• „Zimny start” na słabszym urządzeniu: uruchom aplikację po restarcie urządzenia, z pełną historią lokalnych danych. Sprawdź czas wejścia do ekranu startowego i dostępność funkcji.
• Interakcje użytkownika podczas synchronizacji: użytkownik nie czeka i dalej edytuje dane. Zweryfikuj, czy nie dochodzi do blokad, utraty zmian albo niespójnych widoków.

Regresje: co powtarzać przy każdej zmianie aplikacji

• Zmiany formularzy i walidacji: dodanie pola, zmiana typu, nowe wymagania — sprawdź, czy stare dane lokalne nadal dają się odczytać i wysłać po aktualizacji.
• Zmiany w nawigacji i stanach ekranów: regresje często pojawiają się przez resetowanie zmiennych/kolekcji podczas przechodzenia między ekranami w trybie offline.
• Zmiany źródeł danych i konektorów: aktualizacja schematu, widoków, uprawnień, limitów — weryfikuj, czy komunikaty błędów są nadal zrozumiałe i czy aplikacja nie wpada w pętle ponowień.
• Zmiany w logice „statusów” rekordu: jeśli pojawiają się nowe stany (np. „do wysłania”, „odrzucone”), upewnij się, że filtry i liczniki w UI nadal pokazują prawdę.
• Aktualizacja Power Apps/urządzeń: przetestuj po aktualizacjach systemu i aplikacji Power Apps (kontener), bo potrafią zmienić zachowanie przechowywania lokalnego i zarządzania pamięcią.

Kryteria akceptacji testów offline w terenie

• Brak utraty pracy użytkownika: w typowych awariach (zanik sieci, przejście do tła, restart) aplikacja nie gubi wprowadzonych danych lub zapewnia przewidywalne odtworzenie.
• Kontrolowane błędy: gdy coś się nie uda, użytkownik dostaje jasny komunikat i możliwość poprawy lub ponowienia, bez ręcznych „trików”.
• Spójny stan po synchronizacji: po powrocie online dane na urządzeniu i w źródle są zgodne, a ewentualne konflikty są jawne i rozstrzygalne.
• Odporność na niestabilną sieć: brak zapętleń, duplikatów i „zablokowanych” operacji po wielu przełączeniach online/offline.
• Akceptowalna wydajność: aplikacja pozostaje responsywna, a synchronizacja nie degraduje doświadczenia bardziej niż to konieczne.

Copilot w Excelu 2026: 9 zadań, które dalej robi źle (i jak to obejść formułami) 27 marca 2026

SPSS czy RStudio do analiz ankiet NPS/CSAT? Porównanie workflow i raportowania 25 marca 2026