Ручная обработка

Рабочий процесс: ручной узелCommunity Edition+

Введение

Когда бизнес-процесс нельзя полностью автоматизировать для принятия решений, можно использовать узел «Ручная обработка», чтобы делегировать часть полномочий по принятию решений человеку.

Когда выполняется узел «Ручная обработка», он прерывает выполнение всего рабочего процесса и создает задачу для соответствующего пользователя. После отправки задачи пользователем рабочий процесс в зависимости от выбранного статуса либо продолжится, либо останется в ожидании, либо завершится. Это особенно полезно в сценариях вроде процессов согласования.

Установка

Встроенный плагин, установка не требуется.

Создание узла

В интерфейсе настройки рабочего процесса нажмите кнопку плюса ("+") в рабочем процессе, чтобы добавить узел «Ручная обработка»:

Создание узла ручной обработки

Настройка узла

Исполнитель

Для узла «Ручная обработка» нужно указать пользователя как исполнителя задачи. Список задач можно добавить на страницу как блок, а содержимое всплывающего окна задачи для каждого узла настраивается в конфигурации интерфейса узла.

Выберите пользователя либо укажите первичный/внешний ключ пользовательских данных из контекста через переменную.

Настройка исполнителя с выбором переменной

Примечание

Сейчас назначение исполнителя в узле «Ручная обработка» не поддерживает нескольких пользователей. Поддержка появится в будущих версиях.

Настройка пользовательского интерфейса

Конфигурация интерфейса задачи — ключевая часть узла «Ручная обработка». Нажмите кнопку «Настроить пользовательский интерфейс», чтобы открыть отдельное окно конфигурации, которое настраивается в визуальном режиме, как обычная страница:

Настройка интерфейса узла

Вкладки

Вкладки можно использовать для разделения разного содержимого. Например, одна вкладка для отправки формы согласования, другая — для отправки формы отклонения, либо для отображения деталей связанных данных. Их можно настраивать произвольно.

Блоки

Поддерживаемые типы блоков в основном делятся на две категории: блоки данных и блоки форм. Дополнительно Markdown обычно используется для статического контента, например информационных сообщений.

Блок данных

Блоки данных могут отображать данные триггера или результаты обработки любого узла, предоставляя релевантный контекст исполнителю задачи. Например, если рабочий процесс запускается событием формы, можно создать блок деталей для данных триггера. Это соответствует настройке деталей на обычной странице и позволяет выбрать для отображения любое поле данных триггера:

Блок данных триггера

Блоки данных узлов работают аналогично: можно выбрать результат данных из вышестоящего узла и показать его в деталях. Например, результат вышестоящего узла «Вычисление» может служить контекстной справочной информацией для задачи исполнителя:

Блок данных узла

Примечание

Поскольку во время конфигурации интерфейса рабочий процесс еще не находится в состоянии выполнения, конкретные данные в блоках данных не отображаются. Данные для конкретного экземпляра рабочего процесса видны только во всплывающем интерфейсе задачи после запуска и выполнения рабочего процесса.

Блок формы

В интерфейсе задачи нужно настроить как минимум один блок формы, чтобы обработать итоговое решение о продолжении рабочего процесса. Если форму не настроить, после прерывания рабочий процесс не сможет продолжиться. Доступны три типа блоков формы:

  • Пользовательская форма
  • Форма создания записи
  • Форма обновления записи

Типы блоков формы

Для формы создания записи и формы обновления записи требуется выбрать базовую коллекцию. После отправки пользователем задачи значения формы используются для создания или обновления данных в указанной коллекции. Пользовательская форма позволяет свободно определить временную форму, не привязанную к коллекции. Значения полей, отправленные пользователем, можно использовать в последующих узлах.

Кнопки отправки формы можно настроить в трех вариантах:

  • Отправить и продолжить рабочий процесс
  • Отправить и завершить рабочий процесс
  • Только сохранить значения формы

Кнопки формы

Эти три кнопки соответствуют трем статусам узла в процессе рабочего процесса. После отправки статус узла становится «Завершено», «Отклонено» или остается «В ожидании». У формы обязательно должна быть настроена хотя бы одна из первых двух кнопок, чтобы определить дальнейший ход всего рабочего процесса.

На кнопке «Продолжить рабочий процесс» можно настроить присвоения значений полям формы:

Настройка значений формы на кнопке

Всплывающее окно настройки значений формы

После открытия всплывающего окна можно присвоить значения любому полю формы. После отправки формы это значение станет итоговым значением поля. Это особенно полезно при проверке данных. В одной форме можно использовать несколько кнопок «Продолжить рабочий процесс», где каждая кнопка задает разные перечислимые значения для полей (например, статус), тем самым позволяя продолжать выполнение рабочего процесса с разными наборами данных.

Блок задач

Для ручной обработки также нужно добавить на страницу список задач, чтобы отображать задачи. Это позволяет ответственным сотрудникам получать доступ к конкретным задачам узла «Ручная обработка» и обрабатывать их через этот список.

Добавить блок

Чтобы добавить блок списка задач, выберите «Задачи рабочего процесса» из блоков на странице:

Добавление блока задач

Пример блока списка задач:

Список задач

Детали задачи

Далее ответственные сотрудники могут нажать на соответствующую задачу, открыть всплывающее окно задачи и выполнить ручную обработку:

Детали задачи

Пример

Проверка публикации

Предположим, что пост, отправленный обычным пользователем, должен быть одобрен администратором перед переводом в опубликованное состояние. Если рабочий процесс отклоняется, пост остается в состоянии черновика (не публичный). Этот процесс можно реализовать через форму обновления записи в узле «Ручная обработка».

Создайте рабочий процесс с триггером «Создание поста» и добавьте узел «Ручная обработка»:

Manual Node_Example_Post Review_Workflow Orchestration

В узле «Ручная обработка» назначьте исполнителем администратора. В конфигурации интерфейса добавьте блок на основе данных триггера, чтобы показать детали нового поста:

Manual Node_Example_Post Review_Node Configuration_Details Block

В конфигурации интерфейса добавьте блок на основе формы обновления записи, выберите коллекцию постов, чтобы администратор мог принять решение об одобрении. После одобрения соответствующий пост будет обновлен в соответствии с дальнейшими настройками. После добавления формы по умолчанию будет кнопка «Продолжить рабочий процесс», которую можно трактовать как «Одобрить». Затем добавьте кнопку «Завершить рабочий процесс» для отклонения:

Manual Node_Example_Post Review_Node Configuration_Form and Actions

При продолжении рабочего процесса нужно обновлять статус поста. Это можно настроить двумя способами. Первый — показать поле статуса поста прямо в форме, чтобы оператор выбирал значение вручную. Такой способ лучше подходит для сценариев с активным заполнением формы, например при добавлении обратной связи:

Manual Node_Example_Post Review_Node Configuration_Form Fields

Чтобы упростить задачу оператора, можно использовать второй способ: настроить присвоение значений формы на кнопке «Продолжить рабочий процесс». В присвоении добавьте поле «Статус» со значением «Опубликовано». Это означает, что при нажатии кнопки пост будет переведен в опубликованное состояние:

Manual Node_Example_Post Review_Node Configuration_Form Assignment

Далее в меню конфигурации в правом верхнем углу блока формы выберите условие фильтрации для обновляемых данных. Здесь выберите коллекцию «Посты», а условие фильтрации задайте как «ID равно переменной триггера / данным триггера / ID»:

Manual Node_Example_Post Review_Node Configuration_Form Condition

В конце можно изменить заголовки блоков, тексты соответствующих кнопок и тексты-заполнители полей формы, чтобы сделать интерфейс более удобным:

Manual Node_Example_Post Review_Node Configuration_Final Form

Закройте панель конфигурации и нажмите «Отправить», чтобы сохранить настройку узла. На этом рабочий процесс настроен. После включения он будет автоматически запускаться при создании нового поста. Администратор увидит необходимость обработки рабочего процесса в списке задач. По нажатию откроются детали задачи:

Manual Node_Example_Post Review_To-do List
Manual Node_Example_Post Review_To-do Details

Администратор может принять ручное решение на основе деталей поста — можно ли публиковать пост. Если да, нажатие кнопки «Одобрить» переведет пост в опубликованное состояние. Если нет, нажатие «Отклонить» оставит пост в состоянии черновика.

Согласование отпуска

Предположим, сотрудник подает заявку на отпуск, которая вступает в силу только после одобрения руководителем, а у сотрудника нужно списать соответствующие отпускные данные. Независимо от одобрения или отклонения используется узел «HTTP запрос» для вызова API SMS и отправки уведомления сотруднику. Этот сценарий можно реализовать через пользовательскую форму в узле «Ручная обработка».

Создайте рабочий процесс с триггером «Создание заявки на отпуск» и добавьте узел «Ручная обработка». Это похоже на предыдущий процесс проверки постов, но здесь исполнителем является руководитель. В конфигурации интерфейса добавьте блок на основе данных триггера для отображения деталей новой заявки на отпуск. Затем добавьте еще один блок на основе пользовательской формы, чтобы руководитель мог принять решение об одобрении. В пользовательской форме добавьте поле статуса одобрения и поле причины отклонения:

Manual Node_Example_Leave Approval_Node Configuration

В отличие от процесса проверки постов, здесь нужно продолжать последующий процесс в зависимости от результата одобрения руководителя, поэтому для отправки настраивается только кнопка «Продолжить рабочий процесс», без использования кнопки «Завершить рабочий процесс».

Одновременно после узла «Ручная обработка» можно использовать узел «Условие», чтобы определить, одобрил ли руководитель заявку на отпуск. В ветви одобрения добавьте обработку данных для списания отпуска, а после слияния ветвей добавьте узел «HTTP запрос» для отправки SMS-уведомления сотруднику. В итоге получается следующий полный рабочий процесс:

Manual Node_Example_Leave Approval_Workflow Orchestration

Условие в узле «Условие» настраивается как «Узел ручной обработки / Данные пользовательской формы / Значение поля одобрения равно „Одобрено“»:

Manual Node_Example_Leave Approval_Condition

Данные в узле «HTTP запрос» также могут использовать соответствующие переменные формы из узла «Ручная обработка», чтобы различать содержимое SMS для одобрения и отклонения. На этом конфигурация рабочего процесса завершена. После включения рабочего процесса, когда сотрудник отправляет форму заявки на отпуск, руководитель сможет обработать согласование в своих задачах. Операция в целом аналогична процессу проверки постов.