Один отчёт публикуется в пару кликов. Но когда отчётов десятки, авторов несколько, а потребителей сотни — нужен порядок: кто редактирует, кто только смотрит, где «черновики», а где «прод». За это в Power BI Service отвечают рабочие области (workspaces), роли и приложения.
Это не про DAX, а про организацию публикации в Power BI Service — слой, без которого командная эксплуатация превращается в хаос из личных «Моя рабочая область».
Рабочая область (workspace)
Workspace — это контейнер для связанных отчётов, датасетов (семантических моделей), дашбордов и дэшфлоу. Это рабочая «комната» команды: здесь авторы вместе ведут содержимое. Личная «Моя рабочая область» — только для черновиков одного человека; командное всегда живёт в общих workspace.
Доступ выдаётся не к отдельному отчёту, а к рабочей области целиком — через роли. Поэтому контент группируют по командам/доменам (например, «Финансы», «Продажи»), а не сваливают в одну область. Структура workspace = структура ответственности.
Четыре роли в workspace
| Роль | Что может |
|---|---|
| Admin | всё + управлять доступом и удалять область |
| Member | публиковать, редактировать, делиться, добавлять людей (кроме админских действий) |
| Contributor | создавать и редактировать контент, но не управлять доступом |
| Viewer | только просматривать содержимое области |
Авторам дают Contributor/Member, потребителям — Viewer (или, лучше, доступ через приложение, см. ниже).
Приложение (app) — для потребителей
Workspace — «кухня» авторов. Показывать сырую кухню сотням пользователей не нужно. Из workspace публикуют приложение (app) — причёсанную витрину: выбранные отчёты, навигация, единый доступ.
Потребителям выдают доступ к приложению, а не к рабочей области. Так читатели видят только готовое и оформленное, а черновики и технические датасеты остаются в workspace. Плюс приложением проще управлять: одна аудитория, один набор разрешений, обновляемая витрина.
Сертификация и продвижение датасетов
Когда одну семантическую модель переиспользуют многие (см. урок про SSAS/общие модели), важно отличать «официальную» от чьего-то эксперимента. Для этого есть endorsement:
- Promoted (продвинутая) — автор отмечает модель как рекомендуемую;
- Certified (сертифицированная) — прошла проверку уполномоченных лиц, «золотой источник».
Сертифицированные модели всплывают первыми и помечены значком — пользователь понимает, какой источник правды брать.
Частая беда: критичный отчёт опубликован в личной «Моей рабочей области» автора. Уволился человек / нет доступа — и отчёт недоступен, прав не передать, бэкапа нет. Всё, чем пользуется команда, должно жить в общей рабочей области с несколькими админами, а раздаваться через приложение. Личная область — только черновики.
Что дальше
Контент организован и роздан. Дальше — как безопасно проводить изменения из разработки в прод, не ломая боевые отчёты: deployment pipelines. Следующий урок.