Правила автоматизации в AcademyOcean: команды обновляются в соответствии с заданными правилами
Правила автоматизации в 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: кого обработало правило
Журнал активности показывает учащихся, для которых выполнялось правило, примененные условия и действие, а также время последнего срабатывания. Если автоматизация несколько раз обрабатывает одного учащегося, каждое выполнение отображается отдельной записью. Новые события располагаются сверху, а для длинного журнала доступна пагинация.
Этот журнал отвечает на практический вопрос администратора: «К кому и когда применялось правило?». Если состав команды выглядит не так, как ожидалось, записи помогают проверить сам факт выполнения, но не объясняют причину несоответствия данных в профиле.
Журнал аудита: кто изменял настройки
Журнал аудита фиксирует административные изменения правила и позволяет просмотреть технические данные до и после редактирования. Он нужен для другого вопроса: «Кто изменил логику и что именно было изменено?».
Разделение журналов устраняет путаницу между результатом работы правила и историей его конфигурации. Журнал активности (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.