Андрей Николаев

Если да, то какое действие БП отвечает за блокировку изменений поля?

Нет, блокировать поля нельзя.
Что можно сделать? Создать через api не редактируемое пользователем поле - Статус.
Сделать БП который будет менять сразу оба статуса именно он будет отвечать за переходы.
Сделать БП который при изменении будет проверять соответствие реального статуса со статусом в этом поле и если они отличаются устанавливать реальный статус в статус из поля.

Где будут сложности:
1) Роботы и триггеры, там скорее всего придется либо отказаться, либо пересмотреть стратегию.
2) Сторонние приложения могут работать некорректно

Для единого БП такое не реализовать.
Необходимо разбивать Ваш бизнес-процесс на отдельные составляющие таким образом, чтобы единого экземпляра небыло.
Чтобы БП возвращался к ранним стадиям, вам нужно сделать БП со стадиями и ПОСЛЕ завершения задачи дополнительно проверять статус и отправлять его в соответствующий блок, но проще БП разбить на несколько частей.

К сожалению для данного типа поля такое использовать нельзя, однако можно использовать какое-либо из полей типа HTML/BB и уже там выводить как вам хочется.

1) Подписываемся на событие OnEpilog модуля main.
Подробнее в документации: https://dev.1c-bitrix.ru/learning/course/index.php...

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

2) На событии:
- Проверяем что это не Ajax запрос

$req = \Bitrix\Main\Application::getInstance()->getContext()->getRequest();
// $req->isAjaxRequest()


- Проверяем что страница не админка (будет определена константа ADMIN_SECTION и она будет true)

И если ок, то регистрируем и подключаем свою js-библиотеку и подключаем ее.
Подробнее о js-библиотеках: https://dev.1c-bitrix.ru/api_help/js_lib/my_extens...
3) В коде своей библиотеки регистрируем подписку, как вы указали

Исходящий веб-хук возвращает строго указанную информацию.
Расширить передаваемые параметры в облачном битрикс24 нельзя.

Для определения привязана ли задача к сделке можно воспользоваться методом tasks.task.get.
У задачи привязанной к CRM будет параметр UF_CRM_TASK с указанием к какой сущности она привязана.

Нет, реализовать подобное на момент написания комментария нельзя.

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

Однако, путем разработки собственных действий бизнес-процесса возможно реализовать иной вариант.
Вам потребуется разработать 2 дополнительных блока действий бизнес-процесса:
- Ожидание изменение статуса задачи
- Редактирование задачи.

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

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

Правильного/Хайпового/Актуального/Лучшего способа нет.

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

Может получиться так, что какие-то вещи будет проще сделать Роботами, какие-то Бизнес-процессами, а какие-то возможно стоит вообще вынести в списки.

Когда я в последний раз работал с синхронизацией (весна 2019 года) такого механизма небыло.

Да и в целом, даже если отвлечься от БУС и Б24 такой механизм впринципе достаточно непростая работа, так как помимо всего прочено нужно дополнительно:
- поддерживать маппинг свойств (добавилось в б24 появилось в бус и наоборот)
- поддерживать маппинг товаров
- поддерживать маппинг значений списочных методов
- поддерживать маппинг ценовой политики

В общем случае интеграция работает так:
- БУС формирует заказ и отправляет его в Б24.
- Б24 создает товарные позиции под сформированную сделку/заказ
- Вся дальнейшая работа происходит в Б24.