Wersja robocza · publiczna

PumpenLotse · Manual właściciela

Jak system ma działać — i co działa już dziś.

Jedna mapa produktu dla właściciela, administratorów i przyszłych partnerów. Statusy na tej stronie celowo oddzielają działające funkcje od przygotowanej specyfikacji i planów.

Działa

Dostępne w obecnej aplikacji

Przygotowane

Opisane lub częściowo przygotowane

Planowane

Nie jest jeszcze aktywne

Sekcja 01

Cel systemu i role

PumpenLotse ma prowadzić klienta od danych budynku do właściwego partnera, zachowując jasny podział odpowiedzialności i dostępu.

Ścieżka publiczna klienta

Działa

Gdzie: Landing page, kreator Heizlast, porównanie pomp i FAQ.
Co robi: Pomaga zrozumieć potrzeby budynku i przygotować dane do rozmowy ofertowej.
Jak się zachowuje: Działa bez konta; obecna wersja podglądu oferty nie wysyła danych do partnerów.
Efekt: Klient otrzymuje wynik Heizlast i czytelny punkt startu do dalszej decyzji.
Kto ma dostęp: Każdy odwiedzający stronę.

Właściciel / administrator

Przygotowane

Gdzie: Zabezpieczony panel `/admin`; bez skonfigurowanej bazy pozostaje zamknięty.
Co robi: Zarządza zapytaniami, partnerami, dopasowaniem, przydziałem i historią działań.
Jak się zachowuje: Login, RBAC, zapytania panelu i audyt są zaimplementowane; uruchomienie wymaga osobnej bazy i jawnie utworzonego konta właściciela.
Efekt: Pełna kontrola nad jakością i dystrybucją leadów.
Kto ma dostęp: Wyłącznie konta z rolą właściciela lub administratora.

Partner instalacyjny

Przygotowane

Gdzie: Zabezpieczony portal `/partner`; bez skonfigurowanej bazy pozostaje zamknięty.
Co robi: Odbiera wyłącznie przypisane zapytania, ocenia je i aktualizuje status obsługi.
Jak się zachowuje: Każde zapytanie do danych ponownie sprawdza firmę partnera, przydział, aktywny dostęp i uprawnienia.
Efekt: Partner pracuje na uporządkowanym inboxie bez dostępu do cudzych leadów.
Kto ma dostęp: Zaproszeni użytkownicy konkretnej firmy partnerskiej.

Sekcja 02

Pełny przepływ klienta

Docelowy proces łączy publiczne narzędzia z kontrolowanym przydziałem i przejrzystą informacją zwrotną.

Docelowa sekwencja

01Działa

Klient

Uzupełnia dane budynku i może obliczyć Heizlast.

02Przygotowane

Numer sprawy

Szyfrowany intake zapisuje zapytanie i nadaje identyfikator po konfiguracji bazy.

03Przygotowane

Panel admina

Zabezpieczone widoki i zapytania czekają na skonfigurowaną bazę.

04Przygotowane

Matching

Twarde filtry tworzą listę, scoring ją porządkuje.

05Przygotowane

Przydział

Admin wybiera direct, Top lub maksymalnie 3 firmy w trybie shared.

06Przygotowane

Partner

Portal, izolacja firmy i accept/decline są zaimplementowane, lecz baza nie jest jeszcze skonfigurowana.

07Przygotowane

Klient

Chroniony widok pokazuje status i firmy, które realnie przyjęły lead.

Klient → numer zapytania → partner

Przygotowane

Gdzie: Specyfikacja procesu pomiędzy formularzem, panelem admina i portalem partnera.
Co robi: Definiuje kolejność: dane klienta, numer sprawy, weryfikacja, matching, przydział, decyzja partnera i kontakt.
Jak się zachowuje: Model, szyfrowane pola, statusy, kolejka i przydziały są gotowe w kodzie; publiczny intake pozostaje wyłączony do czasu osobnej bazy, klucza szyfrowania i jawnej bramki operacyjnej.
Efekt: Każda sprawa ma jednoznaczny identyfikator i mierzalną historię.
Kto ma dostęp: Klient widzi swoją sprawę; admin całość; partner tylko przydzielony zakres.

Raport Heizlast w sprawie

Działa

