Administrer delte flyter med brukere utenfor et miljø

Fra og med juni 2025 blir enhver flyt som deles med en bruker som ikke er miljømedlem, utilgjengelig for denne brukeren. Denne viktige endringen ved Power Automate gjør at brukere må være medlemmer av et miljø for å få tilgang til flyter i dette miljøet. Denne endringen forbedrer sikkerheten ved å håndheve miljøgrenser. Den påvirker imidlertid organisasjoner der flyter deles på tvers av ulike miljøer, for eksempel der en flyteier legger til noen utenfor miljøet som medeier eller Bare kjør-bruker.

For å kunne etterleve den nye policyen må Power Platform-administratorer identifisere flyter som deles med brukere utenfor miljøet og justere delingsinnstillingene for disse flytene. Denne artikkelen gir en strukturert tilnærming til å gjøre dette.

Denne artikkelen hjelper deg med å gjøre følgende:

• Identifiser flyter som deles med eksterne brukere (brukere som ikke er i flytens miljø).
• Juster deling og tilgang for disse flytene for å sikre kontinuitet (f.eks., legg til riktige brukere i miljøer og bruk kjøretilgang).

Denne artikkelen viser hvordan Power Platform-administratorer proaktivt kan løse delingsproblemer før håndhevelsen i juni 2025. Det kan også bidra til å etablere styring for å håndtere flytdeling på en sikker måte fremover. For å illustrere viktige punkter, inneholder denne artikkelen reelle eksempler og trinnvise instruksjoner.

Lær anbefalte fremgangsmåter for administrasjon av delte flyter i Del en skyflyt.

Identifiser flyter som deles med brukere utenfor miljøet

Det første trinnet er å lage en liste over alle skyflyter og brukerne de deles med i hvert miljø, og deretter finne ut hvilke flyter som deles med uvedkommende – brukere som ikke er medlemmer av dette miljøet. Power Automate-flyter kan opprettes på to måter: som normale flyter (ikke-løsningsflyter), eller som løsningsavhengige flyter (del av en Dataverse-løsning). Begge er i et miljø, og begge trenger gjennomgang. Delene nedenfor beskriver metoder for å identifisere eksternt delte flyter.

Administrasjonssenter for Power Platform – GUI-metoden

Miljøadministratorer kan bruke administrasjonssenteret for Power Platform til en visuell sporing av endringer.

1. I administrasjonssenteret for Power Platform velger du Administrer>Miljøer > (miljøet ditt) >Ressurser>Flyter.

   Det vises en liste over alle flyter i miljøet, sammen med en Eiere-kolonne.

2. Inspiser eierne for hver flyt. Hvis en flyt har flere eiere (oppretter pluss medeiere), deles den. Sammenlign disse eierne med kjente medlemmer av miljøet. Sammenlign for eksempel sikkerhetsgruppen eller brukerlisten for dette miljøet.

3. Flagg flyter der en eier eller medeier ikke er et forventet miljømedlem. f.eks., hvis avdeling A-miljøet bare skal inneholde brukere fra Avd A, men du ser en medeier fra Avd B, deles denne flyten med en utenforstående. Du må kanskje velge navnet på en eier for å vise detaljer, eller kryssreferanse med miljøets brukerkatalog.

Fordeler med administrasjonssenter for Power Platform – GUI-metoden

Administrasjonssenteret for Power Platform byr på et brukervennlig grensesnitt og tillater filtrering og sortering av flyter etter navn eller eier. Du kan raskt oppdage åpenbare uoverensstemmelser hvis du vet hvilke team og brukere som hører hjemme i miljøet.

Ulemper med administrasjonssenter for Power Platform – GUI-metoden

Denne metoden er manuell og skalerer ikke bra for mange flyter. Du må verifisere eierne individuelt, noe som kan være tidkrevende for store miljøer. Det kan være vanskelig å kryssjekke miljømedlemskap direkte fra brukergrensesnittet.

PowerShell skript – automatisert metode

Når det gjelder en systematisk og repeterbar sporing av endringer, byr Power Automate på administrative PowerShell-cmdleter for å vise flyter og eierne deres. Denne tilnærmingen er kraftig for masseanalyse på tvers av store miljøer eller hele leiere. Du kan skripte prosessen for å sende ut alle flyter og utheve eksterne delinger.

