Как принять передачу потока Power Automate

Принимайте весь согласованный результат

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

Разбираем один вымышленный F-OPS в одной среде: существующий плановый облачный поток в составе решения (solution). P0, P1, идентификаторы, разрешения и все результаты ниже заданы для учебного разбора. Мы не запускали Power Automate или SABSUS и не получали данные организации. Пример оценивает достаточность предъявленного набора свидетельств.

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

Уточните технические границы

Различайте основного владельца (Primary owner) и совладельца. Connection reference указывает на подключение с учётной записью. Подключения ушедшего сотрудника могут отказать при действующем владельце; Other connections этим потоком не используются. При пользовательском лицензировании планового потока действует лицензия основного владельца; назначенная потоку лицензия Process имеет приоритет. Лицензирование независимо от подключений.

Попросите администратора подтвердить применимость этих условий к конкретной среде. В папке приёмки должны отдельно лежать свидетельства сопровождения и лицензирования с датой проверки. Не выводите одно из другого. Неизвестный статус помечайте как открытый вопрос; не заменяйте его скриншотом успешного результата или устным обещанием «всё оплачено».

Проследите редкую ветвь до получателя

В учебной карте три операции: прочитать список, создать внутреннюю задачу и, только при исключении, уведомить диспетчера. Для каждой записаны ссылка, подключение, учётная запись и назначение. Имена REF и CONN придуманы для наглядности. Доказательством служит разрешённая к просмотру конфигурация с устойчивыми идентификаторами; привлекательное название «общая почта» само по себе ничего не подтверждает.

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

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

Задайте два разных ожидаемых исхода

TEST-401 обозначает обычную запись. Ожидается ровно одна внутренняя задача с этим номером в согласованном тестовом месте; уведомления диспетчеру быть не должно. TEST-402 обозначает исключение. Для него нужна одна задача и одно уведомление в выделенном тестовом ящике, причём оба результата должны содержать TEST-402.

Номер связывает вход с последствиями. Найденное письмо без нужного номера может относиться к старому упражнению; задача в соседней очереди не выполняет договорённость. Сохраните отдельно, что ожидалось, что предъявлено и где находится свидетельство. Фраза «всё зелёное» не объясняет ни содержимое, ни получателя, ни отсутствие лишнего эффекта.

Проверять нужно и запретный для обычной записи эффект: если TEST-401 породил уведомление, результат неверен, хотя задача существует. Для TEST-402 отсутствие письма нельзя скрыть общей отметкой о созданной задаче. Это два разных бизнес-условия; их не следует сводить к доле успешных запусков. Все наблюдения в следующем сравнении являются условиями задачи, а не журналом приложения.

Сравните одинаковое начало и разные основания

В случае A основной владелец — P1, редактирование разрешено, лицензирование подтверждено. Предъявлен соответствующий заданию TEST-401. Однако REF-NOTICE связан с CONN-P0-NOTICE. Передачу в полном согласованном объёме не принимаем: независимость редкого шага от P0 остаётся неподтверждённой. При этом нельзя написать «TEST-402 завершился ошибкой»: такой результат нам не предъявляли.

Запись решения A должна назвать незакрытый пункт, ответственную роль и требуемое свидетельство. Например: «Администратор: представить согласованное основание для шага уведомления и результат TEST-402». Передача такой записи исполнителю точнее общего требования «починить автоматизацию» и не разрешает ему самостоятельно расширять доступ.

В случае B для уведомления уже предъявлено разрешённое соответствие REF-NOTICE → CONN-P1-NOTICE → P1. Остальные условия A сохранены, а отдельные результаты TEST-401 и TEST-402 совпадают с заданием по количеству, номеру и месту. Этих исходных данных достаточно для принятия именно рассматриваемой конфигурации и двух указанных исходов. Здесь не описывается создание или переключение подключения.

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

Проверьте и противоположную ошибку

В случае C всё соответствует B, но старая запись P0 видна среди неиспользуемых подключений. Полная карта подтверждает: в F-OPS нет действующих ссылок на неё. Отклонять передачу только из-за знакомого имени нельзя. Отсутствие запусков по этой записи само по себе было бы слабее: редкий обязательный путь мог просто ещё не встретиться.

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

Оставьте проверяемую запись решения

Для F-OPS достаточно компактного пакета: среда и идентификатор потока; ссылки на уже собранные свидетельства; карта всех обязательных путей; два задания с ожидаемыми исходами; свидетельства результатов; открытые вопросы и подпись ответственного за приёмку. В карте храните идентификаторы и ссылки на разрешённые свидетельства, без паролей и токенов.

У каждого пункта полезны три статуса: «подтверждено», «не выполнено» и «не установлено». Последние два запрещают положительное решение по соответствующему требованию, но требуют разных действий. Известное расхождение направляют на согласованное исправление; недостающие сведения сначала запрашивают. Не превращайте предположение о будущем отказе в запись о состоявшемся инциденте.

Для реальной проверки администратор отдельно согласует безопасный способ и любые изменения. Не проверяйте непрерывность отключением аккаунта, отзывом прав или удалением связей. Срочное реагирование на угрозу безопасности не откладывают ради этой приёмки. Общие правила учёта автоматизации есть в руководстве по управлению агентами.