Siirrä sovelluksia ja työnkulkuja oletusympäristöstä

Tässä raportissa selostetaan, miten organisaatiot ja järjestelmänvalvojat voivat suunnitella sovellustensa ja työnkulkujensa siirtämistä oletusympäristöstä.

Tekijät: Ravi Chada (Microsoft), Rui Santos (Microsoft)

Muistiinpano

Voit tallentaa tai tulostaa tämän teknisen raportin valitsemalla selaimesta Tulosta ja valitsemalla sitten Tallenna PDF-tiedostona.

Oletusympäristö

Kullekin vuokraajalle luodaan automaattisesti yksi oletusympäristö. Oletusympäristön käyttöoikeudet annetaan kaikille käyttäjille kyseisessä vuokraajassa. Oletusympäristö luodaan Microsoft Entra -vuokraajan oletusaluetta lähinnä olevalle alueelle ja nimeksi annetaan [Microsoft Entra -vuokraajan nimi] (oletus). Aina, kun uusi käyttäjä kirjautuu Power Appsiin tai Power Automateen, käyttäjä lisätään automaattisesti oletusympäristön tekijän rooliin. Oletusympäristön ympäristön järjestelmänvalvojan rooliin ei lisätä käyttäjiä automaattisesti.

Oletusympäristöä ei voi poistaa eikä oletusympäristöä voi varmuuskopioida manuaalisesti. Järjestelmää varmuuskopioidaan jatkuvasti. Oletusympäristö on rajoitettu 1 teratavuun tallennustilaa. Oletusympäristössä on seuraavat ominaisuudet:

• 3 Gt Dataverse-tietokantakapasiteettia
• 3 Gt Dataverse-tiedostokapasiteettia
• 1 Gt Dataverse-lokikapasiteettia

Ennen uusien ympäristöjen luomista tehty kapasiteetin tarkistus sulkee pois ympäristön oletusympäristön sisällytetyn tallennuskapasiteetin, kun lasketaan, onko kapasiteettia riittävästi uuden ympäristön luomiseen. Jos tallennettavia tietoja on enemmän, voit luoda tuotantoympäristön.

Oletusympäristössä Microsoft 365 -käyttöoikeuden omaavan organisaation työntekijät voivat luoda sovelluksia ja pilvivirtoja. Oletusympäristöstä tulee näiden työntekijöiden ensimmäinen ympäristö, jossa he voivat aloittaa sovellustensa ja työnkulkujensa rakentamisen. Koska ympäristön tekijäroolia ei voi poistaa oletusympäristöstä, tekijät voivat kehittää henkilökohtaisia tuottavuussovelluksia ja -työnkulkuja ja jakaa niitä tiimeilleen muiden hyödyksi. Useimmat organisaatiot antavat oletusympäristölle nimen Henkilökohtainen tuottavuus.

Jälkeenpäin järjestelmänvalvojat havaitsevat, että oletusympäristössä on luotu useita sovelluksia ja työnkulkuja. Sovelluksen tai työnkulun ei ehkä pitäisi olla oletusympäristössä esimerkiksi seuraavissa skenaarioissa:

• Sovellus jaetaan useille käyttäjille tuotantotyyppisesti.
• Sovellus käyttää Excel-työkirjoja, joissa on luottamuksellisia tietoja.
• SharePoint-luetteloihin perustuvassa sovelluksessa on paljon tietojen vuorovaikutuksia, kuten lisäyksiä tai päivityksiä.
• Sovellus tai työnkulku käyttää yhdistimiä, jotka eivät ole sallittuja uusissa tietojen menetyksen estämisen (DLP) käytännöissä.
• Mukautetut yhdistimet otetaan käyttöön ja niitä käytetään oletusympäristössä sen sijaan, että ne olisi suojattu erillisessä ympäristössä.

Edellä mainitut skenaariot kannattaa ottaa huomioon, ja niiden perusteella on syytä aloittaa näiden sovellusten ja työnkulkujen siirtäminen oletusympäristöstä omaan kehittäjäympäristöön tai toiseen jaettuun ympäristöön. Muita huomioon otettavia tekijöitä ovat oletusympäristöön liittyvät rajoitukset.

Osaamiskeskus (CoE) -tiimit, jotka valvovat Power Platformia, on reagoitava rajojen ylittämiseen. Tämä vaikuttaa negatiivisesti oletusympäristössä suoritettaviin sovelluksiin. Tämä rajoitus voi olla jotain, jonka järjestelmänvalvojan tai CoE-tiimin on tarkistettava säännöllisesti. Pääasiallisia vaiheita on kolme:

• Power Platform -objektien tunnistaminen
• Power Platform -objektien siirtäminen
• Power Platform -objektien tyhjentäminen

Sovelluksia ja työnkulkuja voi viedä ja siirtää uuteen ympäristöön eri tavoin. Ratkaisut ovat yksittäisiä tiedostoja, joka voi sisältää lähes mitä tahansa, mitä tekijät rakentavat Power Platformissa. Ratkaisujen avulla tämä kaikki voidaan siirtää yhdessä. Peruspohjasovellukset ja pilvivirrat voidaan viedä suoraan.

Ajan mittaan Power Platform -objektit ovat kehittyneet ratkaisutietoisiksi. Sovellukset ja työnkulut voivat nyt olla ratkaisutietoisia oletusarvoisesti, mutta tämä edellyttää manuaalista aktivointia. Tekijät voivat osoitteissa make.powerapps.com ja make.powerautomate.com edelleen luoda sovelluksia ja työnkulkuja, jotka eivät ole ratkaisutietoisia, ja ne voidaan viedä yksitellen tai lisätä ratkaisuun. Lisäämällä ratkaisun tekijä voi hyödyntää ympäristön muuttujia ja yhteysviittauksia päätepisteiden määrittämiseen ja käyttöönottoon eri ympäristöissä.

Tavoitteena on lisätä kaikki Power Platform -osat yhteen ratkaisuun, jolloin useita osia on helppo siirtää yhtenä yksikkönä ympäristöjen välillä.

Power Platform -objektien tunnistaminen

Ensimmäinen vaihe on tunnistaa sovellukset, työnkulut ja resurssit, jotka on siirrettävä tai tyhjennettävä. CoE Starter Kit sisältää luettelon kaikista sovelluksista ja työnkuluista, ja Power BI -raportit auttavat määrittämään käytön. Tässä vaiheessa voit arvioida sovelluksen käyttöä ja antaa niille otsikoita. Kun käyt harjoituksen läpi, merkitse sovellukset ja työnkulut, jotka on siirrettävä toiseen ympäristöön. Tunniste voi perustua käytettyihin yhdistimiin, käyttäjän sijaintiin, käyttäjän osastoon jne. Tässä artikkelissa on myös kuvattu menetelmä, jolla voi tunnistaa kohteita, jotka tulisi poistaa tai sijoittaa uudelleen tietojen menetyksen estämisen (DLP) käytäntöjen perusteella.