Dette skriptet bruker for eksempel Get-AdminFlow til å hente alle flyter, og deretter Get-AdminFlowOwnerRole for hver flyt for å vise eierne og rollene deres. Utdataene viser hvert flytnavn og et punkt med Owner: [User], Role: [Owner/Co-owner]. Du kan omdirigere denne utgangen til en fil eller behandle den videre.

Bestem deretter eksterne delinger: Sammenlign hver eiers brukerhovednavn (UPN) med settet med brukere som er medlemmer av miljøet. En ekstern deling angis av alle eiere med en UPN som ikke finnes i miljøets brukerliste eller sikkerhetsgruppe. I praksis kan du:

• Eksporter listen over flyteiere fra forrige skript og brukerlisten for miljøet, og bruk deretter Excel eller et skript til å finne forskjeller, eller
• Forbedre PowerShell-skriptet for å foreta kryssjekking mot miljøbrukere via Get-AdminEnvironmentUser.

Fordeler med PowerShell-skript – automatisert metode

Denne metoden er automatisert og omfattende. Den kan raskt liste opp hundrevis eller tusenvis av flyter og kan styres via skript for rapportering. Du kan kjøre den etter en tidsplan, for eksempel månedlig, for å oppdage nye eksterne delinger.

Ulemper med PowerShell script-automatisert metode

Krever kjennskap til PowerShell og administratorrettigheter. Råutdataene viser også UPNer og objekt-IDer. Du må tolke hvilke som er utenfor miljøet og krever litt analyse. Dette er imidlertid enkelt hvis du kjenner miljøets brukerdomene eller har en liste over miljømedlemmer.

Center of Excellence (CoE) Toolkit – instrumentbordmetode

Hvis organisasjonen bruker startpakken for Power Platform Center of Excellence, inneholder den Power BI-instrumentbord og rapporter som omfatter måledata for deling. CoEs beholdning av flyter kan utheve flyter som har gjesteeiere eller eiere utenfor miljøets normale sikkerhetsgruppe. CoE-instrumentbordet kan for eksempel ha en rapport for flyter med flere eiere eller flyter som deles med gjestebrukere. Du kan bruke denne innsikten til å finne flyter med unormal deling.

Fordeler med Center of Excellence (CoE) Verktøykasse – instrumentbordmetode

Sentralisert, visuell rapportering som kanskje allerede aggregerer miljødata. Ingen ekstra skripting hvis CoE er på plass. Den kan flagge mønstre som ikke samsvarer automatisk.

Ulemper med Center of Excellence (CoE) Verktøykasse – instrumentbordmetode

Krever at startpakken for CoE distribueres og holdes oppdatert. Data er kanskje ikke i sanntid (vanligvis oppdateres de etter en tidsplan). Konfigurering av egendefinerte filtre, for eksempel identifisering av eksterne domenebrukere, kan også kreve justering av CoE-komponentene.

Sammenligning av identifikasjonsmetoder

Bruk én metode eller en kombinasjon av metodene i den forrige tabellen til å lage en liste over flyter som deles med eksterne brukere. Dette er de berørte flytene som trenger oppmerksomhet før policyendringen. I mange organisasjoner kan dette være et håndterbart delsett av flyter, f.eks., bare noen få flyter på tvers av avdelinger eller flyter som deles med en partners gjestekonto. Andre steder, særlig i leiere med åpen deling, kan det være et betydelig antall flyter å håndtere, så jo tidligere du identifiserer dem, desto bedre er det.

Juster deling og tilgang for berørte flyter

Når du har identifisert flyter som deles med brukere utenfor miljøet deres, er neste trinn å rette opp delingskonfigurasjonen for hver flyt. Målet er å sikre at alle brukere som trenger tilgang til en flyt, legges til riktig i miljøet (eller flytens tilgang endres på annen måte). Gjør dette slik at når den nye håndhevelsen slår inn, mister ingen funksjonalitet. Delene nedenfor beskriver hvordan du tilnærmer deg justeringer.

Vurder nødvendigheten av hver ekstern deling

For hver flaggede flyt kan du diskutere med flytens eier eller relevante forretningsteam hvorfor den ble delt eksternt. Denne konteksten er viktig for å bestemme løsningen. Listen nedenfor beskriver vanlige scenarioer og handlinger.

