#Ручна обробка

This feature is provided by the plugin «Робочий процес: Вузол ручної обробки»

#Вступ

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

При виконанні ручний вузол перериває виконання всього робочого процесу та генерує завдання для відповідного користувача. Після того, як користувач виконає завдання, робочий процес продовжиться, залишиться в очікуванні або буде завершений залежно від обраного статусу. Це дуже корисно в сценаріях, таких як процеси затвердження.

#Встановлення

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

#Створення вузла

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

#Налаштування вузла

#Відповідальний

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

Виберіть користувача або оберіть первинний чи зовнішній ключ даних користувача з контексту за допомогою змінної.

#Налаштування користувацького інтерфейсу

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

#Вкладки

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

#Блоки

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

#Блок даних

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

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

#Блок форми

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

• Користувацька форма
• Форма створення запису
• Форма оновлення запису

Форми створення запису та оновлення запису вимагають вибору базової колекції. Після подання форми користувачем, значення з форми будуть використані для створення або оновлення даних у вказаній колекції. Користувацька форма дозволяє вільно визначити тимчасову форму, не пов’язану з колекцією. Значення полів, подані користувачем, можуть бути використані в наступних вузлах.

Кнопки подання форми можна налаштувати на три типи:

• Надіслати та продовжити робочий процес
• Надіслати та завершити робочий процес
• Лише зберегти значення форми

Ці три кнопки представляють три статуси вузла в робочому процесі. Після подання статус вузла змінюється на «Виконано», «Відхилено» або залишається в стані «Очікування». Форма повинна мати налаштованою принаймні одну з перших двох опцій, щоб визначити подальший хід всього робочого процесу.

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

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

#Блок завдань

Для ручної обробки вам також потрібно додати список завдань на сторінку, щоб відображати завдання. Це дозволить відповідному персоналу отримувати доступ до конкретних завдань ручного вузла та обробляти їх через цей список.

#Додавання блоку

Ви можете вибрати «Завдання робочого процесу» з блоків на сторінці, щоб додати блок списку завдань:

Приклад блоку списку завдань:

#Деталі завдання

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

#Приклад

#Перевірка статті

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

Створіть робочий процес, що запускається подією «Створити статтю», та додайте ручний вузол:

У ручному вузлі налаштуйте відповідального як адміністратора. В конфігурації інтерфейсу додайте блок на основі даних тригера для відображення деталей нової статті:

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

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

Щоб спростити завдання оператора, інший спосіб полягає в налаштуванні присвоєння значень форми на кнопці «Продовжити робочий процес». У присвоєнні додайте поле «Статус» зі значенням «Опубліковано». Це означає, що коли оператор натисне кнопку, стаття буде оновлена до опублікованого стану:

Потім, з меню конфігурації у верхньому правому куті блоку форми, виберіть умову фільтрації для даних, які потрібно оновити. Тут виберіть колекцію «Статті», а умова фільтрації — «ID дорівнює Змінна тригера / Дані тригера / ID»:

Нарешті, ви можете змінити заголовки кожного блоку, текст відповідних кнопок та текст підказки полів форми, щоб зробити інтерфейс більш зручним для користувача:

Закрийте панель конфігурації та натисніть кнопку «Надіслати», щоб зберегти налаштування вузла. Робочий процес тепер налаштовано. Після активації цього робочого процесу він буде автоматично запускатися при створенні нової статті. Адміністратор може побачити, що цей робочий процес потребує обробки, у списку завдань. Натиснувши «Переглянути», можна побачити деталі завдання:

Адміністратор може вручну оцінити деталі статті, щоб вирішити, чи може вона бути опублікована. Якщо так, натискання кнопки «Затвердити» оновить статтю до опублікованого стану. Якщо ні, натискання кнопки «Відхилити» залишить статтю в чернетковому стані.

#Затвердження відпустки

Припустімо, що працівник потребує відпустки, яка повинна бути затверджена керівником, щоб набути чинності, а дані про відпустку відповідного працівника мають бути списані. Незалежно від затвердження чи відхилення, вузол HTTP-запиту буде використано для виклику SMS API, щоб надіслати відповідне сповіщення працівнику (див. розділ HTTP-запит). Цей сценарій можна реалізувати за допомогою користувацької форми в ручному вузлі.

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

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

Водночас, після ручного вузла, ми можемо використовувати вузол умовного рішення, щоб визначити, чи затвердив керівник запит на відпустку. У гілці затвердження додайте обробку даних для списання відпустки, а після злиття гілок додайте вузол запиту для надсилання SMS-повідомлення працівнику. Це дає наступний повний робочий процес:

Умова у вузлі умовного рішення налаштована як «Ручний вузол / Дані користувацької форми / Значення поля затвердження дорівнює «Затверджено»:`

Дані у вузлі надсилання запиту також можуть використовувати відповідні змінні форми з ручного вузла, щоб розрізняти вміст SMS для затвердження та відхилення. Таким чином завершується налаштування всього робочого процесу. Після активації робочого процесу, коли працівник подає форму запиту на відпустку, керівник може обробити затвердження у своїх завданнях. Операція в основному схожа на процес перевірки статті.