Model uprawnień dla poziomów klientów: plany, limity, flagi

Dlaczego zespoły potrzebują modelu uprawnień

Jeśli sprzedajesz więcej niż jeden poziom, w końcu dostaniesz ten sam ticket wsparcia: „Klient X zapłacił za Pro, ale nie ma dostępu do Funkcji Y.” Bez jasnego systemu support nie może tego naprawić bezpośrednio. Prosta zmiana dostępu zamienia się w zadanie dla inżynierii.

Większym problemem jest niespójność. Reguły dostępu rozpraszają się po produkcie: checkbox w panelu admina, zahardkodowane sprawdzenie w API, notatka w arkuszu kalkulacyjnym i jednorazowa aktualizacja bazy danych z poprzedniego kwartału. Klienci widzą różne zachowania w różnych miejscach i nikt nie jest pewien, która reguła jest tą właściwą.

Model uprawnień daje jedno źródło prawdy dla tego, kto może co robić, opierając się na planie i zatwierdzonych wyjątkach. Utrzymuje przewidywalność poziomów (dzięki czemu cennik zachowuje wiarygodność), a jednocześnie zostawia miejsce na rzeczywiste sytuacje: tymczasowy upgrade, podbicie limitu czy pilotaż funkcji dla jednego konta.

„Regulować bez inżynierii” musi być konkretne. W praktyce oznacza to:

• Wsparcie zmienia dostęp w narzędziu administracyjnym edytując dane, a nie prosząc o deploy.
• Produkt czyta te same dane uprawnień wszędzie (backend, aplikacja webowa, mobile).
• Wyjątki mogą być ograniczone czasowo i odwracalne, a nie stałymi hackami.
• Zmiany są logowane: kto, kiedy i dlaczego.

Na przykład klient na poziomie Business przekracza limit aktywnych użytkowników w intensywnym sezonie. Wsparcie powinno móc przyznać +10 miejsc na 14 dni, a system powinien samodzielnie cofnąć to po upływie okresu. Inżynieria powinna być zaangażowana tylko przy dodawaniu zupełnie nowej funkcjonalności, nie przy rutynowych zmianach dostępu.

Podstawowe elementy: klienci, plany i uprawnienia

Dobry model uprawnień zaczyna się od kilku jasnych obiektów i przejrzystej odpowiedzialności. Jeśli te podstawy są niejasne, wsparcie będzie co tydzień prosić inżynierię o „jeszcze jeden wyjątek”.

Oto prosty zestaw bloków konstrukcyjnych:

• Klient (account/tenant): firma lub osoba korzystająca z produktu.
• Subskrypcja: relacja komercyjna (trial, aktywna, anulowana), często powiązana z systemem rozliczeń.
• Plan: nazwany poziom (Free, Pro, Enterprise), który definiuje domyślny dostęp.
• Uprawnienie (entitlement): rzeczywiste dozwolone zachowanie, wyprowadzone z planu plus ewentualne nadpisania.

Ewaluacja uprawnień to nie to samo co billing. Rozliczenia odpowiadają „ile i kiedy fakturować”, uprawnienia odpowiadają „co ten klient może zrobić teraz”. Klient może być nieopłacony, ale w okresie karencji, albo w pełni opłacony, a tymczasowo zablokowany z powodów zgodności. Trzymaj te decyzje rozdzielone, żeby finanse mogły naprawić faktury bez przypadkowej zmiany dostępu do produktu.

Na tym ustawieniu polegają różne grupy:

• Product definiuje, co oznaczają plany.
• Support potrzebuje bezpiecznych narzędzi do przyznawania i odbierania dostępu.
• Sales ops potrzebuje spójnych reguł dla ofert i odnowień.
• Finance potrzebuje wiarygodnego mapowania między tym, co sprzedano, a tym, jaki dostęp przyznano.