Power Platform -objektien siirtäminen

Jos komponentti on merkitty tunnisteella siirrettäväksi toiseen ympäristöön, voit siirtää sovelluksen eri tavoilla. Siirto on vuorovaikutteinen prosessi, ja se edellyttää jonkin verran tekijän vuorovaikutusta. Sovelluksen tai työnkulun siirtämisen monimutkaisuus kasvaa, kun sovelluksen tai työnkulun rakentamisessa käytetään useampia erilaisia osia.

Esimerkiksi sovelluksessa, jossa on kuusi näyttöä, on 10 painiketta useissa näytöissä. Oletetaan, että nämä 10 painiketta kutsuvat kukin yksittäistä työnkulkua. On luotu myös muutama työnkulku käynnistymään päivittäin tietojen korjaamiseksi tai tietojen integroimiseksi toiseen järjestelmään. Oletetaan myös, että automaation osana on käytössä AI Builder -kuvien käsittelymalli. Jos haluat siirtää tällaisen sovelluksen, kaikki osat on lisättävä ratkaisuun, ja yhteysviittaukset on säädettävä oikein ja testattava ennen valmistumisen vahvistusta.

Oletetaan toisessa tapauksessa, että on olemassa pohjasovellus, joka käyttää Office 365 -yhteyttä. Tässä tapauksessa tekijän tarvitsee lisätä ratkaisuun vain pohjasovellus.

Power Platform -objektien tyhjentäminen

Jos osa on merkitty tyhjennettäväksi, päävaihtoehtoja on kaksi. Ensimmäinen vaihtoehto on poistaa se suoraan, ja toinen vaihtoehto on poistaa se varmuuskopion ottamisen jälkeen. Varmuuskopion tapauksessa osa vaiheista saattaa olla päällekkäisiä objektien siirtämisen kanssa.

Esimerkiksi CoE-tiimin järjestelmänvalvojat voivat huomata, että useimmat tekijät luovat testisovelluksia ja -työnkulkuja oppimista varten. Tämän jälkeen tekijät hylkäävät sovellukset ja työnkulut, mikä voidaan vahvistaa tarkastelemalla käyttömittareita. Toinen tapa on asettaa sovellus karanteeniin. Jos kukaan ei ota yhteyttä sovellukseen liittyen, sovellus voidaan myös poistaa.

Viestintästrategian ylläpitäminen on tärkeää. Järjestelmänvalvojien tulee suunnitella yhteydenpitoa:

• Luoda yhteydet, jotka tekijöiden on sallittava, kun he käynnistävät sovelluksen uudessa ympäristössä.
• Sovelluksen uusi URL-osoite kohdeympäristöstä.
• Siirtyminen oikeaan ympäristöön.

Jotkin näistä objektien uudelleensijoituksen ratkaisuista ovat käyttövalmiita, ja ne voivat edellyttää erilliset Power Apps- ja Power Automate -käyttöoikeudet, joiden avulla käyttäjät voivat luoda ja suorittaa sovelluksia eri tietolähteissä, jotka laajenevat Microsoft 365:n ulkopuolelle.

Strategiat

Sovellusten tunnistamisen ja siirtämisen prosessi oletusympäristöstä onnistuu todennäköisemmin strategian avulla. Huomioon on otettava useita strategioita.

DLP-strategia

Tietojen menetyksen estämisen (DLP) käytännöt toimivat varmistuksina, joilla estetään käyttäjiä paljastamasta organisaation tietoja tahattomasti ja suojataan tietoturvaa vuokraajassa. DLP-käytännöt panevat täytäntöön sääntöjä siitä, mitkä yhdistimet otetaan käyttöön kullekin ympäristölle ja mitä yhdistimiä käytetään yhdessä. Yhdistimet luokitellaan seuraavasti: vain liiketoimintatiedot, ei liiketoimintatietoja tai estetty. Vain liiketoimintatietojen ryhmän yhdistintä voi käyttää vain muiden saman ryhmän yhdistimien kanssa samassa sovelluksessa tai työnkulussa. Suosittelemme, että sinulla on vähintään yksi käytäntö.

Objektien tunnistaminen DLP:n avulla

DLP-käytäntöpohjainen tunnistaminen auttaa määrittämään sovellusten ja työnkulkujen kohdeympäristöt. Saattaa olla sovelluksia tai työnkulkuja, jotka käyttävät DLP:n estämiä yhdistimiä tai yritysyhdistinten ja muiden kuin yritysyhdistinten yhdistelmää, joka lakkaa toimimasta DLP:n aktivoinnin jälkeen.

CoE Starter Kitiin kuuluu DLP-editori (vaikutusanalyysi) -työkalu, joka voi auttaa estämään mahdollisten tärkeiden objektien DLP:n aiheuttamat käyttökatkokset. DLP-editorin tavoitteena on antaa järjestelmänvalvojien nähdä nykyisten käytäntöjen vaikutukset tai käytäntömuutosten mahdolliset vaikutukset. Se tarjoaa järjestelmänvalvojille näkymän sovelluksiin, työnkulkuihin ja resursseihin, joihin muutos vaikuttaa ja jotka poistetaan käytöstä, jos uudet tai päivitetyt käytännöt pakotetaan. Sovelluksella voidaan tarkastella olemassa olevia käytäntöjä, muuttaa olemassa olevia käytäntöjä ja vähentää riskejä ottamalla yhteyttä tekijöihin ja tiedottamalla heille sovellukseen tai työnkulkuun liittyvistä parhaista toimintatavoista.

Voit tarkistaa vaikutukset päivittämällä aiemmin luodut DLP-käytännöt. Lisätietoja DLP-editorista on artikkelissa Vuokraajan hygienian määrittäminen CoE Starter Kitin avulla.

Ennen kuin otat DLP-ominaisuuden käyttöön, voit tunnistaa, mihin sovelluksiin ja työnkulkuihin muutos vaikuttaa, ja ilmoittaa siitä tekijöille. DLP-editori voi lähettää sähköpostiosoitteeseen luettelon kaikista sovelluksista ja työnkuluista, joihin muutos vaikuttaa. Tämä luo .csv-tiedoston kullekin objektityypille.

Valitse DLP-editorin versiossa 2.0 Vaikutusanalyysi-alueessa Vie muutokseen liittyvät sovellukset ja työnkulut CSV-tiedostoon.

Kussakin luodussa csv-tiedostossa (flow.csv ja apps.csv) on seuraavia tietoja:

1. Sovellusten ja työnkulkujen nimet.
2. Sovellusten ja työnkulkujen omistajat.
3. Sovellusten ja työnkulkujen omistajan sähköpostiosoite.
4. Kaikki sovellusten ja työnkulkujen käyttämät yhteydet.
5. Sovellusten ja työnkulkujen tunnukset objektien tunnistamiseksi.
6. Sen ympäristön tunnus, jossa sovellukset ja työnkulut sijaitsevat.

