Воронка кандидатів

A1Архітектура: де вона розташована на платформі

Воронка кандидатів is a first-class module of the Воронка та керування клієнтами suite inside the authenticated Expertini ATS workspace. Платформа навмисно рендериться на сервері: кожне представлення готується сервером додатків і надсилається як повний HTML, без клієнтського фреймворку, без сторонніх сценаріїв CDN і без конвеєра збірки між даними та сторінкою. Відображається те, що обчислив сервер — властивість, яка робить інтерфейс доступним для аудиту.

Усе збереження даних працює на єдиному пошуковому сховищі документів; кожен запит містить ідентифікатор організації як обов'язковий фільтр на найнижчому шарі запитів. Тому ізоляція орендарів є структурною — властивістю того, як складається кожен запит, а не політикою, яка покладається на те, що код додатку не забуде виконати перевірку.

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

A2Модель даних та карта залежностей

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

Кожне унікальне відкриття реєструється в сховищі активності інструменту — і саме цей журнал, а не паралельна аналітична система, агрегується в розділі «Звіти». Цифри використання, які ви бачите, є тими цифрами, які платформа фактично зафіксувала.

Усе, що виходить за межі шляху запиту — розсилка сповіщень, доставка вебхуків, ведення журналу активності, пошта — виконується у фонових потоках за принципом «надіслав і забув». Повільна зовнішня кінцева точка ніколи не призведе до зависання інтерфейсу, а помилковий побічний ефект реєструється, а не повторюється мовчки до виникнення суперечливості.

A3Операційні міркування

Налаштування на рівні організації, деструктивні дії та підключення обмежені ролями власника та адміністратора; рекрутери керують інструментом на основі записів, які вони можуть бачити. Зміни ролей застосовуються з наступним запитом — забезпечення виконання відбувається на рівні маршруту, а не в меню.

Помилки виводяться на поверхню, а не приховуються: перевірка на стороні сервера повертає точне поле і причину, помилки постачальника цитуються дослівно, якщо задіяні інтеграції, і кожен запис або підтверджує, або повідомляє. Експорти генеруються за запитом, а не кешуються — звіт, який ви завантажуєте, відображає сховище на момент вашого запиту, а не знімок минулої ночі.

Усе написане належить вам: експорт у форматі CSV та застосунок Експорт даних охоплюють ті самі сховища, які читає сам продукт. Вихід відкритий так само, як і вхід — за задумом, а не як поступка.

A4Interaction contract

Інтерфейс відповідає конвенції платформи «пошук і вибір»: будь-яке поле, що називає реальний запис — кандидата, клієнта чи вакансію — є селектором типу «введіть для пошуку» поверх живих даних, а не рядком, що вводиться вручну, що й робить траєкторії активності та дедуплікацію надійними. Статичні вибори є випадаючими списки фільтрації під час введення, а переходи станів дають чіткий зворотний зв'язок: підтвердження сервера з'являються у вигляді спливаючих вікон (toast), помилки валідації вказують на точне поле, і нічого не відображається як виконане, чого сервер не підтвердив.

Вайрфрейм та потік нижче документують структурний контракт поверхні — які панелі існують, у якому порядку відбуваються стани та що відбувається на кожному краї — а не пікселі. Макет створено за допомогою нативних CSS grid і flexbox, він адаптується від широкого десктопа до єдиної колонки без окремих мобільних видів.