PowerApps: walidacje i reguły biznesowe bez spaghetti — wzorce formularzy i komunikatów błędów

1. Dlaczego walidacje w PowerApps zamieniają się w „spaghetti” i jak temu zapobiec

Walidacje w PowerApps bardzo łatwo zaczynają „puchnąć”, bo aplikacje rosną iteracyjnie: najpierw jedno pole, potem zależność między polami, później wyjątki, role, stany procesu i wymagania audytowe. Bez świadomego podejścia logika biznesowa rozlewa się po kontrolkach, ekranach i zdarzeniach, tworząc układ trudny do utrzymania, testowania i wyjaśnienia innym.

Źródłem problemu nie jest sama platforma, tylko typowy sposób pracy: dopisywanie kolejnych warunków tam, gdzie akurat „działa” (np. przycisk zapisu, OnChange pola, widoczność etykiety), zamiast traktowania walidacji jako osobnej warstwy logiki.

Skąd bierze się „spaghetti” w walidacjach

• Rozproszenie reguł po UI — to samo wymaganie bywa zapisane w kilku miejscach (przycisk, formularz, kontrolka), a po zmianie biznesowej część miejsc zostaje niepoprawiona.
• Mieszanie typów walidacji — proste sprawdzenia (np. format, puste pole) są splatane z regułami procesowymi (np. „w tym statusie nie można edytować”), przez co formuły stają się długie i wieloznaczne.
• Brak jednego źródła prawdy — komunikat błędu, warunek blokujący zapis i warunek podświetlający pole żyją osobno, więc użytkownik widzi co innego niż to, co faktycznie blokuje zapis.
• Ucieczka w zagnieżdżone warunki — kolejne wyjątki dopisywane do istniejących formuł prowadzą do długich, trudnych do czytania konstrukcji, które ciężko bezpiecznie modyfikować.
• Walidacje zależne od kontekstu — reguły typu „w zależności od wyboru A, pole B jest wymagane” szybko się mnożą i zaczynają zahaczać o wiele ekranów.
• Powielanie komunikatów — różne etykiety i kontrolki pokazują różne teksty, a język komunikatów jest niespójny (ton, szczegółowość, kolejność informacji).
• Efekt uboczny zmian — poprawka w jednym miejscu potrafi „zepsuć” inne, bo nie ma jasnej granicy między logiką a prezentacją.

Jak temu zapobiec (na poziomie zasad, bez wchodzenia w implementację)

• Traktuj walidacje jako produkt uboczny reguł biznesowych — najpierw nazywaj i porządkuj reguły, a dopiero potem decyduj, gdzie i jak je pokazać w UI.
• Wydziel odpowiedzialności — UI odpowiada za zbieranie danych i prezentację stanu, a logika za ocenę poprawności i zwrócenie wyników w ustrukturyzowanej formie.
• Ustal jeden mechanizm błędów — jeden spójny sposób: skąd biorą się błędy, jak są przechowywane oraz jak są mapowane na konkretne pola i sekcje.
• Rozdziel „czy można zapisać” od „co pokazać” — blokada akcji i prezentacja komunikatów powinny wynikać z tego samego wyniku walidacji, ale nie być duplikowane osobnymi warunkami.
• Projektuj komunikaty jako element UX — spójne zasady: krótko co jest nie tak, gdzie, i co zrobić; bez technicznych sformułowań i bez sprzecznych sygnałów.
• Buduj rozwiązanie skalowalne — załóż, że reguł będzie więcej, a formularz się zmieni; struktura powinna ułatwiać dodanie kolejnej reguły bez „doklejania” warunków w wielu miejscach.

W praktyce chodzi o przejście z podejścia „dopisz warunek przy kontrolce” do podejścia „oceń dane według reguł i zwróć wynik walidacji”, a następnie jednolicie użyj tego wyniku do: oznaczenia pól, zablokowania akcji i wyświetlenia komunikatów. Taka separacja ogranicza duplikację, zmniejsza złożoność formuł i pozwala rozwijać aplikację bez narastającego chaosu.

2. Architektura walidacji: centralny moduł/reguły biznesowe jako warstwa logiki

Najczęstszy powód, dla którego walidacje w PowerApps szybko stają się nieczytelne, to ich „rozlanie” po całej aplikacji: część reguł siedzi w kontrolkach (np. na zdarzeniach), część w formularzu, część w przycisku zapisu, a część w warunkach widoczności komunikatów. W efekcie ta sama zasada biznesowa bywa powielona w kilku miejscach, a zmiana wymaga polowania na wszystkie wystąpienia. Rozwiązaniem jest potraktowanie walidacji jako osobnej warstwy logiki, a nie efektu ubocznego UI.

Z doświadczenia szkoleniowego Cognity wiemy, że ten temat budzi duże zainteresowanie – również wśród osób zaawansowanych.

W praktyce chodzi o to, by ustanowić centralny moduł reguł biznesowych, który odpowiada na jedno pytanie: czy aktualny stan danych jest poprawny i dlaczego nie. Interfejs użytkownika (formularze, kontrolki, ekrany) powinien jedynie:

• zbierać dane wejściowe do spójnego modelu,
• wywołać walidację,
• zareagować na wynik (pokazać błędy, zablokować zapis/przejście dalej).

Kluczowa różnica względem podejścia „walidacja w kontrolkach” polega na odwróceniu zależności: to nie pole powinno „wiedzieć”, jaka jest logika biznesowa, tylko logika biznesowa powinna „wiedzieć”, jakie warunki musi spełnić model danych — niezależnie od tego, czy dane pochodzą z formularza, importu, czy innego ekranu.

Centralizacja reguł daje kilka natychmiastowych korzyści:

• Jedno źródło prawdy — ta sama reguła działa identycznie w całej aplikacji.
• Spójność komunikatów — łatwiej utrzymać jednolite treści błędów i ich poziomy (np. błąd vs ostrzeżenie).
• Mniej zależności UI — przebudowa formularza rzadziej „psuje” walidacje, bo są z nich odseparowane.
• Lepsza utrzymywalność — dopisanie nowej reguły nie wymaga dotykania wielu kontrolek.

Żeby taka warstwa miała sens, warto od początku rozdzielić trzy typy sprawdzania poprawności, bo mają inny cel i inne miejsce w architekturze:

• Walidacje pola — dotyczą formatu lub zakresu pojedynczej wartości (np. wymagane, długość, zakres liczbowy). Są proste i zwykle mogą być wywoływane często, nawet przy każdej zmianie.
• Walidacje między polami — reguły zależności w obrębie jednego rekordu (np. data końcowa po dacie początkowej, wymagane pole B gdy pole A ma konkretną wartość). To typowe reguły biznesowe, które najlepiej trzymać centralnie.
• Walidacje systemowe — zależne od źródeł danych lub kontekstu (np. unikalność w bazie, uprawnienia, konflikt z istniejącym rekordem). Takie reguły często trzeba projektować z myślą o wydajności i o tym, kiedy je uruchamiać (np. przy zapisie, a nie przy każdym znaku).

„Moduł walidacji” w PowerApps nie musi oznaczać jednego technicznego artefaktu, ale konsekwentny wzorzec: jedno miejsce, w którym reguły są definiowane, uruchamiane i zwracają wynik w przewidywalnej postaci. UI nie powinno tworzyć własnych, równoległych interpretacji tych reguł. Dzięki temu w aplikacji powstaje czytelny podział na:

• warstwę prezentacji (formularze i kontrolki),
• warstwę logiki (reguły i decyzje walidacyjne),
• warstwę danych (operacje zapisu/odczytu i ich błędy techniczne).

Na koniec warto ustalić prostą zasadę projektową: reguła biznesowa powinna być opisana raz i użyta wielokrotnie. Jeśli widzisz, że ten sam warunek pojawia się w widoczności etykiety błędu, w blokadzie przycisku i w logice zapisu — to sygnał, że warstwa logiki nie jest jeszcze wystarczająco scentralizowana.

3. Wzorzec „kolekcja błędów”: struktura danych, dodawanie/usuwanie i mapowanie na pola

Najprostsza droga do „spaghetti” w walidacjach to dopisywanie kolejnych warunków bezpośrednio w właściwościach kontrolek (np. BorderColor, Visible, DisplayMode) i w wielu miejscach naraz. Wzorzec „kolekcja błędów” przenosi wynik walidacji do jednej, spójnej struktury danych: zamiast rozproszonej logiki, masz jedną listę naruszeń reguł, którą UI tylko odczytuje.

Na czym polega wzorzec

• Walidacja tworzy/aktualizuje rekordy błędów w kolekcji (np. colErrors).
• UI mapuje błędy na pola/sekcje, np. „czy pole X ma błąd?” oraz „jaki komunikat pokazać?”.
• Logika zapisu sprawdza, czy kolekcja jest pusta (czy można wysłać formularz), zamiast powielać warunki w wielu miejscach.

Struktura danych: minimalny, praktyczny schemat rekordu błędu

Dobra kolekcja błędów jest prosta, ale wystarczająco opisowa, by dało się ją filtrować i mapować na UI. Poniżej przykładowy minimalny zestaw pól:

W praktyce często dodaje się też pola pomocnicze, ale warto zacząć od minimum: Key, Field, Message. Reszta ułatwia filtrowanie i różne sposoby prezentacji.

Dodawanie błędów: jedna reguła = jeden rekord (idempotencja)

Najczęstszy problem w walidacjach to duplikowanie komunikatów. Dlatego przyjmij zasadę: dla każdej reguły utrzymuj maksymalnie jeden rekord w kolekcji (po Key). To pozwala bezpiecznie „odpalać walidację” wielokrotnie (np. przy zmianie wartości).

Przykładowy wzorzec dodania błędu tylko wtedy, gdy go nie ma:

// Dodaj błąd, jeśli warunek niespełniony i nie ma go jeszcze w kolekcji
If(
    IsBlank(txtTitle.Text),
    If(
        IsBlank(LookUp(colErrors, Key = "REQ_Title")),
        Collect(colErrors, {
            Key: "REQ_Title",
            Field: "Title",
            Message: "Uzupełnij tytuł.",
            Severity: "Error",
            Scope: "Field"
        })
    )
);