Huomaa, että Yhteydet-kohdassa on luettelo kaikista sovelluksen tai työnkulun käyttämistä yhteyksistä. Jos sinun on määritettävä tarkasti, mihin yhdistimeen kyseessä oleva DLP vaikuttaa, automatisointi on tarpeen. Arvioimme tämän tilanteen muuttamista työkalussa.

Esimerkki toteutuksesta yhteyden tunnistamiseksi:

1. Power Automate -työnkulun luominen.

2. Käytä Get Tenant DLP Policy -yhdistintä, joka määrittää kyseisen DLP:n.

3. Tuloksena on kaksi matriisia, yritystietoja ja muita kuin yritystietoja. Twitter-yhdistin näyttää esimerkiksi tämän koodin:

   [
     {
       "id": "/providers/Microsoft.PowerApps/apis/shared_twitter",
       "name": "Twitter",
       "type": "Microsoft.PowerApps/apis"
     }
   ……
   ]
   

4. Tästä luettelosta voit käyttää yhdistimen nimeä, joka vastaa sovelluksen tai työnkulun csv-tiedoston Yhteys-sarakkeen nimiluetteloa.

5. Muuntamalla csv-tiedoston Excel-muotoon ja sijoittamalla sen OneDriveen voit lukea kaikki liittyvät sovellukset ja työnkulut Power Automatesta. Tarkista, mihin yhteyteen muutos vaikuttaa, perustuen logiikkaan, joka vertaa yhteyksiä yhdistimien nimiin.

6. Kun olet löytänyt vastineen sille, mihin yhteyteen muutos vaikuttaa, luo uusi luettelo sovelluksen tai työnkulun tunnuksen avulla ja käyttämällä yhdistintä, johon DLP vaikuttaa.

7. Aiempien tietojen avulla voit ilmoittaa tekijälle tulevista vaikutuksista. Power Cards -kortteja käyttämällä voit kerätä palautetta tekijältä, jos sovellus tai työnkulku voidaan poistaa tai se on siirrettävä toiseen ympäristöön.

Jos analyysin perusteella päätät, että muutokseen liittyviä työnkulkuja ei käytetä, voit asettaa ne karanteeniin ja lähettää tekijälle sähköpostiviestin, jossa on ohjeet työnkulkujen siirtoon toiseen ympäristöön. Tämä kannustaa tee se itse (DIY) -kulttuuria ja eliminoi varjo-IT:n. Joissakin tilanteissa jotkin objektit kannattaa ehkä vapauttaa DLP-käytännöstä. Voit esimerkiksi ottaa käyttöön tietyn DLP:n vain uusille luoduille resursseille ja vapauttaa nykyiset resurssit. Lisätietoja resurssien vapauttamisesta DLP:stä on ohjeaiheessa DLP – resurssien vapauttaminen.

Ympäristöstrategia määritetään tehokkaasti DLP:n avulla ja se tarjoaa kohteen oletusympäristössä kehitettyjä sovelluksia ja työnkulkuja varten.

Ympäristöstrategia

Ympäristöstrategian laatiminen edellyttää ympäristöjen ja muiden tietoturvatasojen määrittämistä tavalla, joka tukee tuottavaa kehitystä organisaatiossa samalla varmistaen ja organisoiden resursseja. Strategia ympäristöjen valmistelemista ja käyttöoikeuksien hallintaa sekä niiden sisältämien resurssien valvontaa varten on tärkeä seuraavista syistä:

• Tietojen ja käyttöoikeuksien suoja.
• Hallitse oletusympäristöä yhteensopivalla tavalla.
• Asianmukaisen ympäristömäärän hallinta hajautumisen ehkäisemiseksi ja kapasiteetin säästämiseksi.
• Terveen sovellusten elinkaaren hallinnan (ALM) edistäminen ja toteuttaminen.
• Resurssien järjestäminen loogisiin osioihin.
• Toimintojen (ja tukipalvelun) tukeminen tuotannossa olevien sovellusten tunnistamisessa siten, että niitä pidetään erillisissä ympäristöissä.
• Sen varmistaminen, että tiedot tallennetaan ja siirretään hyväksyttäville maantieteellisille alueille (suorituskyvyn ja vaatimustenmukaisuuden syiden vuoksi).
• Kehitettävien sovellusten eristyksen varmistaminen.
• Sisäisten laskutuspalveluiden käyttöönotto yrityskäyttäjille tai palveluja käyttäville liiketoimintayksiköille.

Sinulla olisi oltava hyvin määritetyt osastot, jotka voivat olla omavaraisia ja joissa on käytössä ALM-prosessit. Tällöin ympäristöt tarjoavat mahdollisuuden eristämiseen ja resurssien järjestämiseen osaston mukaan. Tähän perustuva strategia luodaan luomalla kullekin osastolle erilliset ympäristöt. Näistä ympäristöistä tulee sitten oletusympäristön sovellusten ja työnkulkujen kohde.

Viestintästrategia

Tehokas viestintä on tärkeää siirtoprosessin aikana. Yhteydenpito tapahtuu siirtoprosessin kaikissa vaiheissa. Selkeä viestintä edistää sidosryhmien ymmärtämistä ja yhteistyötä. Se mahdollistaa sujuvan tiedonkulun ja varmistaa, että kaikille osallisille tiedotetaan hyvin siirtosuunnitelmista, edistymisestä ja mahdollisista haasteista.

Varmista siirto- ja tyhjennysprosessin yhteydessä, että prosessi on sujuva tekijöille, sidosryhmille ja johdolle. Kehitä strategia, jonka avulla yhteydenpitoa voidaan parantaa ja nähdä missä pisteissä pitää kommunikoida. Tämä varmistaa tavoitteiden yhdenmukaisuuden ja auttaa viestinnässä kaikille osallisille. Joitakin huomioon otettavia vaihtoehtoja:

• Käytä CoE Starter Kit -pakettia resurssien seurantaan.
• Lisäämällä mukautettuja pilvivirtoja voit lähettää ilmoituksia eri vaiheissa.
• Luo mallisähköpostiviestit, jotka lähetetään viestinnässä tekijöille.

Huomioitavia seikkoja:

• Muutos sovelluksen URL-osoitteessa. Sovelluksen käyttäjien on päivitettävä kirjanmerkit sovellukseen oletusympäristössä.
• Jos URL-pohjainen HTTP-käynnistinkulku on olemassa, se on päivitettävä riippuvaisiin työnkulkuihin, jotta se toimii edelleen webhookina.
• Määritä yhteyksien muodostamista koskevat yksityiskohtaiset vaiheet, kun siirto on valmis sekä tekijöille että sovelluksen käyttäjille. Käyttäjien ei pitäisi olla huolissaan yhteyden luomisesta, kun he käynnistävät sovelluksen ensimmäisen kerran uudessa ympäristössä.

