Strona statusu integracji: pokaż stan synchronizacji i dalsze kroki

Dlaczego klienci muszą widzieć status synchronizacji

Kiedy klient otwiera Twoją aplikację i liczby wydają się nieprawidłowe, rzadko myśli "zadanie synchronizacji się opóźniło." Myśli, że produkt jest zepsuty, że kolega coś zmienił, albo że sam popełnił błąd. Ta niepewność sprawia, że drobna usterka integracji zamienia się w zgłoszenie do wsparcia, ryzyko utraty klienta lub długą wymianę e-maili.

Widoczna dla klienta strona statusu usuwa zgadywanie. Odpowiada na jedno pytanie, które naprawdę ich interesuje: "Czy moje dane są aktualne, a jeśli nie, co mam zrobić?" Bez tej jasności klienci będą powtarzać akcje, ponownie podłączać konta lub zmieniać ustawienia, które wcale nie były problemem.

Pomaga też rozróżnić dwie całkowicie różne sytuacje:

• Awaria: usługa zewnętrzna jest niedostępna lub odrzuca żądania, więc synchronizacja teraz nie powiedzie się.
• Opóźniona synchronizacja: synchronizacja działa, ale następne uruchomienie jest w kolejce, występuje limitowanie żądań lub trwa dłużej niż zwykle.

Te dwa przypadki wymagają różnych oczekiwań. Podczas awarii najlepszym krokiem może być "poczekaj, będziemy ponawiać automatycznie." Przy opóźnieniu lepszym krokiem może być "kolejne uruchomienie zaplanowane" lub "możesz uruchomić je teraz."

"Dobrze" dla strony statusu integracji oznacza, że klient rozumie sytuację w mniej niż 10 sekund i może podjąć bezpieczną akcję bez kontaktu z supportem. Powinna:

• Budować zaufanie jasnym sygnałem zdrowia i aktualnym znacznikiem czasu
• Redukować powtarzające się pytania typu "Czy się zsynchronizowało?" i "Czy utknęło?"
• Oferować konkretny następny krok, który nie pogorszy sytuacji
• Nie obwiniać w interfejsie, a jednocześnie być uczciwą

Przykład: kierownik sprzedaży oczekuje nowych leadów z CRM przed spotkaniem. Jeśli strona pokaże "Ostatnia udana synchronizacja: 12 minut temu" i "Następne uruchomienie: za 3 minuty", może przestać odświeżać i zająć się innymi sprawami. Jeśli pokaże "Wymaga uwagi: wymagane ponowne połączenie", dokładnie wie, co naprawić.

Co powinna odpowiadać widoczna dla klienta strona statusu

Widoczna dla klienta strona statusu integracji ma zapobiegać zgadywaniu. Kiedy synchronizacja wygląda na "zablokowaną", ludzie chcą jasnych odpowiedzi bez konieczności otwierania zgłoszenia do wsparcia.

Strona powinna odpowiadać na niewielki zestaw pytań prostym językiem:

• Czy integracja działa teraz poprawnie?
• Kiedy była ostatnia udana synchronizacja?
• Co zawiodło i jak duży jest wpływ (wszystkie dane czy tylko część)?
• Co mogę teraz zrobić, by to naprawić lub zmniejszyć szkody?

Warto też być jasnym, do kogo mówisz. Administrator potrzebuje wystarczająco dużo szczegółów, by podjąć działanie (ponowne połączenie, ponowienie, zmiana uprawnień). Zwykły użytkownik zwykle potrzebuje jedynie uspokojenia i harmonogramu. Zespół wsparcia potrzebuje krótkiego podsumowania, które mogą zrzucić ekranem i odesłać dalej.

Gdzie powinna być umieszczona? Najlepiej tam, gdzie łatwo ją znaleźć w miejscu, w którym pojawia się problem. Wiele produktów umieszcza ją w obu miejscach:

• W samym module zależnym od integracji (mały panel "Stan synchronizacji")
• W Ustawieniach lub Integracjach (pełny widok statusu z historią)

Ustal, co pokażesz, a czego nie. Klienci powinni widzieć zdrowie, czasy i czytelną przyczynę, ale nie surowe stack trace'y, nazwy wewnętrznych usług ani prywatne dane z payloadów. Jeśli potrzebujesz głębszej diagnostyki, trzymaj ją w logach wewnętrznych i dodaj krótki identyfikator referencyjny na stronie klienta.

