Dzienny rejestr aktywności

A1Architektura: umiejscowienie w platformie

Dzienny rejestr aktywności is a first-class module of the Wydajność i dobrostan rekrutera suite inside the authenticated Expertini ATS workspace. Platforma jest celowo renderowana po stronie serwera: każdy widok jest przygotowywany przez serwer aplikacji i przesyłany jako kompletny kod HTML, bez frameworka po stronie klienta, bez skryptów CDN podmiotów trzecich i bez potoku budowania między danymi a stroną. To, co się wyświetla, jest dokładnie tym, co obliczył serwer — cecha ta zapewnia pełną audytowalność interfejsu.

Cała trwałość danych opiera się na pojedynczym magazynie dokumentów zoptymalizowanym pod kątem wyszukiwania; każde zapytanie zawiera identyfikator organizacji jako obowiązkowy filtr na najniższej warstwie zapytań. Izolacja dzierżawców ma zatem charakter strukturalny — wynika ze sposobu tworzenia każdego żądania — a nie z polityki polegającej na pamiętaniu o sprawdzeniu tego w kodzie aplikacji.

Availability is governed by the platform's tool registry: this tool is registered from the Starter plan, and access is enforced server-side by the registry gate on every request — never by hiding a button. Plans also carry a monthly distinct-tool quota (3 / 5 / 15 / 30 / 45 across Trial→Business, unlimited on Enterprise), counted at the same chokepoint. The pricing page states both honestly: what is available, and how much of it the month includes.

A2Model danych i mapa zależności

In production the tool reads and writes ats_planner_logs, job requisitions (ats_jobs), pipeline applications (ats_applications). Documents are plain, explicitly-mapped fields — mappings are provisioned ahead of first write, so term filters and aggregations behave deterministically instead of depending on inferred types.

Każde pojedyncze otwarcie jest rejestrowane w dzienniku aktywności narzędzia — i to właśnie ten dziennik, a nie równoległy system analityczny, jest agregowany w sekcji Raporty. Widoczne liczby dotyczące użytkowania są dokładnie tymi wartościami, które zarejestrowała platforma.

Wszystko, co wykracza poza ścieżkę żądania — rozsyłanie powiadomień, dostarczanie webhooków, rejestrowanie aktywności, poczta e-mail — działa w wątkach tła typu fire-and-forget. Wolny zewnętrzny punkt końcowy nigdy nie zawiesi interfejsu, a nieudana operacja poboczna jest rejestrowana w dzienniku, zamiast być po cichu ponawiana aż do wystąpienia niespójności.

A3Kwestie operacyjne

Ustawienia na poziomie organizacji, działania destrukcyjne oraz połączenia są ograniczone do ról właściciela i administratora; rekruterzy obsługują narzędzie na rekordach, do których mają dostęp. Zmiany ról obowiązują od następnego żądania — egzekwowanie odbywa się na poziomie ścieżki routingu, a nie w menu.

Błędy są ujawniane, a nie wyciszane: walidacja po stronie serwera zwraca dokładne pole i przyczynę, błędy dostawców są cytowane dosłownie w przypadku integracji, a każdy zapis jest potwierdzany lub zgłaszany. Eksporty są generowane ponownie na żądanie, a nie buforowane — pobierany raport odzwierciedla stan bazy danych w momencie zapytania, a nie migawkę z poprzedniej nocy.

Wszystkie zapisane dane należą do Państwa: eksporty CSV oraz aplikacja Data Export obejmują te same zasoby, z których korzysta sam produkt. Wyjście jest tak samo otwarte jak wejście — z założenia, a nie z konieczności.

A4Interaction contract

Interfejs jest zgodny z konwencją wyszukiwania i wyboru platformy: każde pole wskazujące na rzeczywisty rekord — kandydata, klienta lub ofertę pracy — to pole wyboru z funkcją wyszukiwania podczas wpisywania na danych na żywo, a nie pole tekstowe, co zapewnia wiarygodność ścieżek aktywności i deduplikacji. Wybory statyczne to pola kombi z filtrowaniem podczas wpisywania, a nie natywne listy rozwijane, natomiast przejścia między stanami zapewniają jednoznaczne informacje zwrotne: potwierdzenia serwera pojawiają się jako powiadomienia toast, błędy walidacji precyzyjnie wskazują pole, a żaden element nie jest oznaczany jako ukończony bez potwierdzenia przez serwer.

Poniższa makieta i schemat przepływu dokumentują układ strukturalny interfejsu — istniejące panele, kolejność stanów oraz zachowanie na każdym etapie — a nie dokładny wygląd w pikselach. Układ został zbudowany przy użyciu natywnych technologii CSS grid i flexbox i dostosowuje się od szerokich ekranów komputerów stacjonarnych do pojedynczej kolumny bez konieczności tworzenia osobnych widoków mobilnych.