Hyvä alku viestinnälle edellyttää, että skaalaamiseen on käytettävissä itsepalvelumalli, joka on käyttäjille reaaliaikaisempi kuin yksittäisen käyttäjän sähköposti tai jakeluluettelo. Jos aiot luoda SharePoint-sivuston, käytettävissä on malli, jonka avulla voit luoda sisäisen Microsoft Power Platform -keskuksen. Keskuksesta tulee yhteinen paikka oppia strategiasta ja ohjeista, jotta tekijät voivat tehdä oikeita päätöksiä siitä, mitä he suunnittelevat rakentavansa ja mihin heidän tällöin kannattaa suunnata.

CoE Starter Kitissä on joitakin ratkaisun olemassa olevia osia, joita voit hyödyntää, kuten määritä passiivisuusilmoitusten osia ja määritä kehittäjien yhteensopivuuden osia. Näiden osien mukana tulee sähköpostimalleja, ja ne voidaan kopioida käyttötarkoitukseen sopivaksi ja oletusympäristöstä siirtämisen tarpeiden mukaan. Hyvä lisäys on myös saada viestinnän sivustoon joitakin menestystarinoita.

Yleisöt

Siirtoprosessissa yhteydenpitoon liittyy yleensä erilaisia kohderyhmiä. Seuraavassa on tärkeimmät sidosryhmät ja niiden roolit:

• Sovelluksen omistajat: Sovelluksen omistajat ovat henkilöitä tai tiimejä, jotka vastaavat tiettyjen sovellusten kehittämisestä, ylläpito ja hallinnasta. He tietävät sovelluksensa toiminnot, työnkulut ja määritykset perusteellisesti. Yhteydenpito sovelluksen omistajien kanssa on erittäin tärkeää, jotta ymmärretään sovelluskohtaiset vaatimukset ja voidaan kerätä palautetta, käsitellä ongelmia ja varmistaa sovellusten sujuvan siirtämisen uuteen ympäristöön.
• Sovelluksen käyttäjät: Sovelluksen käyttäjät ovat henkilöitä, jotka käyttävät sovelluksia säännöllisesti tehtäviensä tai työnkulkujensa suorittamiseen. Heillä saattaa olla eritasoista teknistä asiantuntemusta ja kokemusta sovelluksiin liittyen. Yhteydenpito sovelluksen käyttäjiin on tärkeää, jotta he saavat siirtoa koskevat tiedot, päivitykset muutoksista tai häiriöistä, jotta voidaan tarjota koulutusta tai tukea sujuvan siirtymisen varmistamiseksi ja minimoida mahdolliset vaikutukset päivittäisiin toimintoihin.
• Osastopäälliköt tai johtajat: Osastopäälliköillä tai esimiehillä on merkittävä rooli siirtymisprosessissa, koska he valvovat osastojensa toimintaa ja strategisia tavoitteita. Heille on tiedotettava siirron aikajanasta, mahdollisista vaikutuksista ja eduista. Viestintä osastopäälliköiden kanssa antaa heille tarvittavia ohjeita, yhdenmukaistaa siirtoa osaston tavoitteisiin ja varmistaa sujuvan koordinoinnin osaston ryhmissä.
• IT- tai tekniset tiimit: IT- tai tekniset tiimit ovat vastuussa siirtymisen infrastruktuurista, järjestelmistä ja yleisistä teknisistä näkökohdista. He osallistuvat siirtoprosessin suunnitteluun, toteuttamiseen ja tukeen. Yhteydenpito IT-ryhmiin on tärkeää, jotta voidaan keskustella teknisistä vaatimuksista, riippuvuuksista, tietoturvaan liittyvistä seikoista sekä tarvittavista infrastruktuuri- tai määritysmuutoksista, jotka on toteutettava onnistuneen siirron varmistamiseksi.
• Tietoturva- ja vaatimustenmukaisuustiimit: Tietoturva- ja vaatimustenmukaisuustiimeillä on ratkaiseva rooli tietoturvan, tietosuojan ja säädösten noudattamisen varmistamisessa siirron aikana. Ne antavat ohjeita ja varmistavat, että luottamuksellisten tietojen suojaamiseksi on olemassa asianmukaiset toimenpiteet. Viestintä suojaus- ja yhteensopivuusryhmien kanssa tarkoittaa keskustelua suojausvaatimuksista, salausprotokollista, käytönvalvonnasta ja kaikista säännöstenmukaisuuden noudattamiseen liittyvistä seikoista siirtoprosessin aikana.
• Toimiva johto: Toimivalle johdolle, mukaan lukien C-tason johtajat tai ylin johto, olisi tiedotettava siirtymisprosessista. He eivät ehkä edellytä yksityiskohtaisia ja teknisiä tietoja, mutta heidän on oltava tietoisia projektin tavoitteista, edistymisestä ja mahdollisista vaikutuksista organisaatioon. Yhteydenpito ylimmän johdon kanssa auttaa varmistamaan heidän tukensa, linjauksen strategisiin tavoitteisiin ja resurssien kohdentamisen siirtoa varten.

On tärkeää räätälöidä viestintästrategiat ja -viestit kullekin kohdeyleisölle, kun otetaan huomioon niiden erityistarpeet, huolet ja teknisen ymmärryksen taso. Selkeä ja oikea-aikainen yhteydenpito kaikkien sidosryhmien kanssa edistää yhteistyötä, varmistaa sujuvan koordinoinnin ja vähentää mahdollisia haasteita siirtoprosessin aikana.

Aikataulu

Sidosryhmäviestinnän tiheys siirtoprosessin aikana vaihtelee projektin tarpeiden ja dynamiikan mukaan. On tärkeää luoda säännöllinen ja johdonmukainen viestintä sidosryhmille tiedottamiseksi, huoliin vastaamiseksi ja yhdenmukaisuuden ylläpitämiseksi koko siirron ajan. Seuraavassa on joitakin seikkoja, jotka liittyvät viestinnän tiheyteen eri sidosryhmien kanssa:

