Candidate Alerts

A1Architecture: where it sits in the platform

Candidate Alerts is a first-class module of the Sourcing & Job Ads suite inside the authenticated Expertini ATS workspace. The platform is deliberately server-rendered: every view is prepared by the application server and shipped as complete HTML, with no client-side framework, no third-party CDN scripts, and no build pipeline between the data and the page. What renders is what the server computed — the property that makes the interface auditable.

All persistence runs on a single search-native document store; every query carries the organisation's identifier as a mandatory filter at the lowest query layer. Tenant isolation is therefore structural — a property of how every request is composed — rather than a policy that relies on application code remembering to check.

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

A2Data model and dependency map

In production the tool reads and writes ats_candidate_alerts. 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.

Every distinct open is journalled to the tool-activity store — and that journal, not a parallel analytics system, is what the Reports section aggregates. The usage numbers you see are the numbers the platform actually recorded.

Anything that leaves the request path — notification fan-out, webhook delivery, activity journalling, mail — runs in fire-and-forget background threads. A slow external endpoint can never make the interface hang, and a failed side effect is logged rather than silently retried into inconsistency.

A3Operational considerations

Organisation-level settings, destructive actions, and connections are gated to owner and admin roles; recruiters operate the tool on the records they can see. Role changes apply on the next request — enforcement is at the route, not in the menu.

Failures are surfaced, not swallowed: server-side validation returns the exact field and reason, vendor errors are quoted verbatim where integrations are involved, and every write either confirms or reports. Exports regenerate on request rather than being cached — a report you download reflects the store at the moment you asked, not last night's snapshot.

Everything written is yours to take: CSV exports and the Data Export app cover the same stores the product itself reads. The exit is as open as the entrance — by design, not concession.

A4Interaction contract

The interface follows the platform's search-and-select convention: any field that names a real record — a candidate, client, or job — is a type-to-search picker over live data, never a free-typed string, which is what keeps activity trails and deduplication trustworthy. Static choices are filter-as-you-type combos rather than native dropdowns, and state transitions give explicit feedback: server confirmations surface as toasts, validation errors name the exact field, and nothing is shown as done that the server has not confirmed.

The wireframe and flow below document the structural contract of the surface — what panels exist, what order the states occur in, and what happens at every edge — rather than pixels. The layout is composed with native CSS grid and flexbox and adapts from wide desktop to a single column without separate mobile views.