• Scenario 1: Brukeren ble lagt til som en medeier bare for å kjøre flyten eller se utdataene: I mange tilfeller la eiere til en ekstern bruker som eier når alt denne personen trengte, var å utløse eller bruke flyten (ikke redigere den). Eieren kan for eksempel legge til en brukerstøtteagent som medeier i en flyt, slik at vedkommende kan utløse den manuelt. I slike tilfeller trenger brukeren sannsynligvis ikke fulle eierrettigheter.
• Handling: Fjern vedkommende fra Eiere-listen, og del i stedet flyten med dem som en Bare kjør-bruker (hvis dette er aktuelt), etter at du har sikret at vedkommende har tilgang til miljøet. Dette gir den nødvendige muligheten til å kjøre flyten uten å gjøre dem til en eier. Finn ut mer i delen Legg til nødvendige brukere i miljøet i denne artikkelen.
• Scenario 2: Brukeren samarbeider på bygging eller vedlikehold av flyten: To avdelinger utvikler for eksempel en flyt sammen, slik at en bruker fra avdeling B ble medeier i miljøet til avdeling A.
• Tiltak: Innfør denne brukeren i miljøet som en eier med den aktuelle rollen, eller vurder å flytte flyten til et nøytralt miljø hvis flere organisasjonsenheter skal være medeiere av den. På kort sikt løser tilgangsproblemer å legge til brukeren i listen over tillatte brukere i miljøet og gi dem en passende rolle (Miljøoppretter hvis de trenger redigeringsrettigheter).
• Scenario 3: Delingen er ikke lenger nødvendig: Noen ganger ble brukere lagt til midlertidig eller forlot prosjektet.
• Tiltak: Fjern den eksterne brukeren fra delingen av flyten. Dette er den enkleste løsningen når det er aktuelt. Hvis ingen utenfor miljøet trenger flyten, kan du oppheve delingen med dem. Flyten er da kompatibel, og bare interne eiere forblir.
• Scenario 4: Deling på tvers av leiere eller med gjestebrukere: En flyt ble for eksempel delt med en konto for gjester (ekstern leier). Denne blokkeres etter håndheving.
• Tiltak: Finn ut om gjesten absolutt må ha tilgang. Hvis svaret er ja, er en mulighet offisielt å legge til denne gjesten som en Azure AD-gjest i leieren og i miljøets sikkerhetsgruppe. Dette gjør dem til et miljømedlem. Dette er uvanlig. Du kan alternativt overføre eierskapet til en intern bruker som kan operere på gjestens vegne, eller bruke en annen mekanisme, for eksempel eksponere flyten via en sikker HTTP-utløser i stedet for direkte deling. Vi anbefaler at du fjerner direkte gjestedelinger, fordi selv om de legges til som miljømedlem, kan det oppstå problemer på tvers av leietakere.

Legg til nødvendige brukere i miljøet

For hver bruker som fortsatt skal ha tilgang til flyten, må du kontrollere at de er medlem av miljøet fremover. Dette betyr vanligvis:

• Hvis miljøet bruker en sikkerhetsgruppe: Legg til brukerens konto i denne Azure AD-sikkerhetsgruppen. Dette gir dem standard rolle som Basic-bruker i miljøet, med mindre annet er konfigurert. Rollen Basic-bruker er vanligvis nok for noen som bare trenger å kjøre flyter og ikke opprette og redigere. Etter at du har lagt til brukeren, kontrollerer du at vedkommende nå vises i miljøets brukerliste i administrasjonssenteret for Power Platform.

• Hvis det er standardmiljøet for leieren, som er åpent for alle brukere: De fleste lisensierte brukere er allerede i det. Sikre at brukeren har en Power Automate-lisens. Håndhevelsen påvirker hovedsakelig ikke-standardmiljøer med begrenset medlemskap.

• Miljøutvikler kontra Basic-bruker: Ikke gi en person rollen Miljøutvikler med mindre vedkommende virkelig trenger å bygge og redigere flyter i dette miljøet. I rettelsene våre foretrekker vi å gi bare den grunnleggende brukeren, eller en egendefinert minimal rolle, som gjør det mulig å kjøre delte flyter. For kjøretilgang er Basic-bruker tilstrekkelig – brukeren trenger ikke å være oppretter. Begrensning av oppretterroller er en anbefalt fremgangsmåte for styring, som beskrives mer i delen nedenfor.