Ustal granice wcześnie. Spraw, by zawartość planu i nadpisania klientów była konfigurowalna (żeby wsparcie mogło działać), ale trzymaj zachowanie rdzenia w kodzie. Przykłady „zachowań rdzenia” to sposób obliczania pozostałego limitu, jak obsługujesz wygasłe triale i które akcje muszą być audytowane.

Flagi, limity i kwoty: wybierz właściwy typ

Większość problemów z poziomami staje się prostsza, gdy właściwie nazwiesz uprawnienie. Są trzy powszechne typy, a każdy odpowiada na inne pytanie:

• Flagi boolowskie: czy coś jest włączone czy wyłączone? Przykład: export_enabled = true.
• Limity numeryczne: ile jest dozwolone naraz? Przykład: max_seats = 10.
• Kwoty/limity okresowe: ile można użyć w czasie? Przykład: api_calls_per_month = 100000.

Flagi sprawdzają się dla funkcji, które nie powinny działać częściowo. Jeśli eksport jest wyłączony, ukryj przycisk i zablokuj endpoint. Limity pasują do ustawień pojemności, które się nie resetują, jak miejsca, projekty czy zapisane widoki.

Kwoty wymagają dodatkowej uwagi, bo czas ma znaczenie. Tickety wsparcia maleją szybko, gdy reguła resetu jest zapisana i widoczna w UI administracyjnym.

Zakres (scope) to druga decyzja, która zapobiega zamieszaniu. Flaga typu „SAML SSO enabled” zwykle dotyczy całego konta. „Max projects” może dotyczyć workspace. „Can run reports” może być na poziomie użytkownika, jeśli sprzedajesz dodatki na role.

Dla kwot wybierz jedną regułę resetu na kwotę i trzymaj się jej:

• Nigdy (kredyty dożywotnie)
• Miesięcznie (miesiąc kalendarzowy)
• Okno kroczące (ostatnie 30 dni)
• Na okres rozliczeniowy (zgodne z cyklem fakturowania)

Jeśli reguła resetu zmienia się w zależności od planu, traktuj tę regułę jako część uprawnienia, a nie wiedzę tajemną.

Praktyczny schemat bazy danych dla uprawnień

Model uprawnień przyjazny wsparciu działa najlepiej, gdy pozostaje prosty: kilka tabel, czytelne klucze i rekordy ograniczone czasowo, które można audytować. Celem jest umożliwienie administratorom zmiany dostępu przez edycję danych, a nie deploy kodu.

Zacznij od czterech podstawowych tabel: plans, plan_entitlements, customers oraz customer_overrides.

• Plany opisują poziomy (Free, Pro, Enterprise).
• Plan_entitlements opisują, co zawiera każdy plan.
• Customers wskazują na plan.
• Overrides obejmują wyjątki dla pojedynczego klienta bez zmiany planu dla wszystkich.

Kompaktowy kształt relacyjny, który dobrze się sprawdza:

• plans: id, name, description, is_active
• plan_entitlements: id, plan_id, key, type, value, unit, reset_policy, effective_from, effective_to, created_by
• customers: id, name, plan_id, status, created_at
• customer_overrides: id, customer_id, key, type, value, unit, reset_policy, effective_from, effective_to, created_by

Pola uprawnienia powinny być spójne między tabelami. Użyj stabilnego key jak seats, api_calls czy sso_enabled. type upraszcza ewaluację (np. flag, limit, quota). Przechowuj unit jawnie (np. users, requests, GB). Dla kwot trzymaj reset_policy jednoznacznie (np. monthly, daily, never).

Nadpisania powinny zachowywać się jak allowlist z datami. Jeśli klient ma aktywne nadpisanie sso_enabled=true, to powinno ono mieć pierwszeństwo przed wartością z planu, ale tylko w ramach effective_from i effective_to. To właśnie sprawia, że „przyznaj 10 dodatkowych miejsc na 14 dni” to jedna zmiana w tabeli, która wygasa automatycznie.

