Роботи-автоматизація

https://demo.brightprint.com.ua/robots — конструктор правил «сталася подія → виконати дію», без участі розробників.

Як змінювати роботів: чернетка й публікація

Роботи, які зараз працюють, напряму не редагуються. Зверху сторінки видно активну версію (номер, хто й коли опублікував). Щоб щось змінити:

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

Чернетка одна на всіх; якщо її одночасно змінили двоє, другий побачить повідомлення й оновить сторінку. «Журнал версій» показує всі версії; «Повернути» публікує стару версію знову як нову. Повернення не скасовує вже надіслані повідомлення й виконані дії. Змінювати й публікувати можуть адміністратор і керівник. «Тест» і «Подія й умови» працюють з активними роботами (поза чернеткою).

Коли потрібно перевірити чернетку знову

У локальній 1.0.49 (08.10.2026, ще не викладено) результат перевірки зникає, якщо змінити ID замовлення, подію або список полів. Після оновлення чернетки чи активної версії перевірте потрібний приклад знову: форма починається заново.

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

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

Відмова в публікації та помилка робота

Локальне виправлення 07.10.2026: джерело — регресійні серверні тести. На production/демо ці виправлення ще не викладено; доступність уточнюйте за встановленою версією.

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

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

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

Тригери (коли спрацьовує)

Зміна стадії;
Вхід у конкретну стадію;
Прострочено дедлайн;
Дедлайн скоро настане;
Змінилось поле;
Чек-лист постдруку завершено повністю.

Умови (за яких саме умов)

Кожен робот можна обмежити додатковими умовами — наприклад, тільки для конкретної цільової стадії або конкретного пріоритету замовлення. Без умов робот спрацьовує на будь-яку подію обраного типу.

Правило з пріоритетом

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

Статус 06.10.2026: виправлення зіставлення реалізовано локально у 1.0.35 та перевірено автоматичними серверними тестами; на production/демо не викладено. Кнопка «Тест» показує текст дій і не перевіряє цю умову. Окремого вибору пріоритету в поточному редакторі роботів немає.

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

Дії (що зробити)

Написати в Telegram-групу компанії;
Сповістити клієнта;
Сповістити відповідального менеджера;
Надіслати email;
Надіслати лист за шаблоном;
Додати коментар до замовлення;
Виставити значення поля.

Текст повідомлення — шаблон із підстановками на кшталт {order_number}, {title}, {stage_name}.

Якщо відповідальний у відпустці чи на лікарняному (розділ «Відсутності») або не на зміні, він повідомлення однаково отримає, а копію — колега на зміні (по черзі) або директор, якщо на зміні нікого. Так само працюють сповіщення в центрі. «Тест» про це попереджає, нічого не надсилаючи.

Роботи «Скоро дедлайн» і «Прострочення дедлайну», коли в налаштуваннях SLA увімкнено робочі години, спрацьовують лише в робочий час: уночі й у вихідні нічого не надсилається, повідомлення прийде на початку робочого дня. «Скоро» — це за один робочий день до строку (строк у понеділок видно вже в п’ятницю).

Приклад

«Коли чек-лист постдруку завершено повністю → написати в Telegram-групу цеху: Замовлення №{order_number} «{title}» готове рухати на видачу».

Кнопка «Тест»

Натисніть «Тест» у картці робота. Поки запит триває, кнопка недоступна. Результат показує номер або ID одного доступного замовлення з воронки робота; без воронки — з доступних воронок.

Біля кожної дії видно текст, «Помилка» або «Увага» з поясненням. Помилка однієї дії не приховує наступні. Для зміни поля показано його код/значення або «Очистити поле». Невідомий тип у списку позначається «Невідома дія».