Jeśli budujesz to w AppMaster, zacznij od prostej wersji: rekord statusu (health, last run, last success, message, next action) i stronę, która to odczytuje. Później możesz rozbudować, ale powyższe odpowiedzi to minimum, które sprawia, że strona jest użyteczna.

Kluczowe pola do pokazania na pierwszy rzut oka

Dobra strona statusu integracji jest czytelna w pięć sekund. Celem nie jest wyjaśnienie każdego technicznego detalu, ale pomoc klientowi odpowiedzieć: "Czy to działa teraz i co się zmieniło?"

Zacznij od jednego podsumowania statusu używając prostych etykiet: Healthy, Degraded, Down lub Paused. Trzymaj reguły spójne. Na przykład "Degraded" może oznaczać, że niektóre rekordy się nie synchronizują, ale większość tak, podczas gdy "Paused" oznacza, że synchronizacja jest celowo zatrzymana (przez klienta lub system).

Tuż pod podsumowaniem pokaż trzy czasy, na których klientom zależy. Używaj czytelnego znacznika czasu i relatywnego określenia ("12 minut temu"), i zawsze pokazuj strefę czasową.

Pola, które zwykle mają stałe miejsce na górze strony statusu integracji:

• Podsumowanie statusu (Healthy, Degraded, Down, Paused) z jednolinijkową przyczyną
• Ostatnia udana synchronizacja (czas i względnie)
• Ostatnie uruchomienie (nawet jeśli zakończyło się niepowodzeniem)
• Następne zaplanowane uruchomienie (lub "ręczne", jeśli brak harmonogramu)
• Proste liczniki dla ostatniego uruchomienia: przetworzono, nieudane, pominięte

Liczby powinny pomagać, a nie hałasować. Lepsze są krótkie, stabilne liczby zamiast szczegółowych rozbić. "Przetworzono 1 240, Nieudanych 18, Pominęto 6" wystarczy dla większości klientów.

Konkretne przykłady: jeśli klient widzi "Degraded" oraz "Ostatnia udana synchronizacja: 2 godziny temu" i "Ostatnie uruchomienie: 3 minuty temu (niepowodzenie)", od razu wie, że system próbuje, ale mu się nie udaje. Dodaj "Następne uruchomienie: za 15 minut" i wie, czy czekać, czy działać.

Szczegóły błędów, które pomagają bez nadmiaru informacji

Gdy coś się psuje, klienci chcą jasnej odpowiedzi, a nie zagadki kodu. Na stronie statusu integracji zacznij od tytułu błędu w języku prostym i wskazującym następny krok. "Ważność autoryzacji wygasła" lub "Usunięto uprawnienia" jest lepsze niż "401", bo wskazuje naprawę.

Po tytule dodaj krótką przyczynę i zakres wpływu. Zakres może być tak prosty, jak: która integracja (np. "Salesforce"), jaka część dotknięta ("tylko synchronizacja kontaktów") i czy dane są opóźnione czy brakujące. To utrzymuje komunikat użytecznym bez zamieniania strony w konsolę debugowania.

Dobrym wzorcem jest mały widok "Szczegóły", który można bezpiecznie udostępnić wsparciu. Powinien zawierać tylko to, co pomaga zidentyfikować incydent, nie odtwarzać żądania.

Co zawrzeć w bezpiecznym widoku Szczegóły

Trzymaj to krótkie i spójne dla wszystkich integracji:

• Kod błędu (np. 401, 403, 429)
• Znacznik czasu (ze strefą czasową)
• ID żądania lub ID korelacji
• Ostatnia udana synchronizacja (jeśli istotne)
• Krótka, niesensytywna wiadomość (jedno zdanie)

Unikaj czegokolwiek, co mogłoby wyciec tajemnic lub danych klienta. Nie pokazuj tokenów dostępu, kluczy API, pełnych nagłówków ani pełnych payloadów żądań/odpowiedzi. Nawet "niewinne" fragmenty mogą zawierać e-maile, identyfikatory rekordów lub ukryte pola.

Mały przykład

Jeśli klient rozłącza i ponownie łączy narzędzie, następne uruchomienie może nie powieść się z powodu wygasłego tokena. Zamiast "401 Unauthorized" pokaż:

"Ważność autoryzacji wygasła. Nie możemy odświeżyć połączenia z HubSpot, więc nowe leady nie synchronizują się. Szczegóły: kod 401, 2026-01-25 10:42 UTC, request ID 8f2c..., ostatni sukces 2026-01-25 08:10 UTC."

To daje klientom pewność i pozwala Twojemu zespołowi szybko zlokalizować problem, bez nadmiaru danych.

Następne kroki, które klienci rzeczywiście mogą wykonać

Gdy coś zawodzi, najlepsza strona statusu integracji nie tylko mówi "błąd", ale wskazuje, co klient może zrobić teraz i co się stanie dalej.

Zacznij od akcji, które rozwiązują najczęstsze przyczyny problemów z API zewnętrznymi. Każdy przycisk lub instrukcja powinna być konkretna, nie ogólna, i pokazywać oczekiwany czas.

• Ponowne połączenie konta: przeprowadź użytkownika przez flow ponownej autoryzacji, potem potwierdź "Połączono" i ustaw w kolejkę nową synchronizację (zwykle 1–5 minut).
• Aktualizacja uprawnień: wyjaśnij, które uprawnienie brakuje, potem ponownie sprawdź dostęp i automatycznie spróbuj ponownie ostatnie zadanie.
• Ponów synchronizację: uruchom ponownie najpierw tylko nieudaną część, a potem kontynuuj pełną synchronizację, jeśli się powiedzie (pokaż szacowany przedział czasu).
• Zmień ustawienia synchronizacji: pozwól zmniejszyć zakres (np. mniej rekordów), by odblokować proces, a potem rozszerzyć go później.
• Eksport raportu błędów: pobierz krótkie, bezpieczne dla klienta podsumowanie, które można udostępnić wewnętrznie.

Po każdej akcji pokaż wyraźny rezultat: "Spróbujemy ponowić automatycznie", "Następne uruchomienie zaplanowane na 14:00" lub "Czekamy na odpowiedź dostawcy". Jeśli stosujesz backoff, powiedz to prostym językiem: "Spróbujemy do 3 razy w ciągu następnych 30 minut."

Dla problemów bez możliwości akcji bądź uczciwy i spokojny. Na przykład: "Dostawca ma awarię. Nic nie musisz zmieniać. Wznawiamy synchronizację, gdy odzyskają usługę, i opublikujemy aktualizację tutaj w ciągu 60 minut."

Gdy potrzebne jest wsparcie, powiedz klientom dokładnie, co wysłać, by można było szybko naprawić problem:

• Nazwa integracji i e-mail (lub ID) podłączonego konta
• Czas ostatniej udanej synchronizacji i czas ostatniego błędu
• Kod błędu pokazywany na stronie (nie surowe logi)
• Co kliknęli i co się stało

Jeśli budujesz to w AppMaster, możesz powiązać te akcje z prostymi endpointami backendowymi i interfejsem klienckim bez ujawniania poufnych danych dostawcy.

Jak krok po kroku zbudować stronę statusu

Traktuj stronę statusu integracji jak mały feature produktowy, nie ekran debugowania. Jeśli klient może odpowiedzieć na pytanie "Czy to działa i co zrobić dalej?" jesteś w większości na dobrej drodze.

Krok 1: Zdefiniuj stany i reguły za nimi stojące

Wybierz krótki zestaw stanów i trzymaj je spójnie dla wszystkich integracji. Popularne wybory to Healthy, Delayed, Failing i Paused. Spisz dokładne reguły wyzwalające każdy stan (np. "Failing jeśli ostatnie 3 uruchomienia zakończyły się błędem" lub "Delayed jeśli brak udanej synchronizacji przez 6 godzin").

Krok 2: Rejestruj właściwe zdarzenia

Strona będzie tak dobra, jak dane za nią stojące. Loguj każde uruchomienie, każde ponowienie i każdy błąd w ustrukturyzowany sposób. Zrób "ostatni czas udanej synchronizacji" polem pierwszej klasy, a nie wartością wyliczaną z surowych logów.

Krok 3: Zaprojektuj prosty układ

Dobra strona statusu integracji zwykle ma trzy części: górne podsumowanie (stan + ostatni sukces), krótką historię (ostatnie uruchomienia) i wyraźny obszar akcji (co klient może zrobić teraz). Trzymaj szczegóły jedno kliknięcie dalej, żeby główny widok był spokojny.

Prosta kolejność budowy:

1. Stwórz model stanów i reguły.
2. Zapisuj historię uruchomień, błędy i ponowienia.
3. Zbuduj UI: podsumowanie, historię i akcje.
4. Dodaj widoczność opartą na rolach (admin vs viewer).
5. Waliduj stronę przy rzeczywistych awariach.

Krok 4: Dodaj widoczność opartą na rolach

Pokaż różne poziomy szczegółów. Widoki dla viewerów mogą zawierać status, czasy i bezpieczne wskazówki. Admini zobaczą kody błędów, końcówki, które zawodzą, oraz wskazówki konfiguracyjne (np. "token wygasł").

Krok 5: Testuj przy rzeczywistych przypadkach awarii

Nie zatrzymuj się na testach ścieżek szczęśliwych. Odtwórz typowe błędy:

• Wygasły token
• Limit żądań (rate limit)
• Timeout sieciowy
• Nieprawidłowe uprawnienia
• Błędne mapowanie danych

Jeśli budujesz w AppMaster, możesz zamodelować tabele w Data Designer, zarejestrować zdarzenia przy pomocy Business Processes i złożyć UI przy użyciu web lub mobile builderów bez ręcznego kodowania.

Dane potrzebne za stroną

Widoczna dla klienta strona statusu integracji jest tylko tak dobra, jak dane za nią. Aby strona ładowała się szybko i była spójna, oddziel "szybkie zdrowie" od głębszej historii i surowych logów.

Zacznij od tabeli historii uruchomień. To kręgosłup dla "ostatnie uruchomienie", "ostatni sukces" i widoków trendów. Każdy wiersz powinien reprezentować jedno podejście synchronizacji, nawet jeśli zakończy się szybko niepowodzeniem.

Utrzymuj rekord uruchomienia mały i spójny:

• Czas rozpoczęcia i zakończenia (lub czas trwania)
• Wynik (sukces, częściowy, nieudany)
• Przetworzone elementy (opcjonalnie nieudane)
• Identyfikator integracji/dostawcy (dla produktów wielodostawczych)
• ID korelacji (by powiązać uruchomienia z błędami i logami wewnętrznymi)

Następnie przechowuj znormalizowany rekord błędu. Unikaj wrzucania pełnych stack trace'ów do danych widocznych dla klienta. Zamiast tego zapisz ustrukturyzowany typ błędu (auth, rate limit, validation, timeout), krótką wiadomość, nazwę dostawcy, kiedy się pojawił i kiedy ostatnio wystąpił. To pozwala grupować powtarzające się błędy i pokazywać "zawodzi od wtorku" bez hałasu.

Dodaj mały model "integration health" do szybkiego odczytu. Traktuj go jako pamięć podręczną per klient i integrację: aktualny stan, czas ostatniej udanej synchronizacji, czas ostatniego uruchomienia i krótki powód. UI czyta to najpierw, a historię uruchomień pobiera tylko po otwarciu szczegółów.

Na koniec zdecyduj o retencji. Klienci zwykle potrzebują dni lub tygodni historii uruchomień, by zrozumieć, co się zmieniło, podczas gdy Twoje wewnętrzne logi mogą wymagać dłuższego przechowywania. Ustal jasne okresy (np. 30–90 dni historii widocznej dla klienta) i trzymaj surowe payloady tylko w wewnętrznym magazynie.

Jeśli budujesz na AppMaster, modele te łatwo mapują się na tabele w Data Designer, a Twój flow synchronizacji może zapisywać rekordy uruchomień i błędów z Business Process w tym samym miejscu za każdym razem.

Częste błędy i pułapki

Strona statusu integracji jest użyteczna tylko wtedy, gdy odzwierciedla rzeczywistość. Najszybszy sposób na utratę zaufania to pokazanie zielonej ikony "Wszystko OK" gdy ostatni udany sync był trzy dni temu. Jeśli Twoje dane są przestarzałe, powiedz to, a "Ostatnia udana synchronizacja" powinno być tak widoczne jak bieżący stan.

Innym częstym błędem jest wyrzucenie surowych kodów błędów i koniec. "401" lub "E1029" może być prawdą, ale nie jest pomocne. Klienci potrzebują opisu w prostym języku, co się zepsuło i co to wpływa (np. "Nowe zamówienia nie będą importowane, ale istniejące zamówienia pozostają niezmienione").