Gdzie: Publiczny kreator Heizlast i generowany raport PDF.
Co robi: Przelicza dane budynku i tworzy wynik możliwy do wykorzystania w procesie ofertowym.
Jak się zachowuje: Algorytm działa lokalnie w aplikacji; automatyczne dołączenie raportu do leada jest planowane.
Efekt: Wspólny, techniczny punkt odniesienia dla klienta i przyszłego partnera.
Kto ma dostęp: Klient; docelowo także admin i przypisany partner.

Sekcja 03

Panel administratora

Panel ma być centrum operacyjnym, nie tylko listą kontaktów.

Dashboard i lista zapytań

Przygotowane

Gdzie: Widoki `/admin` i `/admin/leads`.
Co robi: Pokazuje wolumen, nowe sprawy, oczekujące decyzje, SLA i skuteczność przydziałów.
Jak się zachowuje: Widoki i zabezpieczone zapytania są zbudowane; dane pojawią się dopiero po migracji i konfiguracji PostgreSQL.
Efekt: Administrator od razu widzi, co wymaga działania.
Kto ma dostęp: Właściciel i administratorzy zgodnie z rolą.

Szczegóły, statusy i historia

Przygotowane

Gdzie: Warstwa danych panelu admina i schemat historii sprawy.
Co robi: Łączy dane klienta, budynek, Heizlast, dopasowania, przydziały, decyzje i notatki.
Jak się zachowuje: Serwis przydziałów zapisuje decyzje, timeouty, fallback i audyt; rozbudowany ekran pojedynczej sprawy jest kolejnym krokiem UI.
Efekt: Pełny ślad obsługi bez niejawnych zmian.
Kto ma dostęp: Uprawnieni administratorzy; zakres danych zależny od roli.

Sekcja 04

Tryby przydziału

Administrator wybiera model dystrybucji odpowiedni dla konkretnej sprawy.

Jedna firma · direct

Przygotowane

Gdzie: Karta zapytania w inboxie administratora.
Co robi: Przekazuje sprawę jednemu, świadomie wybranemu partnerowi.
Jak się zachowuje: Pozostali partnerzy nie widzą leada; odmowa lub 24-godzinny timeout roboczy automatycznie uruchamia kolejnego nadal zgodnego kandydata.
Efekt: Najbardziej kontrolowany wariant dla spraw wymagających konkretnej kompetencji.
Kto ma dostęp: Admin wybiera; dostęp uzyskuje wybrany partner.

Top Partnerzy

Przygotowane

Gdzie: Tryb oparty na rankingu wyników matchingu.
Co robi: Wybiera najlepsze profile spośród partnerów, którzy przeszli twarde filtry.
Jak się zachowuje: Top status podnosi wynik, ale nigdy nie omija zgodności marki, regionu ani aktywnego dostępu.
Efekt: Szybki przydział do najlepiej rokujących firm.
Kto ma dostęp: Admin uruchamia; widoczność otrzymują tylko wybrani partnerzy.

Maksymalnie 3 partnerów · shared

Przygotowane

Gdzie: Ręczny lub wspomagany wybór w karcie sprawy.
Co robi: Pozwala udostępnić lead maksymalnie trzem zgodnym firmom, aby klient otrzymał do trzech porównywalnych ofert.
Jak się zachowuje: System blokuje czwarte miejsce, pokazuje kryteria dopasowania przed zatwierdzeniem i nigdy nie obciąża firmy, która nie uzyskała dostępu.
Efekt: Klient dostaje realny wybór bez masowej dystrybucji danych.
Kto ma dostęp: Admin; następnie wyłącznie zatwierdzeni partnerzy.

Auto-Entdeckung · automatyczne zabezpieczenie leada

Przygotowane

Gdzie: Ustawienia aplikacji iOS partnera SHK oraz serwer routingu.
Co robi: Partner określa tryb shared lub exclusive, limit miesięczny, maksymalną cenę, promień działania, zakres Heizlast i wymaganą zgodność marki.
Jak się zachowuje: Po uruchomieniu produkcyjnym każdy nowy lead będzie sprawdzany po stronie serwera, niezależnie od tego, czy aplikacja jest otwarta. Automatyczne zabezpieczenie będzie możliwe tylko po jednoczesnym spełnieniu aktywnego abonamentu, budżetu, limitu, regionu, marki, zakresu Heizlast i pozostałych twardych warunków. Shared zajmuje jedno z maksymalnie trzech miejsc; exclusive zajmuje jedyne miejsce i zamyka lead dla innych firm.
Efekt: SHK nie musi stale obserwować inboxu, a automatyzacja nie może ominąć budżetu, limitu ani zgodności technicznej.
Kto ma dostęp: Partner ustawia własną politykę; serwer ją egzekwuje; administrator widzi wynik i pełny audyt.

