Power Platform on useissa organisaatioissa otettu työntekijöiden toimesta jo käyttöön. Kaikki on mukavaa ja helppoa, kun voi mellastaa oletusympäristössä (Default environment). Se ei kuitenkaan pidemmän päälle toimi. Nopeasti on tarpeen miettiä, mitä Power Platform ympäristöjä tarvitaan ja mikä kunkin ympäristön käyttötarkoitus on (environment strategy).

Hallintamielessä moni asia on suoraviivaista, jos kullakin ratkaisulla on omat ympäristönsä (dev/test/prod). Kuten esimerkiksi Dynamics 365:llä tyypillisesti on.

Valtava määrä ympäristöjä ei kuitenkaan ole mikään ratkaisu. Niiden hallinta on oma työnsä. Ja ympäristöt maksavat. Mikä tärkeintä, tämä estää tietojen tehokkaan uudelleenkäytön ympäristöjen kesken.

Kuvitellaan tilanne, jossa meillä on kolme sovellusta. Kukin omassa ympäristössään. Yksi liittyy asiakkaisiin (accounts), toinen projekteihin (projects) ja kolmas laskutukseen (invoices).

Käytännössä eri ympäristöissä sijaitsevat taulut sisältävät tietoja, joita myös muut sovellukset tarvitsevat. Onkin houkutteleva ajatus luoda jaettu ympäristö.

Näin (kansalais)kehittäjät eivät luo jokaiseen ympäristöön samoja projekti jne. tauluja ja rakenna samoja integraatioita samoille tiedoille.

Erilaiset jaetut ympäristöt ovat keskeisessä roolissa myös Microsoftin esimerkeissä.

Liputan itsekin niiden puolesta.

Harvemmin kuitenkaan kerrotaan, mitä jaetut ympäristöt käytännössä tarkoittavat. Niiden hallinta ei nimittäin ole aivan mutkatonta.

Ongelma – Kehittäjien käyttöoikeudet

Jaettujen ympäristöjen keskeisin haaste on mielestäni käyttöoikeudet. Power Platform perustuu Dynamics 365:een, jossa ei ole ollut tarvetta rajoittaa tekijöiden käyttöoikeuksia kovinkaan tarkasti ympäristön sisällä.

Käytännössä kehittäjät saavat jaettuun ympäristöön joko liikaa tai liian vähän käyttöoikeuksia.

Mitä vaihtoehtoja meillä sitten on kehittäjien käyttöoikeuksien suhteen?

Järjestelmän mukauttaja (System Customizer) -oikeudet

Annetaan kehittäjille ympäristöön järjestelmän mukauttaja (System Customizer) -oikeudet.

Näin he näkevät kaikki ympäristön taulut ja pääsevät luomaan tarvitsemansa uudet taulut itse.

Kiva. Mutta nyt kehittäjät voivat muokata ympäristön kaikkia tauluja sekä muita resursseja (Power Appsit, Flow’t, ratkaisupaketit, yhteysviittaukset jne). Kaikkia. Ei siis ainoastaan itse luomiaan vaan kaikkia.

Vakiotauluista (Account, Contact jne) he näkevät vain itse luomansa rivit. Muiden taulujen osalta heillä on täydet oikeudet myös sisältöön. He voivat siis lukea muiden kehittäjien luomien taulujen kaikki sisällöt. Ja halutessaan vaikkapa poistaa niistä rivejä.

He eivät sentään muokata käyttöoikeusrooleja tai antaa muille käyttäjille käyttöoikeusrooleja.

Mutta on tämä silti villiä.

Tätä roolia käytettäessä ainoaksi vaihtoehdoksi jää kuvata malli, miten ympäristösssä toimitaan. Käytännössä se menee näin.

Älä koske muiden luomiin tauluihin. Mikäli löydät jotain kiinnostavaa, jota haluaisit hyödyntää omassa ratkaisussasi, selvitä kuka sen osuuden omistaa ja sovi hänen kanssaan asiasta.

Tekijät sitoutuvat tähän ja sitten luotetaan että näin myös toimitaan. Sillä mikäli tauluuni ilmestyy ”jostain” yksikin uusi pakollinen kenttä, olen nopeasti hankaluuksissa.

Malli sopii tilanteeseen, jossa ympäristössä ei ole luottamuksellista dataa, kehittäjiä on suhteellisen pieni määrä, he tietävät mitä tekevät ja luottavat toisiinsa.

Rajoitettu järjestelmän mukauttaja (Limited System Customizer) -oikeudet

Emme millään haluaisi luopua mallista, jossa kehittäjät luovat tarvitsemansa taulut itse.

Entä jos tekisimme uuden, hieman muokatun, järjestelmän mukauttaja -roolin? Tätähän mainostetaan myös dokumentaatiossa.

By default, system customizers have full access to custom entities. If you want to have the same limitations that exist for system entities, you’ll need to adjust the system customizer security role so that the access level is User rather than Organization for custom entities.

https://docs.microsoft.com/