• Sovellusten omistajat: Säännöllinen viestintä sovellusten omistajien kanssa koko siirtoprosessin ajan on tärkeää. Tähän sisältyy tarvittaessa säännöllisin väliajoin siirron edistymistä koskevia päivityksiä, ongelmien ratkaisua ja sovelluksen omistajien osallistumista päätöksentekoon. Yhteydenpidon tiheys voi vaihdella sovelluksen monimutkaisuuden ja kriittisyyden mukaan, mutta on suositeltavaa saada säännölliset kuittaukset ja oikea-aikaiset vastaukset kyselyihin.
• Sovelluksen käyttäjät: Osallista sovelluksen käyttäjiä säännöllisten viestintäkanavien kautta, jotta he pysyvät ajan tasalla siirrosta. Tähän sisältyy ilmoituksia, sähköpostiviestejä, uutiskirjeitä tai jopa erityisiä koulutustilaisuuksia tai työpajoja. Sovellusten käyttäjien kanssa tiedottamisen tiheys voi vaihdella, mutta on tärkeää tarjota päivityksiä tärkeimmistä välitavoitteista, kertoa käyttäjille muutoksista tai häiriöistä, jotka voivat vaikuttaa heihin, sekä tarjota tukea ja ohjeita koko prosessin ajan.
• Osastopäälliköt ja esimiehet: Viestintä osastopäälliköiden ja esimiesten kanssa voi tapahtua säännöllisin väliajoin tai tarpeen mukaan sen mukaan, mikä merkitys siirtymisellä on heidän osastoilleen. Anna säännöllisin väliajoin päivityksiä yleisestä edistymisestä, aikajanasta ja vaikutuksesta osaston tiimeihin.
• IT- tai tekniset tiimit: Kommunikoi säännöllisesti siirtymiseen osallistuvien IT- ja teknisten tiimien kanssa. Tämä käsittää jatkuvan yhteistyön, teknisten kysymysten tai ongelmien päivitysten jakamisen sekä tarvittavien määritysten tai muutosten koordinoimisen. Viestinnän tiheys on yleensä suurempi suunnittelu- ja analyysivaiheessa. Järjestä käyttöönottovaiheessa säännöllisesti kosketuspisteitä tai kokouksia, jotka varmistavat sujuvan koordinoinnin.

Resursointi

Resurssien tehokas hallinta on tärkeää onnistuneen siirron kannalta. Seuraavassa on joitakin tärkeitä seikkoja, jotka kannattaa ottaa huomioon, kun resurssien hallintaa tarkastellaan siirron aikana:

• Resurssien tunnistaminen: Määritä siirtoprojektiin tarvittavat resurssit, mukaan lukien henkilöt tai ryhmät, jotka vastaavat tehtävistä, kuten siirtoa edeltävistä valmisteluista, tietojen siirrosta, testauksesta, käyttöönotosta, määrityksestä ja siirron jälkeisestä tuesta. Määritä kuhunkin roolin tarvittavat taidot, asiantuntemus ja käytettävyys.
• Resurssien varaus: Varaa resursseja rooleihin ja tehtäviin resurssin osaamisalueet, käytettävyyden ja kuormituskapasiteetin perusteella. Varmista, että resurssit on kohdistettu asianmukaisesti työmäärän tasapainottamiseksi ja projektin määräaikojen mukaisesti. Ota huomioon mahdolliset riippuvuudet tai rajoitukset, jotka voivat vaikuttaa resurssien kohdistamiseen, esimerkiksi useisiin projekteihin liittyvät jaetut resurssit.
• osaamisalueet kehittäminen ja koulutus: Arvioi tiimin osaamisalueet- ja tietopuutteet ja tarjoa tarvittavat koulutus- tai täydennyskoulutusmahdollisuudet sen varmistamiseksi, että resurssit on varustettu riittävästi niille osoitettuihin tehtäviin. Tähän voi liittyä koulutusistuntoja, työpajoja tai pääsy olennaisiin resursseihin ja dokumentaatioon.
• Viestintä ja yhteistyö: Edistää tehokasta viestintää ja yhteistyötä muuttoliikkeeseen osallistuvien resurssien välillä. Kannusta säännöllisiin tilapäivityksiin, koordinaatiokokouksiin ja tietojen jakamiseen, jotta varmistetaan, että kaikki ryhmän jäsenet toimivat yhdenmukaisesti ja tietojen perusteella, ja että he työskentelevät yhdessä yhteisten tavoitteiden saavuttamiseksi.
• Valmiussuunnittelu: Ennakoi mahdolliset resurssirajoitukset tai riskit ja kehitä valmiussuunnitelmia. Määritä tai ristiinkouluta vararesursseja kriittisiin rooleihin odottamattomien haasteiden, kuten odottamattomien poissaolojen tai resurssirajoitusten, ratkaisemiseksi.
• Sidosryhmien sitouttaminen: Pidä sidosryhmät, kuten sovellusten omistajat, osastopäälliköt ja johto, ajan tasalla resurssien kohdentamisesta ja mahdollisista vaikutuksista aikatauluihin tai toimituksiin. Viesti säännöllisesti resurssipäivityksistä, edistymisraporteista ja mahdollisista muutoksista resursointisuunnitelmiin odotusten hallitsemiseksi ja läpinäkyvyyden ylläpitämiseksi.

Objektien yksittäiset siirrot

Sovelluksen ja ratkaisun välinen ero on tärkeä. Sovelluksen vieminen ja tuominen vaikuttaa vain kyseiseen objektiin. Ratkaisu on säilö, jossa voi olla useita sovelluksia, työnkulkuja ja muita objekteja.

Kaaviosovelluksen vieminen ja tuominen (vanha tapa)

Yksityiskohtaiset vaiheet on dokumentoitu kohdassa Kaaviosovelluspaketin vieminen ja Kaaviosovelluspaketin tuominen.

Tämä sovellusten vienti on vanha tapa. Vaikka sitä tuetaan, suosittelemme käyttämään ratkaisuja. Ratkaisujen avulla voit siirtää useita komponentteja yhden resurssin asemesta.

Vie ja tuo työnkulku (vanha tapa)

Seuraavissa vaiheissa kuvataan, miten työnkulku viedään.

1. Valitse "..." -valikosta Vienti ja valitse sitten Paketti (.zip).
2. Anna paketin nimi ja kuvaus. Tämän jälkeen voit määrittää oletusasetuksia ja lisätä kommentteja, joita voi käyttää tuontivaiheen aikana.
3. Valitse oikeassa alakulmassa Vie, jotta voit ladata paketin. Jos lataus ei käynnisty automaattisesti, valitse Lataa-painike.

Seuraavissa vaiheissa kuvataan, miten työnkulku tuodaan.

1. Valitse Tuonti-painike.
2. Lataa pakettitiedosto palvelimeen ja odota, että näytössä näkyy paketin tiedot.
3. Kun määrität työnkulkuasetuksia, voit joko luoda uuden työnkulun tai päivittää aiemmin luodun työnkulun paketista saatavan työnkulun määrityksen avulla.
4. Valitse työnkulun määrittämiseen tarvittavat yhteydet. Tuo-painike tulee käyttöön, kun olet määrittänyt onnistuneesti kaikki tarvittavat asetukset.

Kun olet tuonut työnkulun, se on aktivoitava. Jos työnkulussa on yhteysviittauksia, aktivoivalla käyttäjällä on oltava kyseisten yhteyksien käyttöoikeudet. Jos ei ole, yhteyden omistaja voi myöntää käyttöoikeuden aktivoinnin käyttäjälle.

Tämä pilvityönkulkujen vienti on vanha tapa. Vaikka sitä tuetaan, on suositeltavaa käyttää ratkaisuja, joiden avulla voi siirtää useita osia yhden resurssin sijasta.

Mallipohjaisen sovelluksen vienti ja tuonti