Якщо дужки шаблону пошкоджені — перевірте пари { і }. Для звичайних фігурних дужок у тексті використовуйте {{ і }}.
Використовуйте прості іменовані підстановки, наприклад {title}. Доступ до властивостей/індексів і спеціальне форматування у «Тесті» не підтримуються.
Невідома підстановка або відсутнє значення показуються порожнім текстом із попередженням; перевірте назву й дані замовлення.
Ліміти перегляду: 100 дій, 10 000 символів шаблону та 20 000 символів його результату на дію. При перевищенні текст не обрізається до правильного.
«Увага» про значення поля, відповідального, канал чи шаблон листа вказує, що ще треба перевірити. Відсутність помилки не гарантує доставки.

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

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

Статус 06.10.2026: діагностику реалізовано локально у 1.0.36; джерело — серверні й frontend тести. Production/демо, зовнішній браузерний пілот і приёмка не виконані; встановлену версію уточнюйте в інтегратора. Чернетка/ публікація правил та повна симуляція події ще не доступні.

Кнопка «Подія й умови»

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

Натисніть «Подія й умови» у картці робота.
Укажіть «ID замовлення». Після попереднього «Тесту» його ID підставляється. Потрібен саме ID, а не номер замовлення.
Оберіть «Подія». Для «Зміна поля» введіть «Змінені поля через кому», наприклад title, amount; для інших подій цей список не потрібний.
Натисніть «Перевірити подію». Поки запит триває, форма й перевірки недоступні. «Закрити» або Escape у формі закривають її.

Результат показує замовлення, подію, час читання і пояснення: робот увімкнений чи ні, відповідає тип події/воронка/стадія/поле/пріоритет/борг. Можна перевірити своє доступне замовлення з іншої видимої воронки, щоб побачити причину невідповідності; замовлення нікуди не переноситься.

Якщо вже є успішний такий самий запуск за останні п’ять хвилин, результат пояснює захист від повторів. Для зміни стадії попередження біля клієнтських дій показує, коли їх ведуть «Сповіщення клієнтам». Це не підтвердження відправлення повідомлення. Помилки/попередження шаблонів лишаються видимими.

Подію задаєте ви: вибір «Прострочення дедлайну» не доводить, що замовлення просрочене; вибір «Постдрук завершено» не перевіряє всі чекбокси. Майбутні переходи, календар і нові значення полів не моделюються. Дані або журнал можуть змінитися після перегляду. «Подія й умови збігаються» не гарантує виконання чи доставки; нічого не виконується й не надсилається.

Потрібне право керування роботами та доступ до замовлення. За невірного ID/події/списку полів перевірте введені дані; недоступне замовлення не підміняється іншим. Невідомі ключі старих умов дають попередження про ігнорування; зверніться до інтегратора, не вважайте їх діючими умовами. Акаунт «тільки перегляд» у звичайній CRM не дістає нового дозволу на цей POST: існуючі обмеження облікового запису лишаються.

Статус 06.10.2026: локально 1.0.37; джерело — серверні/фронтенд тести й parity відбору на synthetic даних. Native browser/зовнішнє приймання і викладка на production/демо не виконані. Чернетки й публікація правил ще не реалізовані.

Контрольний сценарій перед зовнішньою перевіркою

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

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

Історична межа цього сценарію (06.10.2026, 1.0.37): він перевіряв лише перегляд, до реалізації чернетки/публікації/повернення. Поточний порядок роботи з версіями наведено на початку сторінки; зовнішнє приймання й два тижні робочого спостереження цим сценарієм не підтверджені. Пройдений перегляд не підтверджує самостійної зміни процесу або готовності до production.

Джерело статусу 06.10.2026: синтетична HTTP/JWT перевірка на SQLite і PostgreSQL, 4 входи + 19 запитів без запису на кожній БД, без запису в перевірюваних запитах. Це не два клієнти чи зовнішній браузерний пілот. Версія застосунку залишилася 1.0.37; production/демо не оновлено.

Журнал спрацювань

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

BrightPrint CRMДемо-дані

Роботи+ Новий робот

Нагадати про оплатуСтадія · очікування передоплати
Надіслати макетПодія · додано нову версію

Робот: тригер, дія й стан увімкненнясписок роботів з увімкненим перемикачем і формою редагування тригера/дії.