W tym podejściu Key jest „kotwicą” reguły: zmieniasz treść komunikatu bez ryzyka, że UI przestanie działać, bo mapowanie odbywa się po identyfikatorze, a nie po tekście.

Usuwanie/aktualizacja błędów: warunek spełniony = usuń rekord

Druga połowa wzorca to sprzątanie: gdy użytkownik poprawi dane, błąd ma zniknąć. Najczytelniej usuwać po Key (czasem również po Field, jeśli dopuszczasz wiele reguł dla jednego pola).

// Usuń błąd, gdy warunek jest już spełniony
If(
    !IsBlank(txtTitle.Text),
    RemoveIf(colErrors, Key = "REQ_Title")
);

Alternatywnie możesz stosować Patch, jeśli chcesz aktualizować komunikat lub wagę bez usuwania i dodawania, ale w większości formularzy prostsze i bardziej przewidywalne jest „dodaj albo usuń”.

Mapowanie błędów na pola i kontrolki (bez logiki w UI)

Gdy błędy są w kolekcji, UI powinno tylko odpowiadać na pytania typu: „czy to pole ma błąd?” oraz „jaki tekst pokazać?”. Dzięki temu w kontrolkach nie lądują rozbudowane warunki biznesowe, tylko proste odczyty z kolekcji.

• Czy pole ma błąd? — sprawdzasz istnienie rekordu w colErrors.
• Jaki komunikat pokazać? — pobierasz Message pierwszego pasującego rekordu.
• Jak podświetlić pole? — opierasz kolor/ikonę o to samo źródło (kolekcję).

// Przykład: widoczność etykiety błędu przy polu Title
lblTitleError.Visible = !IsBlank(LookUp(colErrors, Field = "Title"));

// Przykład: treść etykiety błędu
lblTitleError.Text = Coalesce(LookUp(colErrors, Field = "Title", Message), "");

// Przykład: obramowanie pola
txtTitle.BorderColor = If(!IsBlank(LookUp(colErrors, Field = "Title")), Color.Red, Color.Gray);

Ważna różnica: UI nie „wie”, dlaczego pole jest niepoprawne — tylko wie, że jest błąd przypisany do Field. To ogranicza sprzężenie między regułami a warstwą prezentacji.

Mapowanie na sekcje i podsumowanie błędów (bez duplikowania reguł)

Ten sam zbiór rekordów może zasilać różne widoki: błędy inline przy polach oraz listę w jednym miejscu. Wystarczy inne filtrowanie/wyświetlanie, bez przepisywania warunków walidacyjnych.

• Podsumowanie: galeria oparta o colErrors (np. posortowana po Field lub Severity).
• Sekcje: jeśli używasz Scope lub pola typu Section, możesz pokazywać licznik błędów per sekcja.

Kiedy kolekcja błędów jest szczególnie przydatna

Kluczowe jest to, że kolekcja błędów oddziela wytwarzanie informacji o naruszeniach od prezentacji tej informacji. Dzięki temu formularz jest łatwiejszy w utrzymaniu: reguły możesz zmieniać bez „przeklikiwania” dziesiątek kontrolek i bez ryzyka, że w jednym miejscu zapomnisz o aktualizacji.

4. Komponenty komunikatów: spójne wyświetlanie błędów (inline, podsumowanie, toast)

W PowerApps walidacje najczęściej „psują się” nie na poziomie reguł, tylko na poziomie komunikacji z użytkownikiem: ten sam błąd raz pojawia się pod polem, innym razem w etykiecie na górze, czasem w ogóle znika po zmianie ekranu. Dlatego warto potraktować komunikaty o błędach jak osobną warstwę UI i ustandaryzować je w postaci komponentów (lub przynajmniej powtarzalnych wzorców) dla trzech kanałów: inline, podsumowanie i toast. Doświadczenie Cognity pokazuje, że rozwiązanie tego problemu przynosi szybkie i zauważalne efekty w codziennej pracy.

Inline: błąd „przy polu”, gdy liczy się precyzja

Inline to komunikat przypięty do konkretnej kontrolki (np. TextInput/Dropdown) i zwykle jest najlepszym wyborem, gdy użytkownik ma natychmiast poprawić wartość w danym polu. Najważniejsze cechy dobrego inline:

• Jednoznaczne mapowanie błędu do pola (użytkownik nie zgaduje, gdzie poprawić).
• Spójny wygląd: kolor obramowania, ikona, tekst, marginesy, wysokość etykiety (żeby układ nie „skakał”).
• Warunek widoczności oparty o jednolite źródło prawdy (np. kolekcję błędów lub jeden obiekt stanu), zamiast ad-hoc formuł w każdej kontrolce.

Typowy wzorzec UI: obramowanie kontrolki zmienia kolor, a pod nią pojawia się etykieta z krótką wiadomością. Warto trzymać komunikat inline krótki i „naprawialny” (co użytkownik ma zrobić), a nie opisowy.

Podsumowanie błędów: gdy użytkownik ma poprawić kilka rzeczy

Podsumowanie (lista błędów na górze formularza lub w panelu) sprawdza się, gdy:

• formularz jest długi i użytkownik może nie zauważyć pojedynczych inline na dole,
• po kliknięciu „Zapisz” wykrywa się wiele problemów naraz,
• chcesz dać szybki przegląd: „co blokuje zapis”.

Dobre podsumowanie powinno być skanowalne (lista punktów), a jeśli to możliwe — nawigowalne, tzn. kliknięcie elementu przenosi fokus do pola lub przewija do sekcji. Nawet jeśli nie implementujesz przewijania, sama lista z nazwą pola i komunikatem znacząco redukuje frustrację.

Toast/notify: gdy komunikat jest globalny lub dotyczy akcji

Toast (np. przez Notify()) jest najlepszy do komunikatów, które nie są „przywiązane” do jednego pola:

• błędy akcji (np. nie udało się zapisać przez konflikt/łączność/uprawnienia),
• informacje o wyniku (zapisano, wysłano, odrzucono),
• przypomnienie o wymaganej czynności, gdy użytkownik próbuje przejść dalej.

Toast jest szybki, ale łatwo go „przegapić”, więc nie powinien zastępować inline dla błędów pól. Dobrą praktyką jest używać toastów dla komunikatów systemowych lub krokowych, a błędy pól trzymać inline + w podsumowaniu.

Porównanie kanałów komunikatów

Minimalna standaryzacja: co warto ujednolicić

• Słownictwo: krótkie, konsekwentne komunikaty (np. „Pole wymagane”, „Nieprawidłowy format”, „Wartość poza zakresem”).
• Poziomy: błąd (blokuje), ostrzeżenie (nie blokuje), informacja (feedback) — nawet jeśli początkowo używasz tylko błędów.
• Wygląd: jeden zestaw kolorów i spacingu dla komunikatów (inline/podsumowanie), żeby użytkownik natychmiast rozpoznawał błąd.
• Jedno źródło prawdy: UI tylko „renderuje” komunikaty, a nie wymyśla logiki walidacji lokalnie w kontrolkach.

Uzupełniający przykład: spójne wyświetlanie błędu inline i w podsumowaniu

Poniżej przykład pokazuje wyłącznie ideę: jedna wartość błędu jest używana do stylu kontrolki i tekstu (bez rozbudowy architektury).

// Label pod polem (Inline)
// Visible
!IsBlank(varErr_Email)

// Text
varErr_Email

// Kontrolka TextInput (np. BorderColor)
If(!IsBlank(varErr_Email), Color.Red, RGBA(200,200,200,1))

// Podsumowanie (np. galeria)
// Items
Filter(
  Table(
    {Field:"Email", Msg: varErr_Email},
    {Field:"Telefon", Msg: varErr_Phone}
  ),
  !IsBlank(Msg)
)

Najważniejsze w tym podejściu nie są same formuły, tylko konsekwencja: ta sama treść błędu zasila różne kanały (inline i podsumowanie), a toast zostaje zarezerwowany dla komunikatów globalnych.

5. Walidacja krokowa (wizard): walidacje per ekran/sekcja i blokowanie przejść

Formularze typu wizard (krok po kroku) ograniczają „spaghetti” w walidacjach, bo wymuszają podział reguł na mniejsze, zrozumiałe porcje: per ekran, per sekcja lub per etap procesu. Zamiast próbować zweryfikować wszystko naraz przy zapisie, weryfikujesz tylko to, co użytkownik właśnie uzupełnia — a przejście dalej jest możliwe dopiero po spełnieniu wymagań bieżącego kroku.

Na czym polega walidacja „per krok”

• Zakres walidacji jest lokalny — krok sprawdza tylko swoje pola (i ewentualnie niezbędne zależności), zamiast odpalać całą logikę formularza.
• Blokada nawigacji — przycisk „Dalej” (lub zmiana ekranu/zakładki) jest uzależniona od braku błędów w danym kroku.
• Jasny moment walidacji — zwykle na klik „Dalej” lub przy wyjściu z kroku, a nie przy każdej zmianie pojedynczego pola.
• Stopniowe ujawnianie wymagań — użytkownik nie jest zalewany błędami z przyszłych etapów, których jeszcze nie widział.

Kiedy wizard pomaga, a kiedy przeszkadza

Typowe modele nawigacji i blokowania przejść

W PowerApps spotkasz kilka popularnych podejść. Kluczowa różnica dotyczy tego, gdzie trzymasz informację o aktualnym kroku i jak łatwo kontrolujesz przejścia:

• Wiele ekranów — każdy krok to osobny ekran; przejście sterowane przez Navigate() po pozytywnej walidacji.
• Jeden ekran + kontenery/zakładki — kroki jako sekcje pokazywane/ukrywane (np. Visible zależne od varStep); wygodne do wspólnego nagłówka i podsumowania.
• Galeria kroków (sidebar) — lista kroków z blokadą kliknięć na przyszłe pozycje (np. tylko do ostatniego „zaliczonego” kroku).

Minimalny wzorzec: status kroku + walidacja na „Dalej”

Nawet bez rozbudowanej infrastruktury warto mieć dwie rzeczy: zmienną z numerem kroku oraz flagę/stan zaliczenia kroku. Dzięki temu kontrolujesz zarówno przyciski „Dalej/Wstecz”, jak i możliwość skakania po krokach.