Uczciwa rotacja i ochrona przed przejmowaniem rynku

Przygotowane

Gdzie: Transakcyjny mechanizm wyboru kandydatów dla Auto-Entdeckung.
Co robi: Rozstrzyga sytuację, gdy ten sam lead spełnia warunki wielu firm, na przykład dziesięciu SHK w jednym regionie.
Jak się zachowuje: Najpierw odrzucane są firmy niespełniające twardych warunków. Wśród równorzędnych kandydatów pierwszeństwo ma partner z mniejszą liczbą automatycznych przydziałów w bieżącym miesiącu, a następnie ten, który najdłużej czeka od poprzedniego przydziału. Zapis odbywa się w jednej transakcji: nie może powstać czwarty dostęp shared, dwóch zwycięzców exclusive ani przekroczenie limitu lub budżetu. Limit miesięczny partnera i osobny limit exclusive chronią przed masowym przejmowaniem leadów.
Efekt: Nie wygrywa najszybszy telefon ani najszybsze łącze; miejsca są rozdzielane przewidywalnie i audytowalnie, a niewybrane firmy nie płacą.
Kto ma dostęp: Reguły konfiguruje właściciel; partner widzi własne limity i wykorzystanie, bez dostępu do danych konkurencji.

24 godziny Pon–Pt i automatyczny fallback

Przygotowane

Gdzie: Kolejka routingu, serwis decyzji partnera i worker timeoutów.
Co robi: Daje partnerowi 24 godziny liczone tylko od poniedziałku do piątku na akceptację; odrzucić może natychmiast.
Jak się zachowuje: Weekend pauzuje zegar. Odrzucenie lub timeout ponownie sprawdza twarde filtry i oferuje sprawę następnej firmie; pusta kolejka kończy się `NEEDS_ADMIN`.
Efekt: Lead nie zatrzymuje się u nieaktywnego partnera, a każda zmiana ma ślad audytowy.
Kto ma dostęp: Partner odpowiada na własny przydział; admin widzi kolejkę i historię; worker wykonuje wyłącznie kontrolowane przejścia.

Sekcja 05

Silnik dopasowania

Najpierw bezwzględna zgodność, potem ranking jakości. Wysoki scoring nie może naprawić braku wymaganej marki lub regionu.

Przykład wyjaśniający · nie jest aktywnym przydziałem

Zapytanie wymaga Panasonic

Profil z potwierdzoną obsługą Panasonic, właściwym regionem, dostępnością i aktywnym dostępem przechodzi do scoringu.

Profil obsługuje wyłącznie Viessmann

Profil odpada na twardym filtrze marki — nawet jeśli ma lepszą ocenę, szybszą reakcję albo status Top.

Twarde filtry

Przygotowane

Gdzie: Warstwa kwalifikacji przed scoringiem.
Co robi: Sprawdza markę, promień lub region, rodzaj instalacji, aktywny abonament i bieżącą dostępność.
Jak się zachowuje: Niespełnienie dowolnego wymogu usuwa profil z listy kandydatów.
Efekt: Do rankingu trafiają wyłącznie partnerzy zdolni obsłużyć sprawę.
Kto ma dostęp: Reguły konfiguruje admin; partner widzi własny profil zgodności.

Scoring jakości

Przygotowane

Gdzie: Ranking profili po przejściu twardych filtrów.
Co robi: Porządkuje kandydatów według odległości, czasu reakcji, skuteczności, oceny i statusu Top.
Jak się zachowuje: Wagi mają być jawne dla właściciela i wersjonowane; wynik wspiera decyzję, nie zastępuje admina.
Efekt: Powtarzalne i wyjaśnialne rekomendacje partnerów.
Kto ma dostęp: Pełny wynik dla admina; partner bez wglądu w cudze wyniki.

Sekcja 06

Baza partnerów

Profil partnera ma opisywać zarówno kompetencje techniczne, jak i gotowość operacyjną.

Profil firmy i kompetencji

Przygotowane

