Power Apps и Power Automate в Power BI: формы, кнопки и обновление данных

Обновлено 3 сентября 2026 года.

Power Apps добавляет в отчёт Power BI форму для работы с бизнес-данными, а Power Automate запускает действия: согласование, уведомление или обновление модели. Эти инструменты решают разные задачи. Отчёт помогает заметить проблему, форма — исправить запись в источнике, поток — выполнить дальнейший процесс.

Главное архитектурное условие: обычная импортированная модель Power BI не становится редактируемой базой данных. Изменения сохраняют в SharePoint, Dataverse, SQL или другой поддерживаемой системе. Затем Power BI получает их в соответствии со своим режимом подключения.

Содержание: Как выбрать способ интеграции · Что требуется до настройки · Практикум: комментарий к выбранной заявке в SharePoint · Почему изменение ещё не появилось на графике · Кнопка Power Automate в отчёте · Обновление модели через Power Automate · Повторный запуск потока: почему одной проверки на дубль мало · Как отличать сохранение, refresh и появление данных в отчёте · Диагностика: где искать причину сбоя · Как принять интеграцию перед запуском

Как выбрать способ интеграции

Что требуется до настройки

Power Apps, Power Automate и Power BI — отдельные продукты Power Platform. Подписка Power BI не означает, что все приложения, потоки и premium-коннекторы уже доступны каждому сотруднику. Проверьте лицензии автора и пользователей, среду Power Platform, доступные подключения и политики организации. Официальные вопросы лицензирования.

Canvas apps разрабатывают в браузерной Power Apps Studio, облачные потоки — в Power Automate. Power Automate for desktop решает отдельные задачи автоматизации действий на компьютере.

Заранее задайте границы операции. Например: аналитик может изменить комментарий к одной доступной ему заявке, но не сумму договора и не владельца записи. Согласуйте, где проверяются эти права и где сохраняется история изменений.

Лицензии и подключения: что проверить на конкретном пользователе

SharePoint относится к Standard-коннекторам Power Apps и Power Automate, SQL Server — к Premium. Наличие Power BI Pro не оплачивает автоматически premium-возможности других продуктов. Проверьте фактические права пользователя Microsoft 365/Power Apps/Power Automate и весь набор коннекторов приложения или потока. Классификация SharePoint, SQL Server.

У кнопочного потока проверьте Run only users и каждое подключение: используется ли подключение владельца или Provided by run-only user. Во втором варианте действие обращается к системе с правами запускающего пользователя, если коннектор поддерживает этот сценарий. В первом нужны явные проверки полномочий, чтобы общий аккаунт не расширял доступ читателя. Право запуска не требует выдавать всем права совладельца потока. Run-only и подключения.

Power Apps visual: передача выбранной строки

Добавьте Power Apps visual в отчёт и передайте необходимые поля, прежде всего устойчивый идентификатор записи. Опубликуйте отчёт в Power BI service, откройте его в поддерживаемом браузере и создайте приложение из визуального элемента либо подключите существующее. Контекст доступен приложению через PowerBIIntegration.Data; это данные для чтения, а не таблица для записи. Настройка Power Apps visual.

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

Практикум: комментарий к выбранной заявке в SharePoint

Учебная схема: Power BI читает список SharePoint Requests в режиме Import; canvas app записывает комментарий в тот же список. В списке нужны системный числовой ID, Title и текстовый столбец Comment. Для упражнения достаточно двух тестовых заявок. Их ID назначает SharePoint — используйте реальные полученные номера, а не предполагаемые 1 и 2.

В Power Apps подключите список как источник Requests. В Power BI передайте в визуальный элемент именно ID заявки без суммирования. Одна строка PowerBIIntegration.Data означает один переданный набор значений, а не отдельное событие «пользователь щёлкнул по заявке». Без явного выбора в визуал может попасть весь доступный контекст, поэтому приложение проверяет число строк и показывает ID перед сохранением.

Ниже — шаблон для тестовой среды, не готовый импортируемый пакет приложения. Формулы сверены с документацией, но не запускались в вашем tenant. Все свойства нужно проверить в Studio с фактической схемой списка. В примерах запятые разделяют аргументы, точки с запятой — действия. В русской локали Power Fx обычно использует «;» для аргументов и «;;» для цепочки действий.

1. Создайте форму и зафиксируйте редактируемую запись

