Jurnal de activitate zilnic

A1Arhitectură: unde se află în platformă

Jurnal de activitate zilnic is a first-class module of the Productivitatea și starea de bine a recrutorilor suite inside the authenticated Expertini ATS workspace. Platforma este randată în mod deliberat pe server: fiecare vizualizare este pregătită de serverul de aplicații și livrată sub formă de HTML complet, fără cadru la nivelul clientului, fără scripturi CDN terțe și fără un flux de compilare între date și pagină. Ceea ce se randează este ceea ce a calculat serverul — proprietatea care face interfața auditată.

Toată persistența rulează pe un singur magazin de documente nativ de căutare; fiecare interogare poartă identificatorul organizației ca filtru obligatoriu la cel mai de jos nivel de interogare. Prin urmare, izolareantenanților este structurală — o proprietate a modului în care este compusă fiecare cerere —, și nu o politică bazată pe faptul că codul aplicației își amintește să facă o verificare.

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 de date și hartă de dependență

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.

Fiecare post deschis distinct este înregistrat în jurnalul de activitate al instrumentului — iar acest jurnal, nu un sistem de analize paralel, este ceea ce agregează secțiunea de rapoarte. Numerele de utilizare pe care le vedeți sunt numerele pe care platforma le-a înregistrat efectiv.

Tot ceea ce părăsește fluxul de cereri — distribuirea notificărilor, livrarea webhook-urilor, jurnalele de activitate, e-mailul — rulează în fire de fundal de tip „execută și uită”. Un punct final extern lent nu poate face niciodată interfața să se blocheze, iar un efect secundar eșuat este înregistrat în jurnal în loc să fie reîncercat în mod silențios până la apariția unei inconsistențe.

A3Considerente operaționale

Setările la nivel de organizație, acțiunile distructive și conexiunile sunt restricționate la rolurile de proprietar și administrator; recruiterii operează instrumentul pe înregistrările pe care le pot vedea. Modificările de rol se aplică la următoarea solicitare — aplicarea se face la nivel de rută, nu în meniu.

Eșecurile sunt afișate la suprafață, nu ascunse: validarea pe partea de server returnează câmpul exact și motivul, erorile furnizorilor sunt citate textual acolo unde sunt implicate integrări, iar fiecare scriere fie se confirmă, fie raportează. Exporturile se regenerează la cerere în loc să fie stocate în cache — un raport pe care îl descărcați reflectă starea bazei de date din momentul în care l-ați solicitat, nu instantaneul de aseară.

Tot ceea ce este scris vă aparține pentru a fi preluat: exporturile CSV și aplicația de export a datelor Data Export acoperă aceleași magazine pe care le citește produsul în sine. Ieșirea este la fel de deschisă ca și intrarea — prin design, nu prin concesie.

A4Interaction contract

Interfața urmează convenția de căutare și selectare a platformei: orice câmp care numește o înregistrare reală — un candidat, un client sau un post — este un selector de tip „scrie pentru a căuta” peste date live, niciodată un text scris liber, ceea ce menține pistele de activitate și deduplicarea de încredere. Alegerile statice sunt combinații de filtrare pe măsură ce tastați, în loc de meniuri native, iar tranzițiile de stare oferă feedback explicit: confirmările de server apar ca notificări toast, erorile de validare numesc câmpul exact și nimic nu este afișat ca fiind finalizat dacă serverul nu a confirmat.

Schema și fluxul de mai jos documentează contractul structural al interfeței — ce panouri există, în ce ordine apar stările și ce se întâmplă la fiecare margine — mai degrabă decât pixelii. Layout-ul este compus utilizând grila CSS nativă și flexbox și se adaptează de la ecrane desktop late la o singură coloană fără a necesita vizualizări mobile separate.