• Aktualny krok: np. varStep (1..N)
• Postęp: np. varMaxStepReached (najdalszy krok, do którego użytkownik ma dostęp)
• Warunek przejścia: walidacja kroku → jeśli OK, inkrementuj krok i aktualizuj postęp

// OnSelect przycisku "Dalej" (koncepcyjnie)
// 1) uruchom walidację bieżącego kroku
// 2) jeśli brak błędów, przejdź dalej
If(
    /* StepHasErrors(varStep) */ false,
    /* pokaż komunikaty */,
    Set(varStep, varStep + 1);
    Set(varMaxStepReached, Max(varMaxStepReached, varStep))
);

Jak nie zrobić nowego „spaghetti” w wizardzie

Wizard sam w sobie nie gwarantuje porządku — można równie łatwo przenieść chaos do przycisków „Dalej”. Żeby temu zapobiec:

• Nie duplikuj tych samych reguł w kilku krokach — ustal jedno miejsce odpowiedzialności za daną walidację (krok lub logika wspólna).
• Waliduj „to, co użytkownik widzi” — reguły dla pól ukrytych w kroku nie powinny blokować przejścia.
• Oddziel „blokadę przejścia” od „prezentacji błędu” — przycisk ma decydować, czy wolno iść dalej; sposób pokazania błędu powinien być spójny w całej aplikacji.
• Uważaj na zależności między krokami — jeśli krok 3 wymaga informacji z kroku 1, dopilnuj, by zmiana w kroku 1 mogła unieważnić zaliczenie kroku 3 (np. cofnięcie postępu).

Praktyczne wskazówki UX dla walidacji krokowej

• „Dalej” jako moment prawdy — użytkownik rozumie, że przejście wymaga kompletności; unikaj agresywnej walidacji przy każdym znaku, jeśli nie jest potrzebna.
• Widoczny stan kroków — oznaczenia typu: „do zrobienia / w trakcie / gotowe” zmniejszają frustrację.
• Skupienie na pierwszym błędzie — po kliknięciu „Dalej” przenieś fokus/scroll do pola z problemem, zamiast liczyć, że użytkownik sam je znajdzie.
• Wstecz bez kary — cofanie nie powinno gubić danych; walidacje nie powinny „karać” za eksplorację kroków.

6. Czytelne formuły: konwencje nazewnictwa, rozbijanie złożoności, funkcje pomocnicze

Czytelność formuł w PowerApps to najszybsza droga do uniknięcia „spaghetti”: mniej powtórzeń, mniej zagnieżdżeń, łatwiejsze debugowanie i mniejsze ryzyko, że ta sama reguła będzie zaimplementowana inaczej w trzech miejscach. W praktyce chodzi o trzy rzeczy: konsekwentne nazewnictwo, warstwowanie formuł oraz powtarzalne helpery.

Konwencje nazewnictwa: sygnał zamiast zgadywania

PowerApps nie wymusza standardu, więc warto wprowadzić go samodzielnie. Dobre nazwy odpowiadają na pytania: co to jest?, do czego służy?, jaki ma zasięg? (screen / app / komponent).

• Kontrolki: prefiks wg typu + rola w formularzu (np. txtEmail, cmbCountry, tglIsActive, frmEdit, galItems).
• Zmienne kontekstowe (UpdateContext): prefix ctx dla zasięgu ekranu (np. ctxIsBusy, ctxMode).
• Zmienne globalne (Set): prefix gbl dla zasięgu aplikacji (np. gblUser, gblLocale).
• Kolekcje: prefix col (np. colErrors, colLookups).
• Źródła danych / tabele: zrozumiałe, rzeczownikowe nazwy (np. Users, Requests) oraz unikanie skrótów, które nic nie mówią.

Dodatkowo warto przyjąć stałe nazwy pól i kluczy w całej aplikacji (np. Field, Message, Severity) — dzięki temu formuły nie „rozjeżdżają się” przy mapowaniu logiki na UI.

Skróty myślowe, które psują utrzymanie

Najczęstsze źródła nieczytelności to: nadmiar If w jednym miejscu, powtarzanie tych samych warunków w kilku kontrolkach oraz „magiczne” wartości. Zamiast tego:

• unikaj długich łańcuchów If(…, If(…, If(…))) — rozbijaj na etapy;
• przypisuj wyniki warunków do nazwanych zmiennych w With() lub UpdateContext();
• zastępuj „magiczne” teksty i liczby stałymi/enumami (np. tryby formularza, kody statusów).

Rozbijanie złożoności: warstwowanie formuł

Typowa, trudna w utrzymaniu formuła miesza: pobranie wartości, normalizację, regułę biznesową i budowę komunikatu. Czytelniejszy wzorzec to warstwy:

• Warstwa danych wejściowych: pobranie i ujednolicenie wartości (np. Trim(), Lower()).
• Warstwa reguły: czyste warunki (bool) — bez efektów ubocznych.
• Warstwa komunikatu: dopiero na końcu wybór tekstu/klucza komunikatu.

W PowerApps bardzo pomaga tu funkcja With(), która pozwala nazwać kroki pośrednie i ograniczyć powtarzanie:

// Przykład: rozbicie logiki na czytelne fragmenty
With(
  {
    vEmail: Trim(txtEmail.Text),
    isEmpty: IsBlank(Trim(txtEmail.Text)),
    isValid: IsMatch(Trim(txtEmail.Text), Match.Email)
  },
  If(
    isEmpty,
    "Email jest wymagany",
    If(!isValid, "Niepoprawny format email", "")
  )
)

Ten sam schemat działa dla wielu pól: najpierw nazwane wartości/flag, potem prosty wybór wyniku.

Preferuj przejrzyste warunki: Switch i wzorce decyzyjne

Gdy decyzja zależy od jednej wartości (np. tryb, status), Switch() jest zwykle czytelniejszy niż wielokrotne If:

• If: najlepszy dla 1–2 warunków lub logicznego „i/lub”.
• Switch: najlepszy dla wyboru jednej z wielu gałęzi na podstawie pojedynczego parametru.

Funkcje pomocnicze bez powielania: komponenty i „helpery”

W PowerApps nie zawsze buduje się klasyczne funkcje, ale da się osiągnąć podobny efekt poprzez powtarzalne klocki:

• Komponenty: enkapsulują logikę prezentacji i drobne helpery UI (np. formatowanie, wspólne zachowania kontrolek).
• Wspólne formuły oparte o With(): krótkie „mini-funkcje” w miejscu użycia, ale w spójnym schemacie.
• Wspólne stałe i konfiguracje: np. rekord konfiguracyjny przechowywany globalnie (kolory, progi, flagi) zamiast wpisywania wartości w wielu miejscach.

Najważniejsza zasada helperów: jedna odpowiedzialność. Helper ma zwracać prosty wynik (np. bool albo tekst), a nie jednocześnie zmieniać stan aplikacji i aktualizować UI.

Konwencje struktury formuł: mikrostandard, który robi różnicę

Minimalne „reguły higieny” dla walidacji

• Jedno źródło prawdy dla wartości pola: w danym miejscu czytaj wartość w jeden sposób (np. zawsze z kontrolki albo zawsze z rekordu roboczego), nie mieszaj.
• Jedna odpowiedzialność na właściwość: np. DisplayMode nie powinien jednocześnie „ukrywać” logiki walidacyjnej i uprawnień.
• Trzymaj walidacje „czyste”: warunek walidacji powinien być deterministyczny; efekty uboczne (np. zapisy, nawigacja) trzymaj osobno.
• Unikaj kopiuj-wklej: jeśli ten sam fragment pojawia się 3 razy, to sygnał, że potrzebujesz helpera lub standaryzacji.

Wdrożenie tych zasad nie wymaga przebudowy aplikacji od zera: najczęściej wystarczy zacząć od nazw, potem stopniowo rozbijać najdłuższe formuły na etapy i przenosić powtarzalne elementy do helperów/komponentów.

7. Przykłady formuł: reguły, walidacja pól, agregacja błędów i obsługa submit

Poniższe przykłady pokazują, jak układać formuły tak, by walidacje były powtarzalne, czytelne i łatwe do podpięcia pod formularze. Skupiamy się na różnicach zastosowań: walidacja pojedynczego pola vs. całego rekordu, walidacja „na bieżąco” vs. przed zapisem oraz obsługa błędów użytkownika vs. błędów zapisu (np. źródło danych).

A. Reguły biznesowe jako osobne wywołania (jedno miejsce, wiele pól)

Najczęstszy wzorzec to uruchamianie zestawu reguł w jednym miejscu (np. na zmianę wartości, przy przejściu dalej lub przed zapisem) i w wyniku otrzymanie listy błędów. Dzięki temu nie mieszasz logiki w wielu właściwościach kontrolek.

• Walidacja per zdarzenie: wywołujesz reguły w OnChange/OnVisible, by natychmiast aktualizować błędy i stan przycisków.
• Walidacja przed akcją: wywołujesz reguły w OnSelect przycisku „Zapisz/Wyślij”, by nie dopuścić do submit przy niespełnionych warunkach.
• Różne poziomy rygoru: te same reguły mogą działać w trybie „soft” (podpowiedzi) lub „hard” (blokada) w zależności od kontekstu.

B. Walidacja pojedynczego pola (inline) bez rozlewania formuł

Walidacja inline zwykle odpowiada na pytania: czy pole jest wymagane, czy ma poprawny format, czy mieści się w zakresie. Kluczowe jest, by kontrolka nie liczyła reguł samodzielnie, tylko odczytywała wynik z jednej, spójnej struktury błędów.

• Kolor obramowania / podkreślenie: stan błędu wynika z tego, czy dla danego pola istnieje wpis w kolekcji błędów.
• Tekst błędu przy polu: label obok pola pokazuje komunikat powiązany z danym kluczem (np. nazwą pola).
• Warunkowe wymaganie: pole bywa wymagane tylko, jeśli inne pole ma określoną wartość; nadal prezentujesz to jako błąd przypięty do pola.

C. Reguły między polami (cross-field) i reguły „rekordowe”