Ludzie też gubią się, gdy zachowanie ponowień jest ukryte. Jeśli system ponawia co 15 minut, a strona nic o tym nie mówi, klienci będą ciągle odświeżać i klikać "Synchronizuj teraz", a potem zgłaszać, że to nie działa. Pokaż ponawiania, łącznie z następnym planowanym podejściem i informacją, czy dozwolone jest ręczne ponowienie.

Uważaj na te pułapki:

• Zielony status oparty na "braku ostatnich błędów" zamiast na "ostatnim udanym synchronie".
• Tylko techniczne kody błędów bez ludzkiego wyjaśnienia lub opisu wpływu.
• Brak widoczności automatycznych ponowień, backoffu lub oczekujących uruchomień.
• Szczegóły błędów ujawniające tajemnice (tokeny, pełne nagłówki, dane klientów, payloady webhooków).
• Zbyt wiele etykiet statusu (10+), przez co nikt nie rozróżnia "zablokowane" od "opóźnione".

Trzymaj etykiety statusu krótkie i jasne, np. Healthy, Delayed, Action needed, Outage. Zdefiniuj je raz i trzymaj się ich.

Praktyczny przykład: jeśli token Shopify wygasł, nie pokazuj stack trace'a ani tokena. Pokaż "Połączenie wygasło", czas rozpoczęcia problemu, co nie synchronizuje się i bezpieczny następny krok, np. "Ponownie połącz konto." Jeśli budujesz w AppMaster, traktuj tekst błędu jako treść skierowaną do użytkownika, nie jako surowe logi, i domyślnie zaciemniaj pola wrażliwe.

Szybka lista kontrolna przed wydaniem

Zanim wypuścisz stronę statusu integracji, przejrzyj ją tak, jakbyś był klientem, który właśnie zauważył brak danych. Cel jest prosty: potwierdzić, co jest zepsute, jak poważne jest to i co zrobić dalej bez paniki lub zgadywania.

Zacznij od linii tytułowej. Etykieta statusu powinna być jednoznaczna (Healthy, Delayed, Action required) i zawsze powinna zawierać czas ostatniej udanej synchronizacji. Jeśli nie możesz pewnie pokazać "ostatniego sukcesu", klienci założą, że nic nie działa.

Potem sprawdź akcje. Jeśli ponowne połączenie lub ponowienie jest możliwe, zrób to oczywistym i bezpiecznym. Administrator klienta nie powinien musieć otwierać zgłoszenia, by wykonać podstawową akcję jak ponowna autoryzacja konta.

Użyj tej listy kontrolnej przed wydaniem:

• Jasna etykieta statusu plus czas ostatniej udanej synchronizacji (i stan bieżącego uruchomienia, jeśli dotyczy)
• Jednoklikowa ścieżka dla admina do ponownego połączenia lub ponowienia z krótkim potwierdzeniem, co się wydarzy dalej
• Tekst błędu, który unika obwiniania, wyjaśnia wpływ i ustala oczekiwania (np. "Spróbujemy ponownie za 15 minut")
• Brak sekretów i danych osobowych (bez tokenów, bez pełnych payloadów, bez surowych ID, które ujawniają klientów)
• Support może dopasować widok klienta do wewnętrznych logów za pomocą ID korelacji lub krótkiego kodu referencyjnego

Zrób szybki test słownictwa na realnym scenariuszu: podczas godzin szczytu dostawca API osiąga limit żądań. Strona powinna powiedzieć, jakie dane są opóźnione, czy starsze dane są nadal widoczne i kiedy zaplanowano następne ponowienie. "Ich API się nie powiodło" jest mniej pomocne niż "Synchronizacja wstrzymana z powodu limitów żądań. Spróbujemy ponownie o 14:30 UTC. Brak koniecznych działań."

Jeśli budujesz w AppMaster, traktuj teksty statusu i akcje jako część flow produktowego: strona klienta, przycisk ponowienia i wewnętrzne ID referencyjne powinny być napędzane tym samym rekordem statusu na backendzie, żeby nigdy się nie rozjechały.

Przykład: gdy wygasa token API zewnętrznego

Typowy przypadek: synchronizacja CRM zatrzymuje się po tym, jak ktoś zmienił uprawnienia w ustawieniach admina CRM. Token używany przez aplikację nadal może istnieć, ale stracił dostęp do kluczowych obiektów (albo wygasł). Po stronie systemu zadania zaczynają się nie powodzić. Po stronie klienta dane przestają się aktualizować.