Gdzie: Docelowa baza partnerów.
Co robi: Przechowuje firmę, kontakty, obszar działania, marki i modele, zakres usług, certyfikaty i dostępność.
Jak się zachowuje: Zmiany krytycznych pól mogą wymagać zatwierdzenia przez admina przed użyciem w matchingu.
Efekt: Aktualny obraz tego, jakie sprawy partner może faktycznie obsłużyć.
Kto ma dostęp: Admin całość; partner własny profil i dozwolone pola.

Abonament i dane rozliczeniowe

Planowane

Gdzie: Część komercyjna profilu partnera.
Co robi: Łączy status abonamentu, dane do faktur i przyszłą historię rozliczeń.
Jak się zachowuje: Brak aktywnego dostępu ma blokować nowe przydziały bez usuwania historii firmy.
Efekt: Spójność uprawnień operacyjnych i rozliczeń.
Kto ma dostęp: Właściciel, uprawniony admin i partner w zakresie własnej firmy.

Prospecting, źródła i publiczna mapa

Przygotowane

Gdzie: Panel `/admin/prospects`, import CSV, kontrolowany audyt stron i `/api/public/partner-map`.
Co robi: Oddziela prospekty od partnerów, zapisuje provenance/licencję, dowody marki, deduplikację, suppression i stan weryfikacji.
Jak się zachowuje: Google jest zablokowane jako źródło własnej bazy. Prospekt nigdy nie trafia do routingu ani mapy; endpoint publiczny zwraca tylko minimalne, zgrubne dane zweryfikowanych aktywnych partnerów.
Efekt: Można budować sieć SHK bez publikowania niezweryfikowanych firm i bez mieszania researchu z routingiem.
Kto ma dostęp: Prospekty wyłącznie dla właściciela/admina; publiczna mapa pokazuje tylko zagregowane pokrycie.

Sekcja 07

Konta partnerów

Dostęp powstaje przez kontrolowane zaproszenie, nigdy przez ręczne przekazywanie hasła.

Zaproszenie i ustawienie hasła

Przygotowane

Gdzie: Panel admina oraz jednorazowa ścieżka `/einladung`.
Co robi: Tworzy zaszyfrowane, 72-godzinne zaproszenie do ustawienia własnego hasła; nie wysyła go automatycznie.
Jak się zachowuje: Token jest zapisany wyłącznie jako hash, wygasa po użyciu, a konto powstaje dopiero po ustawieniu silnego hasła. Kanał e-mail pozostaje wyłączony.
Efekt: Bezpieczne uruchomienie konta bez jawnych haseł.
Kto ma dostęp: Admin zaprasza; odbiorca kończy aktywację.

Reset i blokada

Przygotowane

Gdzie: Ekran logowania i zarządzanie użytkownikami firmy.
Co robi: Pozwala zresetować dostęp, wymusić ponowne uwierzytelnienie lub zablokować konto.
Jak się zachowuje: Baza przechowuje wyłącznie hash; sesje są nieprzewidywalne i odwoływalne. Pełny ekran resetu pozostaje do podłączenia bez użycia poczty.
Efekt: Odzyskiwanie i odcinanie dostępu bez naruszania poufności.
Kto ma dostęp: Użytkownik resetuje własne hasło; admin zarządza blokadą.

Sekcja 08

Panel partnera

Portal partnera ma koncentrować się na decyzji i obsłudze, nie na przeglądaniu całej bazy.

Inbox leadów i decyzja

Przygotowane

Gdzie: Widoki `/partner` i `/partner/leads` oraz akcje accept/decline.
Co robi: Pokazuje przypisane leady, szczegóły, raport Heizlast oraz akcje akceptacji i odrzucenia.
Jak się zachowuje: Dostęp jest ograniczony do firmy i przypisania; decyzja zapisuje czas, historię i audyt. Uruchomienie wymaga PostgreSQL.
Efekt: Mierzalny proces od przydziału do podjęcia sprawy.
Kto ma dostęp: Użytkownicy firmy wyłącznie dla leadów przypisanych tej firmie.

Profil, marki, region i abonament

Przygotowane

Gdzie: Widoki `/partner/profile` i `/partner/billing`.
Co robi: Pozwala utrzymać kompetencje, zasięg, dostępność i podgląd statusu abonamentu; faktury pojawią się później.
Jak się zachowuje: Zmiana danych wpływających na matching może podlegać akceptacji administratora.
Efekt: Partner sam utrzymuje aktualność informacji operacyjnych.
Kto ma dostęp: Właściciel konta firmy i wskazani użytkownicy.