Добавьте Edit form frmRequest. DataSource = Requests, Item = varRequest, DefaultMode = FormMode.Edit. Оставьте карточку Comment для редактирования. Обязательные поля списка, например Title, сохраните в форме с корректными исходными значениями; если их не редактируют, задайте карточкам режим просмотра. ID показывайте отдельной подписью.

В App.OnStart инициализируйте состояние. После изменения OnStart запустите его в Studio перед проверкой:

Set(varSaving, false);
Set(varLoading, false);
Set(varRequest, Blank())

Добавьте кнопку «Открыть выбранную заявку». Для её DisplayMode:

If(
    CountRows(PowerBIIntegration.Data) = 1
        && !Coalesce(varSaving, false)
        && !Coalesce(varLoading, false)
        && !frmRequest.Unsaved,
    DisplayMode.Edit,
    DisplayMode.Disabled
)

В OnSelect используйте явное открытие записи. ID фиксируется до обращения к источнику, чтобы последующая смена фильтра отчёта не подменила запрос:

If(
    Coalesce(varSaving, false)
        || Coalesce(varLoading, false)
        || frmRequest.Unsaved,
    Notify("Сначала завершите сохранение или отмените правки.", NotificationType.Warning),
    CountRows(PowerBIIntegration.Data) <> 1,
    Notify("Выберите одну заявку.", NotificationType.Warning),
    Set(varLoading, true);
    Set(varRequestedId, First(PowerBIIntegration.Data).ID);
    Set(varRequest, Blank());
    IfError(
        Refresh(Requests),
        Notify("Не удалось обновить источник.", NotificationType.Error); false,
        Set(varRequest, IfError(LookUp(Requests, ID = varRequestedId), Blank()));
        If(
            IsBlank(varRequest.ID),
            Notify("Заявка не найдена, недоступна или произошла ошибка чтения.", NotificationType.Warning),
            EditForm(frmRequest)
        ); true
    );
    Set(varLoading, false)
)

Refresh перечитывает источник приложения; IfError останавливает переход к следующей операции при обнаруженной ошибке. Проверьте, что обработка ошибок на уровне формул включена в приложении. Запись в varRequest становится Item формы и не меняется автоматически вслед за фильтром отчёта. Refresh, IfError.

В Label.Text выведите явное подтверждение объекта:

If(
    IsBlank(varRequest.ID),
    "Откройте одну заявку из отчёта",
    "Редактируется заявка ID " & Text(varRequest.ID)
)

Добавьте рядом пояснение: «Смена выбора в отчёте не меняет открытую форму. Для другой заявки сначала сохраните или отмените правки». В отличие от прямой привязки Item к First(PowerBIIntegration.Data), такое поведение не переносит форму на другую запись посреди ввода.

2. Сохраняйте с подтверждением результата источником

Для кнопки «Сохранить» задайте DisplayMode:

If(
    !Coalesce(varSaving, false)
        && !Coalesce(varLoading, false)
        && !IsBlank(varRequest.ID)
        && frmRequest.Valid
        && frmRequest.Unsaved,
    DisplayMode.Edit,
    DisplayMode.Disabled
)

В OnSelect повторите проверку непосредственно перед действием:

If(
    !Coalesce(varSaving, false)
        && !Coalesce(varLoading, false)
        && !IsBlank(varRequest.ID)
        && frmRequest.Valid
        && frmRequest.Unsaved,
    Set(varSaving, true);
    SubmitForm(frmRequest)
)

В OnSuccess формы:

Set(varRequest, frmRequest.LastSubmit);
Set(varSaving, false);
Notify("Комментарий сохранён в источнике. Отчёт обновляется отдельно.", NotificationType.Success)

В OnFailure формы:

Set(varSaving, false);
Notify(frmRequest.Error, NotificationType.Error)

SubmitForm проверяет форму; OnSuccess выполняется после успешной записи, OnFailure — при ошибке. LastSubmit содержит последнюю успешно сохранённую запись, а Unsaved показывает наличие несохранённых изменений. Функции формы, Свойства Edit form.

Добавьте кнопку «Отменить правки и закрыть» с OnSelect ResetForm(frmRequest); Set(varRequest, Blank()). Отключайте её на время varSaving или varLoading. Пока запрос сохраняется, отключите редактирование карточки Comment: её DisplayMode можно задать как If(Coalesce(varSaving, false), DisplayMode.Disabled, Parent.DisplayMode). Это уменьшает риск потери изменений, введённых во время сохранения.