Juster flytens delingsinnstillinger

Når brukeren nå er et miljømedlem, justerer du hvordan flyten deles med dem.

• Hvis brukeren bare trenger å kjøre flyten: Bruk Bare kjør-deling. Åpne delingsinnstillingene for flyten i Power Automate. Fjern brukeren fra Eiere-listen, og legg til navnet på brukeren i delen Bare kjør-brukere. For manuelt utløste flyter, for eksempel knappflyter og direkteflyter, eller flyter som utløses med koblinger som kan deles, sikrer dette at personen kan utløse flyten uten å være eier. De kan ikke redigere eller vise flytens indre og kan bare kjøre den. Resultatet er at brukeren forblir utenfor eierlisten slik at det ikke oppstår noen miljøkonflikt, men kan bruke flytens funksjonalitet slik den skal.

  Eksempel: Bob i markedsføringsavdelingen var medeier av flyten Behandler av potensielle kunder i salgsavdelingen, bare for å kunne starte den med jevne mellomrom. Vi fjerner Bob som medeier og legger til Bob som en Bare kjør-bruker. Bob legges også til i salgsmiljøet som en Basic-bruker. Nå kan Bob velge flytknappen eller motta koblingen for å kjøre den, men han er ikke lenger en ekstern eier – han er en godkjent Basic-bruker i dette miljøet.

• Hvis brukeren trenger fullstendige Eier-tillatelser (samtidig redigering): Etter at du har lagt brukeren til i miljøet, må du sørge for at vedkommende forblir oppført som Eier i flyten. Teknisk sett kan du fjerne dem og legge dem til på nytt for å oppdatere tillatelser. Men etter at de er lagt til i miljøet, er delingen legitim. Du kan også vurdere å flytte flyten til en løsning hvis to eiere fra forskjellige områder opprettholder den på lang sikt. Løsningsflyter er enklere å transportere til et dedikert miljø om nødvendig. Du må uansett dobbeltsjekke at de vises under Eiere, og at rollen deres er Kan redigere (eier) i flytdetaljene.

• Fjern eventuelle overflødige eller uautoriserte delinger: Benytt anledningen til å rydde opp i denne prosessen. Hvis noen ble lagt til for sikkerhets skyld, men aldri bruker flyten, fjerner du dem. Prinsippet om minste rettighet bidrar til å redusere tilsynet. Sørg for at Eiere-listen i hver flyt er begrenset til de som virkelig trenger utformings- og redigeringstilgang.

Formidle endringer til berørte brukere

Hvis du fjerner noens tilgang eller endrer hvordan de aktiverer en flyt, må du gi dem beskjed. Fra brukerperspektivet kan det være litt annerledes å kjøre en flyt gjennom kjøretilgang. De kan få en delingskobling eller se flyten i teamflyter i stedet for Mine flyter. Forklar at «For å overholde nye Power Automate-policyer har vi oppdatert delingsmetoden for flyt X. Du kan fortsette å kjøre den med metode Y, men den vises ikke lenger i eierskapet ditt.» Dette forhindrer forvirring.

Bekreft status etter justering

Etter at du har gjort endringer, bruker du PowerShell eller administrasjonssenteret for Power Platform til å dobbeltsjekke at ingen flyter forblir hos eksterne eiere. Kjør for eksempel identifikasjonsskriptet på nytt og bekreft at det ikke lenger flagger disse flytene. Løs hver flaggede forekomst ved enten fjerning eller riktig miljømedlemskap.

Ved å utføre disse justeringene sikrer du at når Microsoft vrir bryteren, fortsetter disse flytene å kjøre for de tiltenkte brukerne. I stedet for at brukeren får feilmeldingen you do not have access to this flow, forblir brukeren godkjent fordi vedkommende nå er et miljømedlem i en aktuell kapasitet. I hovedsak justerer du delingspraksisen din med plattformens styringsmodell.

Relatert informasjon

• Veiledning for deling av og tillatelser for skyflyt
• Dele en skyflyt