Mallipohjainen sovellus kuuluu aina ratkaisuun. Ratkaisutiedostoon (.zip) sisältyvä pakattu sovellus voidaan jakaa käyttäjille käyttöoikeusroolien perusteella sen jälkeen, kun se on onnistuneesti viety lähdeympäristöstä ja tuotu kohdeympäristöön.

Yksityiskohtaiset vaiheittaiset prosessit käsitellään kohdassa Ratkaisun vieminen ja Ratkaisun tuominen.

Microsoft Copilot Studio -bottien vieminen ja tuominen

Bottien tuonti ja vienti on mahdollista ratkaisujen avulla. Yksityiskohtainen luettelo vaiheista on kohdassa Bottien vienti ja tuonti ratkaisujen avulla.

Power Pages -sivuston vieminen ja tuominen

Sivujen siirtäminen sisältää aiemmin luodun määrityksen viemisen Microsoft Dataverse -ympäristöön ja tuomisen Dataverse-kohdeympäristöön. Jotkin edeltävät vaiheet on suoritettava kohdeympäristössä. Kun valmistelutyö on valmis, portaalin määritystiedot voidaan viedä määritysten siirtotyökalulla.

SharePoint-lomakesovellus – oletusympäristön erikoistyyppi

SharePoint Lomakesovellukset voidaan liittää vain yhteen ympäristöön, ja jos niitä ei ole määritetty toisin, ne ovat oletusympäristössä. Kaikkien sovellusten siirtäminen edellyttää, että kohde on eri ympäristö kuin oletusympäristö. Aiemmin luotuja mukautettuja lomakkeita ei siirretä automaattisesti juuri määritettyyn ympäristöön. Vain tuotantoympäristöt voidaan nimetä mukautetuille SharePoint-lomakkeille. Tämän jälkeen tulee manuaalinen prosessi, kuten peruspohjasovelluksen siirtäminen.

Microsoft Power Platform -objektien varmuuskopiointi

Useimmat Microsoft Power Platform -objektit viedään zip-tiedostoina. Jos ei, niissä on vähintään yksi tiedostomuoto. Nämä tiedostot alkuperäisessä tiedostomuodossaan, zip-tiedostona tai millä tahansa tiedostopäätteellä, voidaan lisätä mihin tahansa tiedoston tallennustilaan tai säilöön. Joitakin esimerkkivaihtoehtoja ovat Azure DevOps, GitHub, SharePoint, OneDrive tai mikä tahansa muu ratkaisu, joka tukee kaikkia tiedostomuotoja.

Joukkosiirtoasetukset

Sovelluksen tai työnkulun siirto on onnistunut, jos se toimii samalla tavalla kuin aiemminkin. Joitakin elementtejä ei voi kuitenkaan siirtää:

• Työnkulun suoritustiedot työnkulun aiemmista suorituksista – Työnkulun suoritusten tietoja säilytetään vain 28 päivää. Jos tarvitset näitä tietoja, ne voidaan viedä ja tallentaa joko CoE Starter Kit -paketilla tai jos olet määrittänyt viennin Data Lakeen. CoE Starter Kitin uusimmassa versiossa on työnkulun suoritustiedot, jos niitä käytetään tietojen viennin kanssa.
• Pohjaan perustuvan sovelluksen versiot – Kun tekijät iteroivat kehitysprosessin läpi, niistä voidaan luoda useita versioita. Aikaisempia versioita ei voi siirtää. Vain uusin versio voidaan siirtää.
• Sovelluksen tai työnkulun tai yhdistimien avulla käytettävät tiedot – Vain sovelluksen metatiedot sisällytetään vientiin.

Myöskään sovelluksessa tai työnkulussa tehdyt yhteiskäytön kommentit eivät sisälly.

Tässä artikkelissa esitellään joitakin mahdollisuuksia. Ennen kuin päätät, ota huomioon kunkin mahdollisuuden vaikutukset ja edut.

Siirrä kaikki – tietokannan varmuuskopioinnin ja palautuksen vaihtoehto

Myös oletusympäristö varmuuskopioidaan useimpien ympäristötyyppien tavoin. Nämä järjestelmän varmuuskopiot suoritetaan automaattisesti. Oletusympäristössä ei ole tarvittaessa käytettävää vaihtoehtoa, joten se edellyttää tukipyyntöä. Varmuuskopio voidaan palauttaa uuteen ympäristöön, jossa kaikki tiedot pidetään Dataversessa. Tämä vaihtoehto näyttää vain lukijalle sen olemassaolon ja antaa ohjeita sen huomioon ottamiseen. Sitä ei pidä tavoitella ensisijaisena vaihtoehtona, koska se tuottaa vain osittaisen siirron.

• Tuettu: Dataverse, Dynamics-sovellukset
• Ei täysin tuettu: pohjaan perustuva sovellus, komponenttikirjasto, mukautetut sivut, Power Automate, Microsoft Copilot Studio

Ei tuettu kokonaan ilmaisee, että siirron aikana tietoja saatetaan menettää ja lisävaiheet voivat olla tarpeen.

Siirrä metatiedot ja sen jälkeen tiedot

Suositeltava tapa on siirtää metatiedot ratkaisujen avulla. Tämän jälkeen voidaan käyttää joko tietovirtoja, Azure Data Factorya tai jotain muuta tietojen siirtotyökalua tietojen siirtämiseen. Täydellinen automatisointi alusta loppuun ei ehkä ole mahdollista kaikissa tapauksissa erilaisten yhdistinten vuoksi, mutta melko tarkka arvio on mahdollinen.

Korkealla tasolla vaiheet ovat seuraavat:

1. Sovelluksen lisääminen ratkaisuun.
2. Lisää työnkulku ratkaisuun.
3. Lisää olemassa olevat botit.
4. Säädä yhteysviittaukset sovelluksissa ja työnkuluissa.
5. Ratkaisun riippuvuuksien tarkistus ja objektien lisääminen.
6. Tuo ratkaisu.
7. Tuo ratkaisu.
8. Siirrä tiedot.

Ratkaisun riippuvuuksien tarkistaminen

Ratkaisun tuonnin onnistuminen kohdeympäristössä voidaan varmistaa vain, jos kaikki ratkaisuun liittyvät osat on lisätty tai ne ovat käytettävissä kohdeympäristössä. Jos osia puuttuu, ratkaisun tuonti todennäköisesti epäonnistuu. Parhaiten voit varmistaa, että kaikki pakolliset osat ovat käytettävissä, jos näitä vaihtoehtoja käytetään yhdessä:

• Lisää valitut osat ratkaisuun manuaalisesti. Tässä tapauksessa oletetaan, että tiedät, että kaikki riippuvaiset osat ovat jo käytettävissä kohdeympäristössä.

• Käyttämällä ratkaisun Näytä riippuvuudet -painiketta voit antaa järjestelmän määrittää riippuvuudet puolestasi. Voit lisätä kaikki riippuvuudet tai lisätä valikoivasti vain ne riippuvuudet, joita ei ole kohdeympäristössä.

  

