Automation Rules в AcademyOcean: розподіл у команди та інше
Automation Rules в AcademyOcean: команди оновлюються за заданими правилами
Нові працівники реєструються в академії, у профілях уже вказані їхні посади, відділи й міста, але адміністратор усе одно вручно додає кожного до потрібної команди. Що більшою стає база учнів, то частіше доводиться повертатися до однієї й тієї самої операції: перевірити властивості профілю, знайти правильну команду та оновити її склад.
Automation Rules перетворюють цю повторювану роботу на правило. Адміністратор задає умови за властивостями учня, визначає команди для призначення, перевіряє майбутній результат у прев'ю та активує автоматизацію. Після цього виконання правила можна відстежувати в журналі активності, а зміни його налаштувань — в окремому журналі аудиту.
Розповідаємо, як працюють Automation Rules та де вони допомагають HR- і L&D-командам прибрати ручне сортування учнів.
Що Automation Rules змінюють у роботі адміністратора
Замість того щоб щоразу переглядати профілі й вручну підтримувати актуальний склад команд, адміністратор один раз описує логіку розподілу. Наприклад, працівників служби підтримки з Києва потрібно додавати до команди, для якої підготовлено відповідний онбординг. Якщо роль і місто вже збережені у властивостях профілю, вони можуть стати умовами правила.
Новий розділ Automation розташований у Academy Settings. На його головній сторінці зібрані створені правила, пошук за назвою та вкладки All, Active й Inactive. У таблиці адміністратор бачить умови, дію, кількість оброблених учнів і дату останнього спрацювання. Так простіше зрозуміти не лише те, які правила налаштовані, а й те, чи використовуються вони на практиці.
Як працює правило «Коли → Тоді»
Кожне правило складається з тригера та дії. У частині «Коли» адміністратор обирає властивість учня, оператор і потрібне значення. У частині «Тоді» вказують одну або кілька команд, до яких треба призначити учня. Зберегти правило можна лише тоді, коли в ньому є щонайменше одна умова та дія.
Розглянемо сценарій: потрібно автоматично збирати працівників служби підтримки з Києва в окрему онбординг-команду. Правило перевіряє, чи має поле «Посада» значення «Customer Support» і чи вказано в полі «Місто» значення «Київ». Якщо обидві умови виконані, дія Assign to team(s) призначає учня до вибраної команди.
Важлива деталь: кілька умов усередині одного правила працюють за логікою «І». Це означає, що учень має відповідати всім заданим критеріям одночасно.
Чим більше умов додає адміністратор, тим вужчою зазвичай стає відповідна група. У стартовій версії до одного правила можна додати до 50 умов, але дія поки одна — призначення до команди або кількох команд.
Властивості учнів стають умовами автоматизації
Automation Rules використовують системні та кастомні властивості профілю. Це можуть бути вже наявні дані, за якими компанія сегментує людей: посада, відділ, локація або інша змінна, створена під власну структуру.
Для порівняння властивості доступні оператори is, is not та is unknown. Перший знаходить учнів із конкретним значенням, другий — профілі, де значення відрізняється, а третій — профілі без заповненого параметра. Наприклад, is unknown допомагає окремо побачити людей, яким не можна коректно призначити команду, доки в профілі не вказано потрібний відділ або місто.
Це не означає, що система визначає причину відсутніх даних або виправляє їх автоматично. Правило лише працює з тим, що збережено у профілях.
Тому перед запуском важливо перевірити назви й значення властивостей, особливо якщо їх заповнюють різні адміністратори або передають через інтеграцію.
Перевірка до запуску: хто потрапить під правило
Автоматизація не повинна бути «чорною скринькою». Поруч із кнопкою збереження відображається кількість учнів, які відповідають налаштованим умовам, а кнопка Preview відкриває таблицю з конкретними профілями. У ній можна перевірити ім'я, електронну адресу, місто, країну, дату реєстрації та інші доступні дані.
Прев'ю доступне лише для перегляду: воно показує майбутній результат, але не змінює профілі. Якщо у вибірку потрапили не ті люди, адміністратор може повернутися до редактора, уточнити умови й перевірити результат ще раз. Це особливо корисно для правил із кількома параметрами, де одне надто широке значення може охопити більше учнів, ніж очікувалося.
Після збереження правило може залишатися Inactive або працювати зі статусом Active. Такий підхід дає змогу підготувати логіку заздалегідь і ввімкнути її тоді, коли команда готова до автоматичного призначення.
Коли активне правило спрацьовує
Активне правило виконується не лише під час першого налаштування. У поточній версії є п'ять моментів запуску:
- коли нове правило зберігають зі статусом Active;
- коли наявне правило переводять зі статусу Inactive в Active;
- кожні 30 хвилин для активних правил;
- після завершення учнем Welcome Pop-up;
- під час реєстрації нового учня.
Після редагування активного правила та збереження змін система також повторно перевіряє відповідність учнів умовам і оновлює призначення до команд. Водночас це не варто описувати як миттєву реакцію на будь-яку зміну профілю: підтверджений регулярний цикл перевірки становить 30 хвилин, окрім перелічених подій.
Правило призначає відповідних учнів до вибраних команд. Стартова версія не підтверджує автоматичного видалення людей із команд, тому для таких сценаріїв потрібен окремий контроль адміністратора.
Два журнали для різних питань
Після запуску важливо розуміти і те, що зробила автоматизація, і те, хто змінював її налаштування. Для цього доступні два окремі журнали.
Activity Log: кого обробило правило
Журнал активності показує учнів, для яких виконувалося правило, застосовані умови й дію, а також час останнього спрацювання. Якщо автоматизація кілька разів обробляє одного учня, кожне виконання відображається окремим записом. Нові події розташовуються зверху, а для довгого журналу доступна пагінація.
Цей журнал відповідає на практичне запитання адміністратора: «До кого й коли застосовувалося правило?». Якщо склад команди виглядає не так, як очікувалося, записи допомагають перевірити сам факт виконання, але не пояснюють причину невідповідних даних у профілі.
Audit Log: хто змінював налаштування
Журнал аудиту фіксує адміністративні зміни правила та дає змогу переглянути технічні дані до і після редагування. Він потрібен для іншого запитання: «Хто змінив логіку і що саме було змінено?».
Розділення журналів прибирає плутанину між результатом роботи правила та історією його конфігурації. Activity Log допомагає перевіряти оброблених учнів, тоді як Audit Log — відновити послідовність дій адміністраторів.
Практичні сценарії для HR та L&D
Перший сценарій — онбординг за посадою або відділом. Новий працівник реєструється, завершує Welcome Pop-up, а активне правило перевіряє властивості профілю й додає його до команди з відповідною програмою навчання. HR не потрібно щоразу вручну переносити дані з профілю в структуру команд.
Другий сценарій — розподілена компанія з кількома локаціями. Якщо матеріали або процеси відрізняються за містом чи країною, властивість локації можна поєднати з роллю працівника. Логіка «І» не дасть змішати всіх співробітників однієї посади, якщо правило має охоплювати лише конкретний регіон.
Третій сценарій — контроль заповнення даних. Умова is unknown може відокремити профілі без потрібного параметра. Це сигнал для адміністратора перевірити дані перед призначенням, а не доказ того, чому саме поле залишилося порожнім.
Покрокову роботу Центру автоматизації можна переглянути в офіційному відео AcademyOcean.
Automation Rules і Smart Teams — не одне й те саме
Обидві можливості допомагають працювати з командами, але використовують різну логіку. Automation Rules у стартовій версії призначають учнів за системними або кастомними властивостями профілю. Smart Teams — це окремий наявний сценарій для переходів, пов'язаних із завершенням курсу або визначеним проміжком часу.
У редакторі Automation Rules тригери Days from enrollment date та Course completion позначені як Coming soon. Вони ще не належать до доступних тригерів, тому сценарії за часом чи завершенням навчання не слід переносити в новий розділ до їх окремого запуску.
Різниця проста: якщо розподіл залежить від того, що записано у профілі учня, для цього доступні Automation Rules. Якщо перехід пов'язаний із навчальною подією або часом, зараз це окремий сценарій Smart Teams.