Microsoft 365-ryhmiä voi nykyään hyödyntää kattavasti Power Platformin erilaisissa luvituksissa. Muutoksesta ei ole pidettyä isoa meteliä, mutta pidän sitä merkittävänä.
Miksikö?
Useissa organisaatioissa Azure AD -ryhmien luominen on (syystä) hieman byrokraattista. Uusien jäsenien lisääminen ja vanhojen poistaminen AAD-ryhmistä tapahtuu help deskin kautta. Power Platform -ratkaisujen henkeen sopisi kuitenkin paremmin malli, jossa ratkaisun omistaja(t) ja/tai pääkäyttäjät voisivat ylläpitää käytettäviä ryhmiä ja niiden jäseniä omatoimisesti.
Tämä onnistuu käyttämällä AAD-ryhmien sijasta Microsoft 365-ryhmiä.
Käydään tämä läpi esimerkin avulla. Meillä on kaksi sovellusta
- Loppukäyttäjille suunnattu canvas Power Apps
- Model-driven Power Apps ylläpitäjille
Sovellukset käyttävät Dataverseä ja ratkaisulle on luotu oma ympäristö (environment).
Miten hoidamme kaiken ilman AAD-ryhmiä? Otetaan selvää.
Tiimit
Luodaan Teamsiin kaksi tiimiä. Ensimmäisen (My Example App) jäsenenä ovat sovelluksen käyttäjät ja pääkäyttäjät.
Lisätään siis jäseneksi sovelluksen käyttäjä (FF App User).
Tämän jälkeen luodaan oma tiimi (My Example App Admins) pääkäyttäjille.
Tiimi on luonteva paikka tuoda sovellus ja sen käyttäjät yhteen.
- Tiimissä käyttäjät voivat keskustella sovelluksella tehtävästä työstä, sovelluksen jatkokehitystarpeista jne
- Sovellus voi lähettää tiimiin käyttäjille erilaisia ilmoituksia
- Tiimi on luonteva paikka säilyttää sovellukseen ja siihen liittyvän prosessin dokumentaatio
- Myös se itse sovellus löytyy kätevästi tiimistä
Sivutuotteena saamme käyttöömme tiimin takaa löytyvän M365-ryhmän.
Ympäristö (environment)
Luodaan sovellusta varten oma ympäristö. Luonnin yhteydessä asetetaan ympäristöä vastaavaksi käyttöoikeusrooliksi (security group) kaikki sovelluksen käyttäjät kattavan tiimin taustalla oleva M365-ryhmä (My Example App).
Kyllä! Tähän voi käyttää AAD-ryhmän lisäksi myös M365-ryhmää.
Nyt ympäristön käyttäjiksi siirtyvät ainoastaan kyseisen M365-ryhmän jäsenet (joilla on Dataversen käyttöön oikeuttava lisenssi). Kun käyttäjä poistetaan ryhmästä, hänen tunnuksensa passivoidaan Dataversestä.
Sovellukset
Luodaan seuraavaksi kaksi sovellusta. Mallipohjainen (model-driven) Power Apps, joka on tarkoitettu pääkäyttäjille.
Toinen sovellus on loppukäyttäjille suunnattu canvas Power Apps.
Molemmilla selataan ja ylläpidetään yhden oman taulun (My Example App Data) tietoja. Ylläpitosovelluksella ylläpidetään lisäksi My Example App Data 2 -taulun tietoja.
Käyttöoikeudet
Jotta käyttäjät ylipäänsä voivat nähdä ja muokata luomiemme taulujen sisältöjä, tulee heidät liittää käyttöoikeusryhmään, joka tähän antaa oikeuden.
Luodaan molemmille sovelluksille oma käyttöoikeusryhmä (security groups).
- My Example App User = Oikeudet My Example App Data -tauluun
- My Example App Admin = Oikeudet My Example App Data ja My Example App Data 2 -tauluihin
Sovellusten jakaminen
Seuraavaksi voimmekin jo jakaa sovellukset käyttäjille. Hyödyntäen M365-ryhmiä.
Model-driven Power App
Aloitetaan model-driven appsista. Ensimmäisenä määritellään, mitä käyttöoikeusrooleja sovelluksen (My Example App Admin) mukana ylipäänsä voi jakaa. Valitaan käyttöoikeusrooli My Example App Admin.
Jep, olisi voinut antaa kaikille ratkaisun palasille uniikit nimet…
Tämän jälkeen poimitaan People-listasta ylläpitäjien tiimiä vastaava M365-ryhmä (My Example App Admins).
Viimeisenä valitaan vielä ryhmälle annettavat käyttöoikeusroolit.
Valmista!
Vai onko?
Jaon seurauksena käyttäjät saavat Dataverse tiimin kautta välillisesti käyttöoikeusroolin. Se riittää siihen, että käyttäjät pääsevät ylläpitämään taulujen sisältöjä. Mutta se ei tunnu riittävän model-driven sovelluksen avaamiseen. Eli käyttäjälle tulee antaa kyseinen käyttöoikeusrooli vielä käsin.
Toisessa ympäristössä jakaminen taas tuntuu toimivan suoraan. Ehkä vielä jonain päivänä…
Seuraavaksi jaetaan canvas app.
Canvas Power App
Canvas Appsia ei voi jakaa Microsoft 365 -ryhmälle ellei ryhmän security enabled ominaisuus ole päällä.
Oletuksena se ei ole. Sen saa päälle PowerShellillä.
Kas näin.
Nyt voimme jakaa sovelluksen tälle M365-ryhmälle (My Example App). Valitaan samalla mikä käyttöoikeusryhmä (My Example App User) sille annetaan.
Microsoft 365 -ryhmiin perustuvat (Dataverse) tiimit
Sovellukset on jaettu ja sivutuotteena meille syntyi dataverseen kaksi tiimiä. Niiden jäsenyys perustuu M365-ryhmään.
Tiimin jäsenyys tuo mukanaan oikean (jaon yhteydessä määritellyn) käyttöoikeusryhmän.
Sovelluksen toimintojen määräytyminen käyttäjäryhmän perusteella
Ajoittain haluamme lisätä canvas Power Appsiin ominaisuuksia, jotka näkyvät ainoastaan tietylle ryhmälle (esim pääkäyttäjille). M365-ryhmät sopivat tähän käyttöön erinomaisesti.
Tehdään My Example App -sovellukseen painike, joka näkyy ainoastaan My Example App Admins -ryhmän jäsenille.
Lisätään Office 365 Groups tietolähteeksi.
Tarvitsemme vielä tietoomme M365-ryhmän id:n. Se löytyy helpoiten Azure portaalista.
Haetaan sovelluksen käynnistyessä (App OnStart) kokoelmaan (colAdminGroupMembers) My Example App Admins -ryhmän käyttäjien sähköpostiosoitteet .
ClearCollect(colAdminGroupMembers,
Office365Groups.ListGroupMembers("e5308dbe-8293-4930-9331-d6b186e10152").value.mail)
Tämän jälkeen tallennetaan muuttujaan (varIsAdminUser) tieto, löytyykö sovelluksen käyttäjä kyseisestä ryhmästä.
Set(varIsAdminUser, !IsBlank(LookUp(colAdminGroupMembers, mail= User().Email)))Nyt voimme käyttää tätä tietoa hyväksemme sovelluksen sisällä. Esimerkiksi näyttää painike ainoastaan, ylläpitokäyttäjille.
Milloin (Teams) tiimin jäsenestä tulee Dataversen käyttäjä?
Sitten se kiinnostavin osuus.
FF App User on jäsenenä tiimissämme.
Tämä ryhmä on käyttämämme Dataverse-ympäristön käyttöoikeusryhmänä. Samalle ryhmälle on jaettu canvas Power Apps.
Mutta FF App User ei ole kuitenkaan Dataversessä käyttäjänä.
Miksei?
Koska kyseisellä käyttäjällä ei ole Dataversen käyttöön oikeuttavaa lisenssiä. Tämä takia tunnus ei ole automaattisesti siirtynyt Dataversen käyttäjäksi.
Mitä tapahtuu kun FF App User avaa ensimmäistä kertaa hänelle jaetun canvas Appsin? Hänen tulee aktivoida Power Apps premium plan trial. Sillä ympäristössämme ei ole käytettävissä Power Apps per App plan lisenssejä.
Trialin aktivoinnin jälkeen sovellus aukeaa nätisti.
Samalla FF App User ilmestyy myös Dataversen käyttäjäksi.
Hieman hämmentävää tässä voi olla se, ettei itse käyttäjällä näytä olevan mitään käyttöoikeusroolia.
Jopa käyttäjän diagnostiikka valittaa aiheesta.
Sovellus kuitenkin aukeaa ja tiedot näkyvät. Käyttäjä on oikean tiimin jäsen ja tiimi taas antaa käyttöoikeusroolin.
Käyttöoikeusrooli ei vain näy suoraan käyttäjä tiedoissa.
Lisätään vielä käyttäjä FF App Maker ylläpitotiimiin Teamsissa.
Jonka jälkeen hänelle aukeaa ylläpitosovellus nätisti.
Käyttäjien synkronointi tiimistä Dataverseen
Huomasimme että lisensoimattomat käyttäjät luodaan Dataverseen vasta sovelluksen ensimmäisellä käyttökerralla. Entä jos uudella tiimin jäsenellä onkin tarvittava lisenssi? Ilmestyykö hän välittömästi Dataversen käyttäjäksi?
Ei. Vuorokauden sisällä joka tapauksessa.
Tämän takia tiimiin juuri lisätyt käyttäjät eivät ole valittavissa (Dataverse) käyttäjä-listauksissa, mikäli sovelluksessa sellaisia käytetään. Et voi esimerkiksi merkitä riviä käyttäjän X omistukseen, ennen kuin käyttäjä X on dataversessä käyttäjänä.
Tämä voi olla ongelma.
Voit kuitenkin aina synkronoida tiimin jäsenet Dataverseen Flow’lla. Tällöinkään tiimin jäsen ei ilmesty Dataversen käyttäjäksi, mikäli häneltä puutuu lisenssi.
Yhteenveto
Teamsin ja sen takaa löytyvien M365-ryhmien hyödyntäminen tuo helpotusta Power Appsien luvitukseen. Ryhmän security enabled -asetuksen takia ei tämäkään ole täysin IT-vapaa vaihtoehto.
Lähestymisellä on myös omat rajoituksensa. M365-ryhmän sisällä voi olla toisia M365 tai AAD -ryhmiä. Tai voi, mutta niiden jäsenet kopioidaan ryhmän jäseniksi liittämisen yhteydessä.
M365-ryhmä voi olla myös dynaaminen, mutta tämä taas on Azure AD Premium -ominaisuus.
M365-ryhmien hyödyntäminen onkin järkevintä rajatun käyttäjämäärän sovelluksissa, joissa käyttäjiä halutaan hallinnoida ketterästi itse.
Timo Pertilä 