Osan lisääminen ratkaisuun (manuaalinen)

Jos ratkaisu on luotu, tekijän on käytettävä Lisää olemassa oleva osa -valikon vaihtoehtoa olemassa olevan sovelluksen, työnkulun tai botin lisäämiseksi.

Yhteysviittausten säätäminen

Pohjaan perustuva sovellus ja työnkulut käsittelevät yhteyksiä eri tavalla. Työnkulut käyttävät yhteysviittauksia kaikille yhdistimille, kun taas pohjaan perustuvat sovellukset käyttävät niitä vain implisiittisesti jaettuihin (ei-)yhteyksiin, kuten SQL Server -OAuthtodennukseen.

Sovelluksen päivittäminen käyttämään yhteysviittauksia yhteyksien sijaan

Peruspohjasovelluksia, jotka eivät ole ratkaisutietoisia, kun ne lisätään ratkaisuun, ei päivitetä automaattisesti yhteysviittausten käyttöä varten. Yhteysviittaukset liitetään pohjasovelluksiin vain silloin, tietolähde lisätään sovellukseen. Sovellusten päivittäminen vaati seuraavaa:

1. Lisää ratkaisuun sovellus, joka ei ole ratkaisusta tietoinen.
2. Poista yhteys sovelluksesta.
3. Luo uusi yhteysviite ratkaisussa.
4. Lisää yhteys, joka sisältää liittyvän yhteysviittauksen.

Työnkulun päivittäminen käyttämään yhteysviittauksia yhteyksien sijaan

Jos työnkulku ei ole ratkaisussa, se käyttää yhteyksiä. Jos kyseinen työnkulku lisätään sitten ratkaisuun, se jatkaa aluksi yhteyksien käyttämistä. Työnkulut voidaan päivittää kahdella tavalla käyttämään yhteysviittauksia yhteyksien sijaan:

• Jos työnkulku viedään ei-hallitussa ratkaisussa ja tuodaan, yhteydet poistetaan ja korvataan yhteysviittauksilla.

• Kun ratkaisutyönkulku avataan, työnkulun tietosivulla olevassa työnkulun tarkistuksessa näkyy varoitus, jonka mukaan on käytettävä yhteysviittauksia. Varoitussanoma sisältää toiminnon, jossa on kehotus Poista yhteydet, jotta yhteysviittauksia voidaan lisätä. Tämän toiminnon valitseminen poistaa yhteyden työnkulun käynnistimestä ja toiminnoista sekä sallii yhteysviittausten valitseminen ja luonnin.

Objektin lisääminen ratkaisuun (automatisointi)

PowerShell-komentojen avulla voit siirtää sovelluksia ratkaisuun joukkotoimintona. Aiemmin luotujen pohjasovellusten ja pilvivirtojen lisääminen ratkaisuihin voidaan tehdä myös komentoriviltä. Kokeile tätä vaihtoehtoa asentamalla uusimmat PowerShell-moduulit. Kaksi pääkomentoa ovat Set-PowerAppAsSolutionAware ja Set-FlowAsSolutionAware.

Kun moduulit on asennettu, lisää oma ympäristötunnus, sovelluksen tunnus, työnkulkutunnus ja ratkaisutunnus.

Kaaviosovellukselle:

Set-PowerAppAsSolutionAware -EnvironmentName {Environment ID} -AppName {App ID} -SolutionId {Solution ID}

Työnkululle:

Set-FlowAsSolutionAware -EnvironmentName {Environment ID} -FlowName {Flow ID} - SolutionId {Solution ID}

Yhteysviitteet ovat yhteysviite-taulukon tietomerkintöjä. Yhteysviittauksen käyttäminen sovelluksen tai työnkulun osana edellyttää ydinsovelluksen tai työnkulkumäärityksen muokkausta. connectionReferences-solmu on korvattava yhteysviittauksella.

Ratkaisun tuominen ja vieminen

Jos oletetaan, että ratkaisut ovat valmiit, seuraava automaatiovaihe voidaan tehdä useilla tavoilla:

• Vie ja sitten tuo ratkaisut manuaalisesti kohdeympäristöön.

• Pakettien avulla voit siirtää useita ratkaisuja yhdellä kertaa.

• Power Platformin koontityökalujen tehtävien avulla voit suorittaa useita toimintoja, kuten paketoida ratkaisun, purkaa ratkaisun paketista, viedä ratkaisun ja tuoda ratkaisun. DevOps antaa mahdollisuuden automatisoida sovellusten elinkaaren hallinnan (ALM), ja nämä tehtävät on suunniteltu tukemaan ALM-hallintaa Microsoft Power Platformille.

Power Platform -komentoriviliittymässä (CLI) on myös vaihtoehtoja ratkaisujen vientiin ja tuontiin. Kaikkia ratkaisuun liittyviä komentoja voi käyttää ratkaisujen luomiseen, viemiseen ja tuomiseen. Voit myös siirtää tietoja sisään ja ulos CLI:n avulla.

Tekijäystävällinen valinta on käyttää putkia, joiden on tarkoitus demokratisoida Power Platformin ALM. Tuomalla ALM:n automatisoinnin ja jatkuvan integroinnin/jatkuvan käyttöönoton (CI/CD) ominaisuudet yhdeksi ominaisuuspalveluksi, saat sen lähestyttävämmäksi kaikille tekijöille, järjestelmänvalvojille ja sovelluskehittäjille.

Yhteyksien luominen (manuaalinen)

Luo kohdeympäristössä ennen tuontitoiminnon määritystä puuttuvat yhteydet, joita sovellus tai työnkulku edellyttää. Katso lisätietoja yhteyksien luonnista kohdasta Yhteyksien hallinta Power Automatessa.

Tietojen siirto

Tietojen siirtoon on käytettävissä useita vaihtoehtoja, jotka vaihtelevat manuaalisista täyteen automatisointiin.

• Vie ja tuo tiedot manuaalisesti Excel-työkirjoilla.
• Power Automate -pilvityönkulku voidaan kehittää tietojen poimimiseen lähdetaulukoista ja kirjoittamiseen suoraan kohteeseen. Tämä edellyttää kuitenkin, että tekijä käyttää Dynamics 365 Connector- tai Dataverse (vanha) -yhdistintä. Dataverse-yhdistin ei tällä hetkellä tue eri ympäristöjen yhdistämistä. Tämä ominaisuus on suunniteltu tulevaisuutta varten. Kun toiminto on julkaistu, sitä voidaan käyttää tietojen siirtoon ympäristöstä toiseen.
• Configuration Migration tool (CMT) on työkalu, jota käytetään portaalin siirtämiseen, mutta sitä voidaan käyttää myös säännölliseen tietojen siirtoon. CMT:tä voi käyttää myös PowerShellin kanssa. PAC CLI -työkalu mahdollistaa CMT:n kutsumisen.
• Tietovirtojen avulla voidaan luoda yhdistämismäärityksiä ympäristöjen välille ja niiden avulla voi siirtää tietoja. HTTP Web -yhdistintä voidaan käyttää Dataversen vaihtoehtona.
• Azure Data Factorya voidaan käyttää Dataverse-yhdistimen kanssa tietojen vetämiseen lähteestä ja niiden lisäämiseksi kohteeseen.