Sekcja 09

E-maile do partnerów

Powiadomienie ma zachęcać do zalogowania, ale nie może wynosić danych osobowych poza zabezpieczony portal.

Teaser bez danych osobowych

Przygotowane

Gdzie: Wersjonowane szablony i podgląd `/admin/messages`.
Co robi: Informuje o regionie, typie projektu i czasie na reakcję bez ujawniania nazwiska, telefonu lub e-maila klienta.
Jak się zachowuje: Szablony są wyłącznie preview-only, a schemat outbox uniemożliwia oznaczenie wysyłki. SMTP/API nie są podłączone.
Efekt: Szybka informacja z minimalnym ryzykiem prywatności.
Kto ma dostęp: Wyłącznie adresy aktywnych użytkowników przypisanego partnera.

Pełne dane po zalogowaniu

Przygotowane

Gdzie: Zabezpieczony widok zaakceptowanego leada.
Co robi: Udostępnia dane kontaktowe dopiero po potwierdzeniu uprawnień i aktywnego dostępu.
Jak się zachowuje: Przed decyzją partner widzi wyłącznie teaser budynku. Dane kontaktowe są odszyfrowywane dopiero dla zalogowanej firmy po stanie `ACCEPTED`.
Efekt: Dane klienta nie są przesyłane otwartym kanałem e-mailowym.
Kto ma dostęp: Uprawniony użytkownik przypisanego partnera.

Sekcja 10

Powiadomienia klienta

Klient powinien wiedzieć, co dzieje się ze sprawą i kto faktycznie przyjął kontakt.

Numer sprawy i status

Przygotowane

Gdzie: Szablon potwierdzenia i chroniony tokenem podgląd `/vorgang`.
Co robi: Przekazuje numer zapytania, aktualny status i ważne zdarzenia procesu.
Jak się zachowuje: Bezpieczny intake nadaje numer i jednorazowy token śledzenia; publiczny formularz i realne powiadomienia pozostają wyłączone do konfiguracji bazy i zgody operacyjnej.
Efekt: Klient nie musi domyślać się, czy zapytanie zostało przyjęte.
Kto ma dostęp: Klient przypisany do sprawy; admin ma historię komunikacji.

Firmy, które przyjęły zapytanie

Przygotowane

Gdzie: Chroniony widok sprawy klienta po akceptacji partnera.
Co robi: Pokazuje wyłącznie firmy, które realnie przyjęły sprawę, wraz z dozwolonymi danymi kontaktowymi.
Jak się zachowuje: Widok korzysta wyłącznie ze stanu `ACCEPTED`; odrzucone i wygasłe przydziały nigdy nie są prezentowane jako wykonawcy. Wysyłka pozostaje wyłączona.
Efekt: Przejrzysta lista faktycznie zainteresowanych firm.
Kto ma dostęp: Klient, admin oraz konkretny partner w swojej relacji.

Weryfikacja numeru przez SMS

Przygotowane

Gdzie: Kolejka komunikacyjna, endpoint potwierdzenia i blokada routingu.
Co robi: Potwierdza, że numer telefonu należy do osoby składającej zapytanie, zanim lead może zostać przekazany SHK.
Jak się zachowuje: Kod wygasa po 10 minutach, ma limit pięciu prób i pięciu wysyłek na dobę. Kod jest przechowywany wyłącznie jako hash, a odbiorca i treść kolejki są szyfrowane. Bez skonfigurowanego dostawcy SMS system odmawia przyjęcia produkcyjnego zgłoszenia.
Efekt: Mniej fałszywych leadów i wyższa wartość zapytania bez obowiązkowej osobnej weryfikacji e-maila.
Kto ma dostęp: Klient przez token własnej sprawy; admin widzi status weryfikacji.

Zdjęcia i dokumenty klienta

Przygotowane