Reguły biznesowe często nie dotyczą jednego pola, tylko relacji (np. data końcowa po dacie startowej, suma pozycji zgodna z limitem). Takie reguły warto przypinać do konkretnego pola (żeby użytkownik wiedział, co poprawić) albo do sekcji (gdy nie da się wskazać jednego miejsca).

• Cross-field: walidacja wykorzystuje kilka kontrolek/zmiennych, ale wynik mapujesz do jednego pola lub do „nagłówka” sekcji.
• Rekordowe: walidacje dotyczą całego rekordu (np. konflikt biznesowy) i często lądują w podsumowaniu błędów.
• Reguły zależne od trybu: inne warunki dla nowego rekordu, inne dla edycji (np. blokada zmian po statusie).

D. Agregacja błędów: jeden stan dla UI (blokady, badge, licznik)

Po zebraniu błędów w jednym miejscu łatwo budować zachowania interfejsu bez duplikowania warunków. Zamiast wszędzie powtarzać te same sprawdzenia, UI opiera się o liczbę błędów lub ich kategorie.

• Blokada przycisku „Dalej/Zapisz”: zależy od tego, czy istnieją błędy krytyczne (a nie od dziesiątek warunków w DisplayMode).
• Podsumowanie błędów: lista błędów jest gotowa do pokazania jako komunikaty globalne lub sekcyjne.
• Rozróżnienie typów: błędy mogą mieć poziomy (np. „error” vs. „warning”), co pozwala blokować tylko część sytuacji.

E. Submit: walidacje przed zapisem i obsługa błędów po zapisie

Obsługa zapisu powinna rozdzielać dwie klasy problemów: błędy walidacji (zależne od danych wejściowych) oraz błędy zapisu (np. odrzucenie przez źródło danych, konflikt, uprawnienia). W praktyce najpierw uruchamiasz walidacje, a dopiero potem wywołujesz SubmitForm/Patch; następnie reagujesz na sukces/porażkę.

• Przed zapisem: odświeżenie kolekcji błędów i natychmiastowe przerwanie akcji, jeśli są błędy blokujące.
• W trakcie zapisu: ustawienie stanu „loading”, by zapobiec wielokrotnym kliknięciom i utrzymać spójny UX.
• Po zapisie: w OnSuccess czyścisz błędy walidacyjne, pokazujesz komunikat sukcesu i ewentualnie resetujesz formularz.
• OnFailure: mapujesz błąd systemowy na komunikat globalny (np. toast/podsumowanie), bez mylenia go z walidacją pól.

F. Minimalne „klocki”, które warto mieć w praktyce

Aby powyższe przykłady były możliwe, zwykle wystarczają cztery elementy, które dają spójny przepływ:

• Jeden wyzwalacz walidacji (np. przycisk lub zdarzenie ekranu), który odświeża listę błędów.
• Jedna struktura błędów, z której UI odczytuje: czy pole ma błąd, jaki komunikat pokazać, czy błąd blokuje.
• Jedno miejsce decyzji, czy wolno wykonać akcję (na podstawie agregacji błędów).
• Osobna ścieżka dla błędów zapisu (OnFailure), niezależna od reguł biznesowych.

Tak ułożone formuły nie wymagają „doklejania” kolejnych IF-ów w kontrolkach. Zamiast tego formularz staje się zbiorem prostych odczytów stanu, a logika walidacji pozostaje spójna i testowalna.

8. Checklist UX dla komunikatów błędów: treść, timing, dostępność i wzorce interakcji

Dobra walidacja to nie tylko „czy działa”, ale też jak komunikuje. Ten checklist pomaga ocenić komunikaty błędów w formularzach PowerApps pod kątem treści, momentu wyświetlania, dostępności oraz przewidywalnych wzorców interakcji — tak, aby użytkownik rozumiał problem i mógł szybko go naprawić.

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

Treść komunikatu: zrozumiale i naprawialnie

• Mów, co jest nie tak bez żargonu technicznego (unikaj „invalid”, „type mismatch”, „400”).
• Wskaż, co zrobić: komunikat ma prowadzić do poprawy („Wpisz datę w formacie…”, „Uzupełnij pole …”).
• Jedna przyczyna = jedna wiadomość; nie łącz kilku problemów w jednym zdaniu.
• Konsekwencja terminów: te same nazwy pól, te same określenia wymagań („wymagane”, „opcjonalne”, „minimalnie”).
• Unikaj oceniania („Błędnie wypełnione”) — zamiast tego neutralnie („Brakuje wartości”).
• Używaj wartości progowych wprost (np. limit znaków, zakres dat), o ile pomaga to w poprawie.
• Nie ujawniaj wrażliwych informacji w komunikatach (np. szczegółów uprawnień, struktury danych).

Timing: kiedy pokazywać błąd, żeby nie frustrować

• Nie karz za pisanie: unikaj agresywnej walidacji w trakcie wpisywania, jeśli pole ma złożony format; użytkownik powinien mieć szansę dokończyć.
• Waliduj po zakończeniu edycji pola (gdy użytkownik przechodzi dalej) dla większości reguł formatów i wymaganych pól.
• Waliduj przy próbie zapisu zawsze — jako ostatnią barierę, z jasnym wskazaniem, co blokuje zapis.
• Nie pokazuj błędu „z góry” na pustym formularzu, zanim użytkownik cokolwiek zrobi (chyba że to krytyczny warunek startowy).
• Reaguj natychmiast po naprawie: jeśli użytkownik poprawił pole, błąd powinien znikać szybko i przewidywalnie.