Kun oletusympäristön koko on rajoitettu, jokin edellä mainituista vaihtoehdoista riittää, kun tietoja siirretään pois oletusympäristöstä.

Tyhjentämisessä huomioon otettavia seikkoja

Tyhjentäminen kannattaa sovelluksille ja työnkuluille, joita ei ole käytetty tai päivitetty pitkään aikaan. Järjestelmänvalvojalla on eri vaihtoehtoja harkittavaksi tyhjentämisen suhteen.

• Määritä tietojen tuontijärjestys. Vähiten riippuvaiset taulukot tulevat ensimmäisiksi ja eniten riippuvaiset lopuksi.
• Kaikkia kenttiä ei tarvitse yhdistää. Kenttiä, kuten Versio, Muokkauspäivämäärä, Luontipäivämäärä ja joitakin muita järjestelmäkenttiä ei tarvitse yhdistää.
• Jos haluat säilyttää alkuperäisen luontipäivämäärän, yhdistä Luontipäivämäärä-lähdekenttä kohdetaulukon OverRiddenCreatedOn-kenttään.
• Seurantatietoja ei voi siirtää.
• Älä ota käyttöön työnkulkuja, jotka käynnistyvät tietojen lisäämisen perusteella, ellei näin ole tarkoitus. Tämä lisää tietojen siirron aikaa.

Merkintäasetukset

CoE Starter Kitissä ei ole merkintävaihtoehtoa tällä hetkellä. Se voi kuitenkin olla mukautus, jonka voit lisätä aloituspakettiin.

Luo Tunnisteet-niminen taulukko ja määritä monta moneen (N:N) -suhde sovellukseen, työnkulkuihin ja muihin varastotaulukoihin. Tämän jälkeen voit luoda tunnisteen ja liittää nämä tietueet sopiviin varastonimikkeisiin. Käyttökokemuksen parantamiseksi voit upottaa ruudukon sovellusten, työnkulkujen ja muiden varastotaulukoiden päälomakkeeseen. Tätä asetusta suositellaan, koska siinä on viittausten yhdenmukaisuus.

Luo kuhunkin varastotaulukkoon tekstikenttä, jonka avulla voit siepata tekstin (tunnisteen) myöhempää käyttöä varten.

Jos haluat kiinteämmän luettelon, luo yleinen asetusjoukko lisää se myös kaikkiin varastotaulukoihin ja niiden lomakkeisiin.

Karanteenivaihtoehto

Jos olet epävarma tiettyjen sovellusten tarpeellisuudesta, voit kokeilla niiden eristämistä jonkin aikaa ja asettaa ne karanteeniin tämän tilan aikana. Vain omistaja voi käyttää sovellusta. Kun sopiva aika on kulunut ja omistajalta ei ole saatu vastausta, voit poistaa ne ympäristöstä.

Työnkulut eivät tue karanteenitilaa, mutta vastaavaa toimintatapaa voidaan käyttää pysäyttämällä työnkulku ja tarkistamalla, aktivoiko omistaja työnkulun uudelleen.

Molemmissa tapauksissa on tärkeää pitää yhteyttä omistajaan asianmukaisesti.

Vain poisto -vaihtoehto

Jos tuottavuus ei heikenny eikä objekteja ei uudelleenkäytetä, tämä vaihtoehto on paras. Useimmat testivirrat ja -sovellukset kuuluvat tähän luokkaan.

Tällöin, kun objektiluettelo on tunnistettu, siihen voidaan kehittää PowerShell-erä ja sille voidaan välittää csv-luettelo, joka poistaa kaikki kyseiset resurssit.

Kun käyt läpi sovellusten ja työnkulkujen tunnuksia, voit poistaa ne oletusympäristöstä seuraavalla komennolla.

• Remove-AdminFlow -EnvironmentName Default-[Guid] -FlowName [Guid]
• Remove-AdminPowerApp -AppName [Guid] -EnvironmentName [Guid]

Objektien varmuuskopiointi ja poisto -vaihtoehto

Oletetaan esimerkiksi, että Power Automate -työnkulku luodaan tiettyyn erityiseen kausittaiseen tarpeeseen, mutta sitä ei ole käytetty pitkään aikaan. Tällöin on hyvä varmuuskopioida osa ennen sen poistamista.

Saat osasta varmuuskopion, voit luoda viedyn ratkaisun joko yksittäisen siirron tai joukkosiirron asetuksilla. Tämän jälkeen se voidaan lisätä joko haluttuun tiedostosäilöön tai OneDrive-sijaintiin.

Kun varmuuskopio on suojattu, voit suorittaa puhdistusprosessin loppuun Poista-vaihtoehdon avulla.

Monissa tapauksissa nämä ovat testivirtoja ja sovelluksia, joita tekijät ovat luoneet osana henkilökohtaista tuottavuuden oppimista ja kokeilua.

Yhteenveto

Power Platform on työkalu sekä kansalais- että ammattikehittäjille. Oletusympäristön käytön tulisi keskittyä ensisijaisesti Microsoft 365 -tuotteiden käytön henkilökohtaiseen tuottavuuteen. Kaikkien muiden sovellusten ja työnkulkujen kehittämisen tulisi tapahtua erillisissä jaetuissa, henkilökohtaisissa tai kehittäjäympäristöissä. Vahva suositus on kehittää DLP-käytäntöön perustuva riippumaton ympäristöstrategia, jonka avulla tekijät voivat kehittää sovelluksiaan ja työnkulkujaan oikeassa ympäristössä. Siitä on myös paljon hyötyä viestintästrategian luomiseen ja siihen, että käyttäjille tarjotaan itsepalvelumalleja strategian oppimiseen, ratkaisujen toteutukseen ja parhaita käytäntöjä sovellusten ja työnkulkujen kehittämiseksi. Hyvä lisäys on saada viestinnän sivustoon joitakin menestystarinoita. Sisäisesti julkaistujen menestystarinoiden avulla tekijät voivat saada ideoita ja nähdä mahdollisuuksia Power Platformin hyödyntämisessä.

Vahva hallintostrategia on olennaisen tärkeä, kun siirretään tiettyjä objekteja. Objektien siirtämiseen on eri strategioita, kuten yksittäinen siirto ja joukkosiirto. Sopiva vaihtoehto määräytyy organisaatiokäytäntöjen mukaan. Ratkaisut ovat suositeltavin tapa järjestää sovelluksen osat ja tehdä siirroista yksinkertaisempia.