Gdzie: Prywatny upload obiektowy i panel szczegółów sprawy.
Co robi: Obsługuje zdjęcia kotłowni, grzejników, budynku oraz PDF planu lub świadectwa energetycznego.
Jak się zachowuje: Plik trafia bezpośrednio do prywatnego magazynu przez 15-minutowy link. Limit to 20 plików po 15 MB; dozwolone są JPG, PNG, HEIC i PDF. Plik pozostaje niewidoczny dla partnera do potwierdzenia metadanych i skanowania antywirusowego.
Efekt: Lepsza kwalifikacja bez obciążania serwera aplikacji dużymi plikami i bez publicznych adresów zdjęć.
Kto ma dostęp: Klient z tokenem sprawy; admin po skanowaniu; partner dopiero po uprawnionym dostępie.

Sekcja 11

Statusy leada

Status jest zdarzeniem biznesowym. Każda zmiana powinna mieć przyczynę, wykonawcę i efekt.

Status	Co go powoduje	Efekt zmiany
Nowy	Utworzenie zapytania	Sprawa czeka na walidację
Zweryfikowany	Admin potwierdza kompletność i zgodę	Można uruchomić matching
Matching	Start kwalifikacji partnerów	Powstaje ranking kandydatów
Przypisany	Admin zatwierdza partnerów	Tworzą się kontrolowane dostępy
Przyjęty	Partner akceptuje lead	Rejestrowany jest czas reakcji
Odrzucony	Partner podaje powód odmowy	Admin może wykonać ponowny przydział
W kontakcie	Partner potwierdza rozpoczęcie rozmowy	Klient widzi aktywną obsługę
Oferta	Partner oznacza przygotowanie oferty	Sprawa trafia do etapu decyzji
Zakończony	Wynik obsługi jest znany	Zamykane są aktywne SLA
Archiwalny	Upływ retencji lub decyzja admina	Ograniczony dostęp operacyjny

Maszyna stanów leada

Przygotowane

Gdzie: Specyfikacja przyszłego backendu i historii sprawy.
Co robi: Definiuje dozwolone przejścia od nowego zapytania do zakończenia lub archiwizacji.
Jak się zachowuje: Zmiana może uruchamiać matching, powiadomienie, SLA lub zamknięcie dostępu partnera.
Efekt: Spójne raportowanie i brak niejednoznacznych etapów.
Kto ma dostęp: Admin zarządza pełnym stanem; partner wybranymi przejściami; klient widzi uproszczony status.

Sekcja 12

Płatności, abonament i faktury

Warstwa rozliczeniowa zostanie wdrożona dopiero po stabilizacji podstawowego obiegu leadów.

Billing partnerów

Planowane

Gdzie: Przyszły moduł abonamentów i rozliczeń.
Co robi: Obsłuży plany, okresy dostępu, płatności, dokumenty i historię faktur.
Jak się zachowuje: Status płatności ma wpływać na nowe przydziały, ale nie usuwać danych historycznych.
Efekt: Przewidywalny model komercyjny i automatyczna kontrola dostępu.
Kto ma dostęp: Właściciel, uprawniona księgowość i partner dla własnych rozliczeń.

Sekcja 13

Bezpieczeństwo i prywatność

Dostęp jest nadawany według roli i konkretnej relacji ze sprawą, a nie wyłącznie po samym zalogowaniu.

Zgody i minimalizacja danych

Działa

Gdzie: Publiczne formularze i walidacja danych wejściowych.
Co robi: Wymaga zgody tam, gdzie przewidziano przetwarzanie, i ogranicza zakres danych do celu formularza.
Jak się zachowuje: Obecny podgląd oferty deklaruje brak zapisu i brak wysyłki; integracje pozostają wyłączone.
Efekt: Jasna granica między demonstracją procesu a realnym przekazaniem danych.
Kto ma dostęp: Klient podaje dane; aplikacja obsługuje je wyłącznie w zadeklarowanym zakresie.

Role, audyt i izolacja partnerów

Przygotowane

Gdzie: Projekt autoryzacji przyszłego backendu.
Co robi: Wymusza zasadę najmniejszych uprawnień i zapisuje istotne operacje.
Jak się zachowuje: Partner widzi tylko przypisane leady; admin nie widzi haseł; dostęp do danych można odwołać.
Efekt: Ograniczenie skutków błędu użytkownika lub przejęcia konta.
Kto ma dostęp: Każda rola wyłącznie w swoim zakresie; audyt dla właściciela i uprawnionego admina.

Sekcja 14

Roadmapa wdrożenia

Kolejność chroni przed budowaniem automatyzacji na niestabilnych danych i uprawnieniach.

Baza danych · auth · role

Fundament

Partnerzy i kompetencje