Jak powinna działać ewaluacja uprawnień

Ewaluacja uprawnień to mały fragment kodu (lub usługa), który odpowiada na jedno pytanie: „Czy ten klient może to zrobić teraz?” Jeśli ta część jest przewidywalna, wszystko inne jest prostsze w obsłudze.

Użyj jasnej kolejności priorytetów i jej nie zmieniaj: nadpisanie klienta > wartość planu > domyślna wartość systemu. To pozwala wsparciu przyznawać tymczasowe wyjątki bez zmiany planu i daje inżynierii bezpieczne domyślne ustawienia, gdy nic nie jest skonfigurowane.

Praktyczny flow ewaluacji:

• Zidentyfikuj klienta/konto z uwierzytelnionej sesji (nie z ciała żądania).
• Załaduj aktywny plan klienta i aktywne nadpisania.
• Dla danego klucza zwróć nadpisanie, jeśli istnieje; inaczej zwróć wartość planu; inaczej zwróć domyślną wartość systemu.
• Jeśli klucz nie występuje nigdzie, bezpiecznie zabroń dostępu dla sprawdzeń egzekucyjnych i użyj sensownej wartości domyślnej dla elementów tylko do wyświetlania w UI.
• Jeśli klucz jest nieznany (nie ma go w rejestrze), traktuj to jako błąd konfiguracji, zabroń dostępu i zaloguj problem do dalszego sprawdzenia.

Caching ma znaczenie, bo uprawnienia są sprawdzane bardzo często. Cache’uj rozstrzygnięte uprawnienia per klient z krótkim TTL i wyraźnym numerem wersji. Unieważniaj cache, gdy zmieni się: przypisanie planu, definicja planu, nadpisania klienta lub status klienta (trial, grace, blocked). Prosty wzorzec to „cache według customer_id + entitlements_version”, gdzie edycje supportu zwiększają wersję, by zmiany pojawiły się szybko.

Bezpieczeństwo multi-tenant jest niezbędne. Każde zapytanie musi filtrować po bieżącym customer/account id, a każdy wpis w cache musi być kluczowany tym id. Nie wyszukuj uprawnień po emailu, domenie ani samej nazwie planu.

Krok po kroku: przyjazny dla wsparcia workflow do zmiany dostępu

Przyjazny workflow dla wsparcia utrzymuje model elastyczny, nie zamieniając każdego przypadku brzegowego w zadanie inżynieryjne. Celem jest bezpieczna zmiana, zostawienie śladu i potwierdzenie doświadczenia klienta.

Bezpieczny flow dla wsparcia

Zacznij od odnalezienia właściwego rekordu klienta i potwierdzenia, o co proszą i dlaczego. „Potrzebujemy dwóch dodatkowych miejsc na tydzień” różni się od „podpisaliśmy aneks na wyższy tier”. Dobre narzędzie admina pozwala w jednym miejscu zobaczyć aktualny plan, status klienta i aktywne nadpisania.

Zanim coś zmienisz, sprawdź rzeczywiste użycie względem bieżącego limitu lub kwoty. Wiele próśb znika, gdy widać, że konto nie osiągnęło limitu lub problem leży gdzie indziej (np. śledzenie użycia nie aktualizuje się).

Gdy trzeba dostosować dostęp, preferuj explicite nadpisanie zamiast edycji planu. Trzymaj nadpisania wąskie (jedna flaga lub jeden limit), dodaj właściciela i powód oraz domyślnie ustaw datę wygaśnięcia. Tymczasowe wyjątki są powszechne i łatwo o nich zapomnieć.

Prosta checklista w narzędziu admina zwykle wystarczy:

• Potwierdź tożsamość klienta, aktualny plan i powód prośby.
• Przejrzyj bieżące użycie vs odpowiedni limit.
• Zastosuj ograniczone nadpisanie i ustaw termin wygaśnięcia.
• Dodaj notatki oraz referencję do ticketu lub sprawy.
• Zweryfikuj rezultat w UI produktu, używając impersonacji lub konta testowego.