Na stronie statusu integracji klient powinien zobaczyć jasne, spokojne podsumowanie. Na przykład: Status: Degraded (synchronizacja CRM wstrzymana) oraz ostatnia udana synchronizacja (np. "Ostatni sukces: 25 sty 10:42"). Dodaj krótką linię wyjaśniającą wpływ: "Nowe kontakty i transakcje nie będą się pojawiać, dopóki połączenie nie zostanie naprawione."

Pomocne jest pokazanie, co jest dotknięte, bez wyrzucania logów. Proste pole "Dane dotknięte" wystarczy: Kontakty: brak synchronizacji, Transakcje: brak synchronizacji, Notatki: OK. Jeśli produkt ma wiele workspace'ów lub pipeline'ów, wskaż, które z nich są dotknięte.

Następnie podaj jedną rekomendowaną akcję, odpowiadającą najczęstszej naprawie:

• Ponownie połącz konto CRM (ponowna autoryzacja)
• Potwierdź, że użytkownik ma uprawnienia do odczytu Kontakty i Transakcje
• Uruchom ponownie po ponownym połączeniu

Po ponownym połączeniu strona powinna zmienić się natychmiast, nawet przed kolejnym pełnym uruchomieniem. Pokaż: "Połączenie przywrócone. Następna synchronizacja zacznie się za 5 minut" (lub "Ponowienie uruchamiane teraz"). Gdy ponowienie się zakończy, zastąp ostrzeżenie potwierdzeniem: "Synchronizacja OK. Dane zaktualizowane o 11:08."

Jeśli budujesz w AppMaster, możesz zamodelować "stan połączenia", "ostatni sukces" i "następne uruchomienie" w Data Designer, a potem aktualizować je z flow synchronizacji w Business Process Editor, żeby strona statusu integracji była aktualna bez ręcznej pracy supportu.

Kolejne kroki do wdrożenia w Twoim produkcie

Zacznij od małego zestawu, żeby szybko wypuścić i uczyć się z rzeczywistego użycia. Prosta strona statusu integracji pokazująca stan na pierwszy rzut oka i czas ostatniej udanej synchronizacji odpowie na większość pytań klientów od razu. Gdy to będzie niezawodne, dodaj głębsze szczegóły jak ostatnie błędy, co jest ponawiane i co klient może zrobić dalej.

Dokładność liczy się bardziej niż design. Jeśli strona statusu raz się myli, klienci przestaną jej ufać i wrócą do supportu. Instrumentuj zadania synchronizacji tak, żeby każde uruchomienie zapisywało jasny rezultat (sukces, częściowy, nieudany), znaczniki czasu i kategorię błędu. Rejestruj ponowienia tak samo, łącznie z informacją, kiedy zaplanowano kolejne podejście.

Praktyczny plan wdrożenia:

• Wypuść v1: odznaka statusu + czas ostatniej udanej synchronizacji + "zaktualizowano X minut temu"
• Dodaj logowanie: przechowuj ostatnie uruchomienie, ostatni sukces, licznik błędów i czas następnego ponowienia per integracja
• Dodaj wskazówki: zmapuj każdą kategorię błędu na przyjazny komunikat i konkretną akcję
• Zgraj support: używaj tych samych sformułowań w dokumentacji i w UI, by uniknąć nieporozumień
• Rozszerz: dodaj krótką oś czasu "ostatnich zdarzeń" gdy podstawy będą stabilne

Trzymaj słownictwo spójne między produktem a supportem. Jeśli support mówi "Ponownie połącz konto", UI powinno używać tej samej formy, a nie technicznego "Reauthorize OAuth". Pomaga też informacja, co się stanie po działaniach klienta, np. "Spróbujemy ponownie automatycznie w ciągu 5 minut."

Jeśli chcesz to zbudować bez dużego zaangażowania inżynierskiego, platforma no-code jak AppMaster może trzymać dane, logikę i UI w jednym miejscu. Zamodeluj Integration i SyncRun w Data Designer (PostgreSQL), zapisuj wyniki synchronizacji z Business Process Editor i zbuduj prostą stronę klienta w web UI builderze. Gdy wymagania się zmienią, AppMaster wygeneruje aplikację ponownie, więc iterowanie pól i komunikatów pozostanie bezpieczne. Wypuść najpierw v1 strony statusu, a potem rozwijaj ją na podstawie rzeczywistych zgłoszeń do supportu.