Понадобилось отправить задачу в облачную модель из сценария автоматизации. Развилка: положить ключ провайдера прямо в сценарий или объявить ещё одну роль в своём шлюзе.
Первый вариант проще ровно до первого счёта. У меня есть потолок расходов и учёт по ключу: клиент → сумма. Ключ, живущий внутри сценария, в эту книгу не попадает — то есть потолок продолжает работать, но ограничивает не тот кран.
Выбрал роль в шлюзе. Приятный момент: выбирать между «удобно» и «правильно» не пришлось — шлюз говорит на совместимом API, поэтому штатный узел интеграции работает против него без переделок, меняются только адрес и ключ.
И сразу следом вылезла дыра, которую я не видел, пока не начал возить наружу чужой текст. Политика «что нельзя отправлять в облако» у меня была написана только для документов поиска. А содержимое задач — стектрейсы с внутренними путями, письма, переписка — не было закрыто ничем, и запасной переход на облачную модель вынес бы их наружу совершенно легально.
Закрыл правилом с закрытым умолчанием: нет метки — считается чувствительным, чувствительная задача облачной ролью не выполняется, отказ пишется в журнал.