Nopeasti luettuna kuulostaa hyvältä. Muttei ole. Idea on siis luoda kopio järjestelmän mukauttaja -roolista ja ottaa siltä pois organisaatiotason oikeudet muiden luomiin tauluihin. Eli vaihtaa vihreät pallot keltaisiksi (oikeus vain omiin riveihin) tai jättää kokonaan tyhjiksi (ei minkäänlaisiaoikeuksia sisältöön).

Ja sitten ympäristössä toimiville kehittäjille annetaan tämä käyttöoikeusrooli.

Se ei kuitenkaan rajoita kehittäjän oikeuksia tehdä muutoksia ympäristön tauluihin ja resursseihin. Ainoa ero edelliseen on se, ettei kehittäjä näe muiden luomien taulujen sisältöä.

Mitä tapahtuu kun ympäristöön luodaan uusi taulu? Kaikki järjestelmän muokkaajat, myös ne joilla on tämä luomamme rajoitettu muokauttajarooli, saavat täydet oikeudet kyseiseen tauluun. Se siitä sitten.

Kuka seuraa ympäristöjä aktiivisesti ja käy siivoamassa käyttöoikeusrooleja sitä mukaa, kun ympäristöön ilmestyy uusia tauluja? Ei kukaan.

Malli sopii tilanteeseen, jossa ympäristössä on muutamia tauluja joiden sisältöjen näkyvyyttä kehittäjille halutaan rajoittaa. Muilta osin kehittäjät saavat nähdä kaiken.

Ympäristön tekijä (Environment Maker) -oikeudet

Kolmantena vaihtoehtona on antaa kehittäjille ympäristön tekijä (Environment Maker) -oikeudet. Näin he voivat luoda sovelluksia ja työnkulkuja. He näkevät kaikki ympäristön taulut, mutta heillä ei ole niihin mitään oikeuksia.

Mikäli he haluavat käyttää ratkaisussaan ympäristössä jo olevia tauluja, heidän tulee pyytää tätä varten uusi käyttöoikeusrooli, jolle lisätään oikeudet kyseisiin tauluihin.

Mikäli kehittäjä tarvitsee ratkaisuaan varten uusia tauluja, hänen tulee pyytää ympäristöstä vastaavan luomaan ne. Mikäli hän tarvitsee omiin tauluihinsa uusia kenttiä, hänen tulee pyytää ympäristöstä vastaavan lisäämään ne. Jne.

Ei kuulosta järin ketterältä. Jokainen tuntemani SharePointia käyttänyt kansalaiskehittäjä on luonut tarvitsemansa listat ja niiden sarakkeet itse.

Kehittäjien oikeudet tuotantoympäristöön?

Edelläkuvattua tuskaa helpottaa hieman, kun ajattelee kyseessä olevan kehitys/testiympäristön, jossa ei ole luottamuksellista sisältöä.

Mutta mitä oikeuksia kehittäjillä tulisi olla tuotantoympäristöön?

Aloitetaan helposta. Voidakseen jakaa tuotantoympäristössä olevan sovelluksen muiden käyttöön, tulee olla kyseisessä ympäristössä käyttäjänä ja omata ympäristön tekijä (Environment Maker) -käyttöoikeusrooli.

Se on iso rooli henkilölle, joka vain hallitsee sovelluksen käyttäjiä. Suuntaisin katseet malliin, jossa sovellusten jakamisessa hyödynnetään AAD/M365 -ryhmiä.

Entä kuka siirtää ratkaisupaketit testistä tuotantoon?

Jotta ympäristöön voi tuoda ratkaisupaketin, tarvitsee käyttäjä kohdeympäristöön järjestelmän muokkaaja (System Customizer) -oikeudet.

Jep. Juuri ne, joilla näkee ympäristöstä kaiken sisällön. Mikäli tuotannossa on dataa, jota kehittäjät eivät saa nähdä, on vaihtoehtoja kaksi.

  1. Luodaan tuotantoon oma käyttöoikeusroolinsa ratkaisupaketin tuontia varten
  2. Ratkaisupaketit tuodaan tuotantoon keskitetysti tahon x toimesta

Vaihtoehto kaksi kuulostaa paremmalta. Harvassa organisaatiossa on tähän kuitenkaan vielä kykyä. Aikaa tai osaamista tai kumpaakaan.

Yhteenveto

Power Platform ympäristöjä ei ole alunperin suunniteltu käyttötapaan, johon niitä parhaillaan ajetaan. Toivon että näemme nopeasti päivän, jolloin ympäristön sisällä voi hallita kehittäjien käyttöoikeuksia nykyistä tarkemmin. Tämä mahdollistaisi kansalaiskehittäjille tarkoitetut jaetut ympäristöt ilman huolta siitä että joku tekee epähuomiossa jotain tyhmää.

Tämän kanssa on kuitenkin pärjätty. Kunhan pitää myös tämän ulottuvuuden mielessä organisaatioiden ympäristöjä suunnitellessa.

Keitä ympäristön kehittäjät ovat ja saavatko he nähdä ympäristön sisällä kaiken?

Useimmiten mitään ongelmaa ei lopulta ole.