Zawsze weryfikuj zmianę tak, jak zobaczy ją klient. Jeśli wspierasz impersonację, jasno pokaż, kiedy jest włączona i loguj jej użycie.

Ulepszenia, degradacje, triale i okresy karencji

Większość problemów z uprawnieniami pojawia się przy zmianach: klient uaktualnia konto w połowie okresu rozliczeniowego, karta płatnicza nie przechodzi, albo trial kończy się w weekend. Jeśli reguły są niejasne, wsparcie zaczyna zgadywać, a inżynieria zostaje wciągnięta.

Dla upgrade’ów trzymaj to prosto: dostęp powinien zwykle zmienić się natychmiast, natomiast rozliczenia zostaw systemowi billingowemu. Twój model uprawnień powinien nasłuchiwać zdarzenia billingowego typu „plan changed” i zastosować nowe uprawnienia planu od razu. Jeśli billing robi prorację — OK, ale nie mieszaj obliczeń proracji w logice uprawnień.

Downgrady to miejsce, gdzie pojawiają się niespodzianki. Wybierz jasne zachowanie przy degradowaniu i udostępnij je wsparciu:

• Okres karencji: utrzymuj wyższy dostęp do końca opłaconego terminu.
• Tryb tylko do odczytu: pozwól na podgląd/eksport danych, blokując nowe zapisy.
• Natychmiastowe zablokowanie: blokuj funkcję od razu (zalecane dla ryzykownych funkcji).
• Zachowanie przy przekroczeniu limitu: zezwól na używanie, ale blokuj tworzenie nowych zasobów, gdy klient jest powyżej limitu.
• Przechowywanie danych: zachowaj dane, ale zablokuj dostęp do nich aż do upgrade’u.

Triale działają najlepiej jako osobny plan, a nie boolean na rekordzie klienta. Daj trialowi jawne flagi i limity oraz regułę auto-wygaśnięcia. Po zakończeniu triala przenieś klienta na domyślny plan (często „Free”) i zastosuj zdefiniowane zachowanie downgrade’u.

Okresy karencji są też przydatne przy problemach z rozliczeniami. Krótki okres „po terminie” (np. 3–7 dni) daje czas na naprawę płatności bez utraty dostępu w środku dnia pracy. Traktuj okres karencji jako nadpisanie ograniczone czasowo, a nie niestandardową nazwę planu.

Praktyczna wskazówka: nie wiąż uprawnień z marketingowymi nazwami tierów jak „Pro” czy „Enterprise”. Utrzymuj stabilne wewnętrzne identyfikatory planów (np. plan_basic_v2), żeby móc zmieniać nazwy poziomów bez łamania reguł.

Audytowalność i kontrole bezpieczeństwa

Jeśli wsparcie może zmieniać dostęp bez inżynierii, potrzebujesz śladu. Dobry model uprawnień traktuje każdą zmianę jako zarejestrowaną decyzję, a nie cichą modyfikację.

Dla każdego nadpisania rejestruj aktora, powód biznesowy i znaczniki czasu. Jeśli organizacja tego wymaga, dodaj krok zatwierdzania dla wrażliwych zmian.

Co zapisywać przy każdej zmianie

Trzymaj log prosty, żeby był używany:

• created_by i created_at
• approved_by i approved_at (opcjonalne)
• reason (krótki tekst jak „paid add-on” lub „incident credit”)
• previous_value i new_value
• expires_at

Kontrole bezpieczeństwa zapobiegają wpadkom przed wdrożeniem do produkcji. Wprowadź zabezpieczenia w UI administracyjnym i w bazie: ogranicz maksymalne wartości, blokuj liczby ujemne i wymuszaj datę wygaśnięcia przy dużych zmianach (np. podniesienie limitu API 10x).