3. Проверьте границы примера

Блокировка кнопок предотвращает случайные повторные действия в текущем интерфейсе. Она не является серверной защитой, транзакционной блокировкой или решением конкурентного редактирования из двух вкладок. Если другой сотрудник изменил запись после открытия формы, система должна обнаружить конфликт по поддерживаемой версии/ETag либо применить согласованное правило. Простое сравнение Modified перед записью оставляет окно гонки и не гарантирует защиту.

SharePoint-права на изменение записи шире, чем набор полей показанной формы. Скрытая карточка не запрещает менять столбец через другой интерфейс или API. Если бизнес требует разрешить только Comment и запретить изменение других полей, обеспечьте это в выбранном источнике или отдельной серверной операции. RLS отчёта такую проверку не выполняет.

Для поиска по SharePoint ID используйте сравнение равенства с зафиксированным числовым ключом. Не преобразовывайте весь столбец ID в текст внутри условия поиска без проверки делегирования. По документации SharePoint делегирует равенство по ID; операции «больше/меньше» для этого системного поля имеют ограничения. Делегируемые операции SharePoint.

Почему изменение ещё не появилось на графике

В примере SharePoint уже хранит новый комментарий, а импортированная модель Power BI может показывать прежний. Ей требуется обновление; после него нужно обновить отображение отчёта. Сообщение формы должно честно подтверждать сохранение в источнике, не обещая одновременного обновления всех графиков.

PowerBIIntegration.Refresh() доступна для приложения, созданного из Power Apps visual, и требует подходящего DirectQuery-подключения. Это не универсальная команда обновления Import-модели. Сам визуальный элемент Power Apps также не умеет передавать произвольные данные обратно в отчёт или фильтровать его из приложения. Максимум передаваемых из Power BI записей — 1000. Ограничения интеграции.

Не путайте этот предел с делегированием запросов Power Apps. Неделегируемая формула обрабатывает ограниченную выборку источника — по умолчанию до 500 записей, настройка позволяет до 2000. Увеличение лимита не гарантирует полноты результата. Проверяйте делегируемость конкретной функции для конкретного коннектора, особенно при поиске и фильтрации большого списка. Делегирование запросов.

Кнопка Power Automate в отчёте

Этот вариант подходит, когда пользователь выбирает данные и запускает заранее определённую операцию. Например, создаёт задачу по просроченной заявке. Для свободного ввода комментария лучше форма: Power Automate visual не поддерживает дополнительные произвольные поля ручного ввода.

1. Добавьте Power Automate visual и поля ID, название и другие необходимые атрибуты в Power Automate Data.
2. Через меню визуального элемента откройте Edit и создайте поток с Power BI button trigger прямо из отчёта.
3. Добавьте проверку выбранных данных и действие в целевой системе. Используйте нужные поля в действиях потока, иначе они могут отсутствовать во входном Body.
4. Сохраните и примените поток к кнопке.
5. Выдайте пользователям run-only доступ и проверьте запуск в режиме чтения отчёта.

Предел визуального элемента — 1000 записей. Он не работает в Publish to web и не поддерживается в сценариях embedded analytics. Право открыть отчёт не выдаёт право запускать поток. Инструкция и ограничения Power Automate visual.

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

Обновление модели через Power Automate

В коннекторе Power BI есть действие Refresh a dataset. Его основные параметры — Workspace и Dataset; выбор произвольных столбцов для обновления в этой простой карточке действия не предусмотрен. Термин dataset в коннекторе соответствует семантической модели в современном интерфейсе Power BI. Описание действия.

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

Power Automate не отменяет ограничения частоты и ресурсов Power BI. Для Import в общей ёмкости лимит восьми обновлений в сутки объединяет расписание и запросы REST API; ручные запуски Refresh now через интерфейс в этот лимит не входят. Для выделенной ёмкости доступная частота зависит от способа запуска и ресурсов. Если форма используется много раз в час, не запускайте полный refresh после каждого сохранения: объединяйте изменения в пакеты или рассматривайте другой режим подключения. Типы и ограничения обновления Power BI.

Повторный запуск потока: почему одной проверки на дубль мало

