Маршрут согласования: обязательные роли и замещение

Решение: какие проверки действительно обязательны

Начните с содержания решения, а не с адресатов письма. Например, одна роль проверяет выполнимость услуги, другая — расчёт и ресурсные ограничения. Если обе проверки обязательны, положительный ответ одной не заменяет отсутствие другой.

Разделите правило между ролями и внутри роли. Между обязательными ролями может действовать «И»: нужны все. Внутри группы взаимозаменяемых представителей — «ИЛИ»: достаточно одного допустимого решения. Последовательный маршрут дополнительно задаёт, когда начинается следующая проверка.

Microsoft Power Automate различает Everyone must approve и First to respond. В первом варианте положительный исход требует одобрений всех назначенных участников, а один отказ завершает запрос отрицательно. Во втором ответ любого участника завершает запрос. Microsoft: approval types.

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

Роль, представитель и уведомление — разные записи

Роль обозначает требуемую проверку. Представитель — человека, который вправе выполнить её в данном запросе. Уведомление лишь сообщает ему о работе. Повторное письмо не создаёт дополнительную роль, а прочитанное сообщение не является решением.

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

Microsoft описывает групповые approvals отдельно: один ответ участника может представлять группу. Для запроса, требующего ответа двух групп, нужен представитель каждой; ответов двух человек из одной недостаточно. Microsoft: group approvals.

Учебный пример: четыре допустимых представителя, две роли

Все обозначения условные. Запрос R1 относится к версии V1. Нужны две роли: OPS проверяет операционную часть, FIN — расчёт. Допустимый пул OPS — O1/O2, и оба уведомлены как активные представители. Пул FIN — F1/F2, но первоначально назначен только F1. F2 является допустимым заместителем и сможет отвечать после разрешённой передачи. Между ролями действует «И».

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

O1 одобрил V1. Состояние: OPS выполнена, FIN ожидает; завершена одна роль из двух. Затем пришло ещё одно положительное сообщение O2. В журнале два ответа, но выполнена по-прежнему одна роль. Нельзя превратить два ответа в «2 из 2» и разрешить следующий шаг.

F1 отсутствует. Ответственный применяет разрешённый порядок замещения и назначает F2 представителем FIN для этого запроса. Подтверждённая замена не создаёт третью обязательную роль. После положительного решения F2 получаем OPS + FIN = 2 выполненные роли из 2.

В истории могут находиться три положительных сообщения: O1, O2 и F2. Итог считается по двум ролям, а не как «3 из 4 возможных представителей». O2 не обязан отвечать повторно, если OPS уже завершена согласно выбранному правилу. Отсутствие F1 не остаётся второй незакрытой проверкой FIN после корректной замены.

Если вместо одобрения FIN даёт допустимый отказ, текущий круг получает отрицательный результат. Ранее завершённая OPS не превращает его в положительный. Если после завершения роли приходит новая существенная информация, её передают на отдельный разбор, не игнорируя и не считая автоматически вторым голосом.

Замещение требует области и полномочия

Для передачи укажите исходного получателя, нового, роль, запрос, причину, начало действия и согласовавшего. Решите, что происходит со старой возможностью ответа: она прекращается либо остаётся по явно выбранной политике. Иначе F1 и F2 могут независимо действовать по разным представлениям маршрута.

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

В Power Automate получатель запроса может переназначить его, тогда как инициатор не может просто выполнить ту же операцию: документация описывает для него отмену запроса и изменение назначенного согласующего в процессе. Microsoft: reassign an approval. Поэтому путь замещения зависит от роли пользователя и конкретной системы.

Отсутствие ответа к сроку должно вести к назначенному действию: напоминанию, проверке отсутствия, замещению или остановке. Молчание не следует автоматически считать одобрением. У нового назначения сохраняйте связь с первоначальным запросом и объясняйте изменение внутреннего срока.

Изменение версии создаёт новый круг проверки

Допустим, после ответов по V1 автор существенно изменил состав предложения и подготовил V2. В учебной политике обе обязательные роли проверяют новую версию заново. Создаётся круг R2 с OPS и FIN в состоянии ожидания; решения R1 остаются историей V1.

Поздний ответ F1 по прежнему уведомлению V1 не засчитывается в R2. Проверка должна сопоставить запрос, круг, версию, роль и допустимого участника. Одного совпадения названия документа недостаточно.

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

Если бизнес разрешает сохранять часть проверок после несущественной правки, отдельно определите критерий, согласующего и затронутые роли. Такое наследование не должно возникать из привычки копировать статус «одобрено».

Возврат на доработку отличается от ожидания

Если процесс различает отказ и возврат на исправление, задайте разные последствия. В ожидании представитель ещё должен ответить. При возврате автор должен устранить конкретное замечание. При отказе дальнейшее действие определяется принятой процедурой, а не очередным напоминанием тому же человеку.

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

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

Минимальные данные и защита от повторов

Нужны бизнес-объект, версия содержимого, номер круга, версия маршрута, обязательные роли и правило их объединения. Для роли сохраняйте допустимого представителя, решения, делегирование и время. Для ответа — источник, точную версию, автора и результат проверки применимости.

Устойчивый идентификатор ответа помогает отличить повтор доставки от нового решения. При неизвестном результате сначала проверьте существующий круг. Повторное нажатие не должно дважды запускать разрешённую следующую операцию.

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

Приёмочный чек-лист

1. Две роли OPS и FIN отличаются от четырёх возможных представителей.
2. Ответы O1 и O2 оставляют выполненной только OPS.
3. Без FIN итог «одобрено» не возникает.
4. Замещение F1 на F2 сохраняет одну роль FIN и историю передачи.
5. Допустимый отказ в ожидающей роли завершает круг согласно выбранному правилу.
6. Дополнительное сообщение после завершения роли не становится вторым голосом.
7. V2 получает нужный новый круг, поздний ответ V1 в него не попадает.
8. Возврат на доработку назначает конкретное действие автору.
9. Повтор ответа не создаёт второго завершения маршрута.
10. Одобрение отделено от фактической отправки или денежной операции.

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

Частые вопросы

Два положительных ответа означают две проверки?

Только если они относятся к двум требуемым ролям текущего круга. Два представителя одной роли не заменяют другую.

Можно заместителю просто переслать письмо?

Нужны предусмотренная передача, полномочие, доступ к нужной версии и понятное состояние прежнего назначения. Пересылка сама этого не доказывает.

Внутреннее одобрение равно юридической подписи?

Нет такого общего вывода. Этот материал описывает операционный маршрут; требования к подписи, документам и полномочиям проверяются отдельно.

Источники

• Microsoft: approval types — все одобрения или первый ответ.
• Microsoft: group approvals — представитель каждой обязательной группы.
• Microsoft: approval scenarios — переназначение и ограничения ролей.

Проверено 9 октября 2026 года. OPS, FIN и два круга согласования учебные.