Cofanie zmian i gotowość do audytu

Wsparcie popełni błędy. Daj im jedną akcję „przywróć do domyślnych ustawień planu”, która czyści nadpisania na poziomie klienta i przywraca konto do przypisanego planu.

Dla audytów uprość eksport historii według klienta i zakresu dat. Podstawowy eksport CSV z powodem i zatwierdzającym odpowiada na większość pytań bez angażowania inżynierii.

Przykład: klient na „Pro” potrzebuje 30 dodatkowych miejsc na tydzień. Wsparcie ustawia seats_override=60 z expires_at w następny piątek, dodaje powód „event” i uzyskuje akceptację menedżera. Po wygaśnięciu nadpisanie przestaje działać, system wraca do 30, a pełna ścieżka jest dostępna w razie sporu z billingiem.

Częste błędy, które utrudniają pracę z uprawnieniami

Najszybszy sposób na zepsucie modelu uprawnień to pozwolić mu rosnąć przypadkowo. Kilka wczesnych skrótów potrafi zamienić się w miesiące ticketów i pytania „dlaczego ten klient może to robić?”.

Jednym z częstych problemów jest rozrzucanie sprawdzeń funkcji wszędzie. Jeśli różne części aplikacji decydują o dostępie różnymi sposobami, będziecie wdrażać sprzeczności. Zcentralizuj ewaluację uprawnień za jedną funkcją lub usługą i spraw, by każdy UI i każde API z niej korzystało.

Inna pułapka to mieszanie stanu billingowego z dostępem. „Paid” to nie to samo co „dozwolone”. Billing ma retry, chargebacki, triale i rozliczenia, które rozliczają się później. Trzymaj zdarzenia billingowe oddzielnie i tłumacz je na uprawnienia z jasnymi regułami (w tym okresami karencji), żeby edge case’y nie blokowały użytkowników ani nie wpuszczały ich na stałe.

Unikaj polegania tylko na jednym stringu „tier” jak „basic” czy „pro” jako jedynym źródle prawdy. Tiers zmieniają się w czasie, pojawiają się wyjątki. Przechowuj jawne flagi i limity, żeby support mógł przyznać jedną zdolność bez przypadkowego przyznawania wszystkiego, co niesie ze sobą etykieta tieru.

Nadpisania manualne są konieczne, ale nieograniczone nadpisania bez zasad stają się długiem technicznym. Wymagaj właściciela, powodu i referencji do ticketu. Zachęcaj do dat wygaśnięcia lub dat przeglądu. Trzymaj nadpisania wąskie (jeden klucz na raz) i ułatwiaj ich audyt.

Kwoty również psują się, gdy reguły resetu są niejasne. Zdefiniuj co oznacza „na miesiąc” (miesiąc kalendarzowy vs 30 dni kroczących), co się dzieje przy upgrade’cie i czy niewykorzystana kwota przepada. Wymuszaj te reguły w logice backendu, nie tylko w UI, aby zmiany wsparcia nie tworzyły niespójnego zachowania między web a mobile.

Szybka lista kontrolna przed wdrożeniem

Zanim wypuścisz model uprawnień, zrób ostatnie przejście z ludźmi, którzy będą go używać na co dzień: wsparciem, success i on-call.

Upewnij się, że każda funkcja mapuje się na jeden stabilny klucz uprawnienia z jasnym właścicielem. Unikaj duplikatów jak reports_enabled vs reporting_enabled. Upewnij się, że każdy plan ma jawne domyślne wartości dla kluczy, które wprowadzasz. Jeśli klucz jest nieobecny, zachowaj bezpieczne zachowanie (zwykle zabroń dostępu) i zgłoś wewnętrzny alert, żeby to naprawić.

Dla operacji potwierdź, że workflow jest faktycznie użyteczny:

• Wsparcie może zobaczyć efektywny dostęp (domyślny plan plus nadpisanie) bez SQL.
• Nadpisania są logowane z informacją kto zmienił co, dlaczego i kiedy to wygasa.
• Kwoty mają widoczną regułę resetu i jasny sposób pokazania bieżącego użycia.

Test rzeczywistości: poproś wsparcie, żeby przyznało klientowi dodatek na 14 dni, a potem je usunęło. Jeśli mogą to zrobić pewnie w mniej niż dwie minuty, jesteś blisko.

Przykładowy scenariusz: poziomy z tymczasowym wyjątkiem

Wyobraź sobie, że oferujesz trzy poziomy i każdy ustawia kilka jasnych uprawnień, które pojawiają się w produkcie i są egzekwowane na backendzie.

• Free: 1 projekt, 3 użytkowników, 200 eksportów/miesiąc, podstawowy limit API, 7-dniowe logi audytu.
• Team: 10 projektów, 25 użytkowników, 2 000 eksportów/miesiąc, wyższy limit API, 30-dniowe logi audytu.
• Business: nieograniczone projekty, 200 użytkowników, 10 000 eksportów/miesiąc, najwyższy limit API, 180-dniowe logi audytu, SSO włączone.

Teraz klient Team mówi: „Mamy koniec kwartału i potrzebujemy 8 000 eksportów w tym miesiącu. Możecie pomóc przez 30 dni?” To dokładnie sytuacja, gdzie tymczasowe nadpisanie jest lepsze niż przenoszenie ich na inny plan.

Wsparcie otwiera rekord klienta, dodaje nadpisanie export_monthly_limit = 8000 i ustawia expires_at na 30 dni od dziś. Dodają notatkę: „Zatwierdzone przez Alex (Sales), 30-dniowy wyjątek na raportowanie Q4.”

Po stronie klienta powinny się wydarzyć dwie rzeczy:

• UI odzwierciedla nowy limit (np. pasek użycia i etykieta „Pozostałe eksporty” się aktualizują).
• Eksporty działają do momentu osiągnięcia 8 000 w miesiącu.

Jeśli przekroczą limit, zobaczą jasny komunikat: „Osiągnięto limit eksportów (8 000/miesiąc). Skontaktuj się z supportem lub uaktualnij plan, aby zwiększyć limit.”

Po dacie wygaśnięcia nadpisanie przestaje działać automatycznie, a klient wraca do limitu Team bez konieczności ręcznego wyłączania.

Następne kroki: implementuj i iteruj bez hamowania wsparcia

Zacznij od zamiany „funkcji” na mały katalog uprawnień. Nadaj każdemu elementowi jasny klucz, typ (flaga vs limit vs kwota) i domyślną wartość dla każdego planu. Ten katalog staje się wspólnym językiem między produktem, wsparciem i inżynierią — trzymaj nazwy konkretne i stabilne.

Zdecyduj, gdzie odbywa się egzekwowanie. Bezpieczna zasada: egzekwuj w API wszystko, co zmienia dane lub generuje koszty, używaj jobów w tle do zatrzymywania długotrwałej pracy przy przekroczeniach, a UI traktuj jako wskazówkę (wyłączone przyciski, pomocne komunikaty), ale nie jedyny mechanizm blokujący.

Trzymaj pierwszą wersję zwartą. Skup się na uprawnieniach, które generują najwięcej pytań, dodaj sprawdzenia do akcji o najwyższym ryzyku i wypuść widok admina pokazujący klienta, plan, nadpisania i historię w jednym miejscu.

Jeśli chcesz szybko zbudować panel administracyjny i logikę bez ręcznego kodowania, AppMaster (appmaster.io) jest praktycznym wyborem do tego typu prac: możesz modelować plany i nadpisania jako dane, implementować checki jako procesy biznesowe i wypuścić UI wsparcia, który pozostaje spójny między backendem a aplikacjami.