Journal for intervjuspørsmål

A1Arkitektur: plassering i plattformen

Journal for intervjuspørsmål is a first-class module of the Interviewing suite inside the authenticated Expertini ATS workspace. Plattformen er bevisst serverrendret: hver visning klargjøres av applikasjonsserveren og leveres som komplett HTML, uten klientside-rammeverk, uten tredjeparts CDN-skript og uten byggprosesser mellom dataene og siden. Det som gjengis er det serveren beregnet – egenskapen som gjør grensesnittet revisjonsklart.

All datalagring kjører på et felles søkeoptimalisert dokumentlager; hver spørring bærer organisasjonens identifikator som et obligatorisk filter på det laveste spørringslaget. Leietakerisolasjon er derfor strukturell — en egenskap ved hvordan hver forespørsel er bygget opp — snarere enn en regel som avhenger av at applikasjonskoden husker å sjekke.

Availability is governed by the platform's tool registry: this tool is registered from the Professional 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.

A2Datamodell og avhengighetskart

In production the tool reads and writes job requisitions (ats_jobs). 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.

Hver enkelt åpning loggføres i verktøyaktivitetslageret – og denne loggen, ikke et parallelt analysesystem, er det rapportseksjonen aggregerer. Brukstallene De ser, er tallene plattformen faktisk registrerte.

Alt som forlater forespørselsbanen — varslingsdistribusjon, levering av webhooks, aktivitetsjournalføring, e-post — kjører i bakgrunnstråder uten blokkering (fire-and-forget). Et tregt eksternt endepunkt kan aldri føre til at grensesnittet henger, og en mislykket sideeffekt logges i stedet for å bli forsøkt på nytt i det stille og skape inkonsistens.

A3Operasjonelle hensyn

Innstillinger på organisasjonsnivå, destruktive handlinger og tilkoblinger er begrenset til eier- og administratorroller; rekrutterere bruker verktøyet på postene de kan se. Rolleendringer trer i kraft ved neste forespørsel – håndheving skjer på rutenivå, ikke i menyen.

Feil synliggjøres, ikke svelges: validering på serversiden returnerer det nøyaktige feltet og årsaken, leverandørfeil siteres ordrett der integrasjoner er involvert, og enhver skriving enten bekrefter eller rapporterer. Eksporter regenereres på forespørsel i stedet for å bufres — en rapport du laster ned gjenspeiler datalageret i det øyeblikket du ba om den, ikke et øyeblikksbilde fra i går kveld.

Alt som er registrert er ditt til odel og eie: CSV-eksporter og appen Data Export dekker de samme datalagrene som selve produktet leser fra. Utgangen er like åpen som inngangen – etter hensikt, ikke som en innrømmelse.

A4Interaction contract

Grensesnittet følger plattformens konvensjon for søk og valg: ethvert felt som refererer til en faktisk oppføring — en kandidat, kunde eller stilling — er en søk-mens-du-skriver-velger mot sanntidsdata, aldri en fritekststreng. Dette sikrer at aktivitetshistorikk og duplikatkontroll forblir pålitelige. Statiske valg er filtrer-mens-du-skriver-kombinasjonsbokser fremfor integrerte rullegardinmenyer, og tilstandsendringer gir eksplisitt tilbakemelding: serverbekreftelser vises som varsler, valideringsfeil angir det nøyaktige feltet, og ingenting vises som fullført før serveren har bekreftet det.

Trådskissen og flyten nedenfor dokumenterer flatens strukturelle kontrakt — hvilke paneler som finnes, hvilken rekkefølge tilstandene opptrer i, og hva som skjer ved hver overgang — snarere enn piksler. Oppsettet er bygget med opprinnelig CSS grid og flexbox og tilpasser seg fra bred skjerm til en enkelt kolonne uten separate mobilvisninger.