Кожен tenant у Microsoft Power Platform починається з одного середовища за замовчуванням, яким користуються всі користувачі, а потоки, створені з SharePoint, завжди потрапляють саме туди. Ніхто не проєктує цей простір — він просто поступово заповнюється, і до моменту, коли IT переходить до його управління, виконана робота вже перетворюється на міграційний проєкт. Управління Power Platform зводиться до трьох рішень: стратегія середовищ, політики DLP та ліцензування Power Platform. Кожне з них обмежує два інших, тому їх потрібно розглядати разом і в певній послідовності ще до масштабування роботи makers. Власні засоби контролю Microsoft залишають прогалини, які можна закрити лише правильною послідовністю дій. 

У грудні 2022 року Gartner прогнозував, що до 2026 року розробники за межами формальних IT-відділів становитимуть щонайменше 80% користувацької бази інструментів low-code розробки проти 60% у 2021 році (Gartner, Gartner Forecasts Worldwide Low-Code Development Technologies Market to Grow 20% in 2023, 2022). Microsoft Power Platform знижує бар’єр входу саме для таких розробників. Саме тому управління Power Platform — це завдання з проєктування, а не подальшого наведення порядку. Коли сотні застосунків і потоків працюють в одному просторі, кожен новий контроль означає переміщення чиєїсь робочої системи, а власники бізнес-рішень рідко погоджуються на це швидко.

Середовище за замовчуванням має містити лише інструменти для особистої продуктивності та нічого, від чого залежить робота цілого підрозділу. Стратегія середовищ Microsoft для tenant будується на такому розділенні та передбачає перейменування середовища за замовчуванням відповідно до його призначення, наприклад на «Personal Productivity Environment». Критично важливі для бізнесу рішення мають розміщуватися в окремих середовищах розробки, тестування та production, а маршрутизація середовищ за замовчуванням (default environment routing) спрямовує нових makers до їхніх власних середовищ розробника, завдяки чому спільний простір перестає заповнюватися. 

Managed Environments роблять таку структуру керованою та контрольованою завдяки обмеженням спільного доступу, щотижневій аналітиці використання, pipeline для переміщення рішень між етапами та solution checker. Environment groups застосовують правила одразу до багатьох середовищ, але лише до керованих: кожне середовище належить до однієї групи, а групи не можуть бути вкладеними. 

Політики роботи з даними (DLP) розподіляють кожен конектор за категоріями Business, Non-Business або Blocked. Відповідно до правил класифікації конекторів, один застосунок або потік може використовувати конектори Business або Non-Business, але ніколи обидві категорії одночасно, і взагалі не може використовувати заблокований конектор. Політики на рівні середовища не можуть перевизначати політики на рівні tenant. Microsoft рекомендує встановлювати для конекторів, які додаються пізніше, категорію Non-Business за замовчуванням, доки хтось їх не перевірить.

Два обмеження визначають, наскільки далеко політики DLP можуть забезпечити вашу модель управління. Стандартні конектори Microsoft неможливо заблокувати, тому їх можна класифікувати лише як Business або Non-Business, але не вимкнути. Політики DLP також не можуть визначити, чи вказує підключення на систему розробки, тестування або production — це розділення має забезпечувати структура середовищ. Саме тому ці два рішення не можна проєктувати окремо. 

Ліцензування Power Platform поєднує окремі користувацькі ліцензії, такі як Power Apps Premium, ліцензії на основі capacity та pay-as-you-go лічильники, які виставляють рахунок за відповідне використання середовища через підписку Azure, як пояснюється в огляді ліцензування Microsoft Power Platform. Деякі ліцензії Microsoft 365 включають обмежені права на Power Apps і Power Automate, але лише для даних Microsoft 365 та стандартних конекторів. Починаючи з 2 січня 2026 року, план Power Apps per app більше не доступний для нових клієнтів через деякі канали придбання. 

Архітектурний зв'язок проявляється в ліцензуванні Managed Environments: щойно середовище стає керованим, кожному активному користувачу потрібна premium-ліцензія або capacity add-on, включно з користувачами, які раніше запускали ті самі застосунки, використовуючи лише права Microsoft 365. Тому ввімкнення Managed Environments є не лише рішенням щодо управління Power Platform, а й рішенням щодо її ліцензування. Послуги OntargIT з ліцензування програмного забезпечення охоплюють вибір відповідних ліцензій до такого переходу. 

Рішення потрібно приймати в чіткій послідовності:

1. Спроєктувати топологію середовищ — визначити, що залишається у середовищі за замовчуванням, які підрозділи отримують середовища розробки, тестування та production і куди маршрутизація спрямовує нових makers.
2. Визначити, які середовища стануть керованими, попередньо перевіривши статус ліцензій кожного активного користувача.
3. Створити політики DLP на рівні tenant, додаючи політики на рівні середовищ лише там, де певній групі середовищ потрібні жорсткіші правила.

Порушення цієї послідовності передбачувано створює проблеми в управлінні Power Platform. Політика DLP, написана першою, не може відокремити середовище розробки від production. Увімкнення Managed Environment до перевірки ліцензій призводить до того, що користувачам, які мали лише права Microsoft 365, потрібна окрема ліцензія для застосунків, якими вони користувалися ще напередодні. Microsoft Power Platform надає адміністраторам усі необхідні засоби контролю; порядок їх застосування є архітектурним рішенням і має бути частиною плану впровадження.

Управління Power Platform працює тоді, коли всі три рішення приймаються як єдина модель: середовища відокремлюють особисту роботу від production, Managed Environments визначають, кому потрібна premium-ліцензія, а політики DLP встановлюють межі використання конекторів у межах цієї структури. Перегляньте всі три аспекти до того, як наступний підрозділ почне розробку.