Рассмотрим отдельную операцию «Создать задачу по заявке». Её бизнес-ключ может состоять из ID заявки, вида действия и версии состояния, например request:42:followup:v3. Это пример контракта операции, а не готовое поле триггера Power BI. Версию и допустимость действия процесс должен получать из доверенного источника. Случайный GUID, создаваемый заново при каждом клике, не объединит два одинаковых запроса.

1. Проверьте структуру и число переданных ключей. Для операции над одной заявкой отклоняйте ноль и несколько записей; не берите первую молча.
2. Перечитайте заявку и проверьте полномочия инициатора и текущее состояние. Переданные из отчёта статус и сумма могут быть устаревшими.
3. Попытайтесь атомарно зарегистрировать ключ операции в хранилище с ограничением уникальности. Схема «сначала поиск, затем создание» без такого ограничения допускает гонку двух запусков.
4. Выполните действие и запишите идентификатор созданной задачи вместе с результатом операции.
5. При повторном запросе верните известный результат или статус обработки. Не создавайте новую задачу только потому, что предыдущий ответ не дошёл до пользователя.

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

Такую логику проверяют двумя почти одновременными кликами и искусственным тайм-аутом после внешнего действия. Ожидаемый результат — одна задача или явно отмеченное неопределённое состояние с последующей сверкой. Сообщение «успешно» без ID результата проверить невозможно.

Как отличать сохранение, refresh и появление данных в отчёте

Для поддержки интеграции полезно разделить четыре состояния. Пример ниже описывает последовательность событий, а не обещание фиксированной задержки:

В журнале процесса сохраняйте ID заявки, идентификатор запуска, версию записи и результат внешнего действия. В отчёте полезно выводить время последней успешной загрузки и контрольный признак из источника. Значение NOW() в мере показывает время вычисления, а не момент последнего обновления Import-модели. Если используете максимальную Modified источника, называйте её именно максимальным временем изменения загруженных записей: оно тоже не тождественно времени успешного refresh.

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

Диагностика: где искать причину сбоя

Скачать таблицу приёмочных проверок CSV. В ней оставлены поля для фактического результата, ID запуска и замечаний. Это шаблон для проверки вашей среды, а не отчёт о том, что интеграция уже внедрена.

Автоматические уведомления по порогу

Классические data alerts Power BI service настраивают для поддерживаемых числовых плиток dashboard: card, KPI и gauge. Это не произвольное условие на любой странице Desktop. Оповещения проверяются при обновлении данных, поэтому задержка загрузки влияет и на время уведомления. Оповещения Power BI.

Сначала создайте правило, затем в Power Automate используйте триггер When a data driven alert is triggered, выберите правило и добавьте действие отправки уведомления. Настройте получателя, текст, ссылку на отчёт и условия повторных сообщений. Связь alert с облачным потоком.

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

Рассылка отчётов и экспорт

Для обычной рассылки сначала проверьте возможности подписок Power BI service. Они создаются в сервисе, а не в Desktop. Поток нужен, когда требуется дополнительная логика: другой график, условия, сохранение файла или маршрутизация получателей. Подписки на отчёты.

Действие Export To File for Power BI Reports использует API экспорта и имеет требования к ёмкости. Официальный пример автоматизации предполагает рабочую область на выделенной ёмкости; наличие только Pro не обеспечивает этот сценарий. Для paginated reports используется отдельное действие со своими условиями. Экспорт через Power Automate.

Проверяйте, от чьего имени формируется файл, какие фильтры и ограничения доступа применены и кому он отправляется. Статический PDF сохраняет уже выгруженные данные: последующее изменение роли в Power BI не удалит полученное вложение из почты.

Четыре проверки доступа

1. Отчёт: пользователь открывает нужный Power BI report и видит разрешённые строки.
2. Приложение: canvas app опубликовано и отдельно предоставлено этому пользователю.
3. Источник: подключение допускает только разрешённые чтение и запись; RLS отчёта не переносится автоматически в SharePoint или SQL.
4. Поток: у пользователя есть право запуска, а используемые подключения и действия не дают ему лишних возможностей.

Предоставление доступа к canvas app само по себе не всегда выдаёт доступ к его данным: поведение зависит от коннектора. Настройте доступ к источникам и связанным ресурсам отдельно. Правила совместного использования приложения.

Как принять интеграцию перед запуском

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