Kontekst i lokalizacja: gdzie użytkownik ma patrzeć

• Inline przy polu dla błędów, które dotyczą jednego miejsca (najbardziej „naprawialne”).
• Podsumowanie błędów gdy formularz jest długi lub ma kilka sekcji — ułatwia skanowanie problemów.
• Komunikaty globalne (np. toast) tylko dla zdarzeń ogólnych: zapis się nie udał, brak sieci, konflikt, brak uprawnień.
• Nie dubluj bez sensu: jeśli pokazujesz błąd inline i w podsumowaniu, treść powinna być spójna, a nie „dwie różne wersje prawdy”.
• Utrzymaj stabilny układ: komunikat nie powinien „rozpychać” formularza w sposób, który przesuwa pole i gubi fokus; priorytetem jest czytelność bez dezorientacji.

Hierarchia i priorytety: co pierwsze, co ważniejsze

• Pokaż najpierw blokery (to, co uniemożliwia zapis), dopiero potem ostrzeżenia.
• Przy konflikcie reguł wybierz jedną, najbardziej pomocną wiadomość (np. „pole wymagane” ma pierwszeństwo nad „zła długość”).
• Ostrzeżenia nie powinny wyglądać jak błędy: inny ton i wizualny akcent, aby nie budować fałszywego poczucia porażki.

Dostępność (a11y): kolor to za mało

• Nie opieraj przekazu tylko na kolorze: dodaj ikonę, etykietę tekstową lub inny sygnał.
• Czytelny kontrast dla tekstu i elementów stanu; komunikat ma być równie widoczny na różnych ekranach i w trybach wysokiego kontrastu.
• Wsparcie dla czytników ekranu: komunikat powinien być dostępny jako tekst i możliwy do odczytania w logicznej kolejności.
• Fokus i nawigacja klawiaturą: użytkownik powinien móc przejść do błędnego pola bez „polowania” myszą.
• Nie używaj wyłącznie skrótów lub symboli bez opisu (np. sama gwiazdka przy polu bez wyjaśnienia).

Wzorce interakcji: jak użytkownik ma naprawiać błędy

• Łatwe przejście do problemu: z podsumowania błędów użytkownik powinien móc trafić do konkretnego pola/sekcji.
• Wyraźny stan po poprawie: po naprawie błąd znika, a pole wraca do neutralnego stanu; unikaj „pół-błędu”, gdy walidacja jest niejednoznaczna.
• Nie blokuj bez wyjaśnienia: jeśli przycisk „Zapisz/Dalej” jest nieaktywny, użytkownik musi wiedzieć dlaczego i co ma zrobić.
• Nie każ zgadywać formatu: przy polach z formatem używaj podpowiedzi (placeholder/opis), aby błąd był wyjątkiem, nie normą.
• Uważaj na nadmiar komunikatów: kilka błędów naraz potrafi przytłoczyć; rozważ prowadzenie użytkownika krok po kroku w gęstych formularzach.

Język i ton: profesjonalnie, krótko, po ludzku

• Zwięzłość: użytkownik ma poprawić dane, nie czytać komunikat — jedno zdanie często wystarcza.
• Forma rozkazująca lub wskazująca („Wybierz…”, „Uzupełnij…”) jest zwykle skuteczniejsza niż opisowa.
• Spójność w całej aplikacji: ten sam styl, wielkość liter, interpunkcja; brak „losowych” wariantów.
• Unikaj humoru i ironii: w błędach liczy się pewność i zaufanie, szczególnie w procesach biznesowych.

Sytuacje szczególne: sieć, uprawnienia, konflikty danych

• Błędy techniczne komunikuj inaczej niż walidacyjne: „Nie udało się zapisać” + prosty powód (jeśli bezpieczny) + co dalej.
• Tryb offline / słaba sieć: powiedz, czy dane są w kolejce do wysłania, czy użytkownik musi spróbować ponownie.
• Uprawnienia: komunikat ma mówić, że brak dostępu uniemożliwia akcję, bez zdradzania detali; podaj dalszy krok (kontakt z administracją/proces zgłoszenia), jeśli to możliwe.
• Konflikty współedycji: informuj, że dane się zmieniły i co może zrobić użytkownik (odśwież, porównaj, ponów).

Szybki test jakości: 5 pytań kontrolnych

• Czy użytkownik wie, które pole jest problemem?
• Czy komunikat mówi co zrobić, a nie tylko co jest źle?
• Czy błąd pojawia się w dobrym momencie (nie za wcześnie, nie za późno)?
• Czy osoba korzystająca z klawiatury/czytnika ekranu naprawi to samo bez przeszkód?
• Czy komunikaty są spójne w całej aplikacji (język, poziomy ważności, zachowanie)?

Dataviz dla ESG: jak pokazywać emisje, cele i luki bez greenwashingu na wykresach 22 kwietnia 2026

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