En service principal som ejer af et flow

Et flow, der ejes af en person, hænger på personens konto og licens. Rejser personen, skal flowet have en ny ejer. En service principal kan eje flowet i stedet. I Power Platform er den en applikationsbruger, der repræsenterer en appregistrering i Entra ID.

Trinene#

Microsofts fem trin:

1. Opret en applikationsbruger, der repræsenterer service principal’en.
2. Del forbindelserne med applikationsbrugeren.
3. Skift ejeren under flowets Details → Edit → Owner.
4. Slå flowet til.
5. Tilpas licenserne efter grænserne for antal kald (se nedenfor).

1. Applikationsbrugeren#

Først en appregistrering i Entra ID (App registrations → New registration, én tenant). Derefter i Power Platform admin center: Manage → Environments → miljøet → Settings → Users + permissions → Application users → New app user, og vælg appregistreringen.

• Listen viser kun appregistreringer, ikke Enterprise applications.
• Der kan kun være én applikationsbruger pr. appregistrering i hvert miljø.
• Applikationsbrugere findes i Dataverse, så miljøet skal have en Dataverse-database.
• Microsoft siger ikke, hvilken sikkerhedsrolle der kræves for at eje et flow. Det har jeg ikke efterprøvet.

2. Forbindelserne#

For et flow uden for en løsning deles hver forbindelse, flowet bruger, med applikationsbrugeren med Can use. Et flow i en løsning bruger forbindelsesreferencer, og så skal forbindelserne ikke deles.

Forbindelsen logger stadig ind som den konto, der oprettede den. Ejerskiftet ændrer ikke, hvem der skriver i SharePoint eller sender mailen. Det gør en forbindelse oprettet med en servicekonto.

3. Ejeren#

Applikationsbrugeren kan kun være ejer, ikke medejer. Den findes ikke i dialogen Owners, kun under Owner.

Microsoft modsiger sig selv om flows uden for en løsning. Siden om at skifte ejer siger, at flowet skal være i en løsning, fordi ejeren er en del af et almindeligt flows identitet. Siden om service principals beskriver trinene for et flow uden for en løsning. Et flow i en løsning er det sikre valg, og en Process-licens kræver det alligevel.

Et ejerskifte kan ifølge Microsoft tage op til syv dage om at slå igennem. At redigere og gemme flowet får det til at ske med det samme.

Grænser og licenser#

Et flow, der ejes af en service principal, har ingen brugerlicens bag sig.

• Kun standardconnectorer: flowet deler tenantens pulje for applikationsbrugere og andre brugere uden licens, 25.000 kald i døgnet for hele tenanten.
• Premium-connectorer: flowet skal have sin egen licens. Microsofts muligheder er en Process-licens til flowet (op til 250.000 kald i døgnet, flowet skal være i en løsning), en flowgruppe med en Process-licens, en udpeget bruger med licens, der er medejer af flowet, pay-as-you-go i miljøet eller at knytte flowet til en app.
• Pay-as-you-go tager betaling pr. kørsel af et flow med premium-connectorer. Kørsler med kun standardconnectorer koster ikke noget. Er ejeren en service principal, betales kørslerne.
• Uden licens kan et premium-flow ejet af en service principal blive suspenderet med beskeden This flow was suspended because flows owned by service principals are not compliant. Microsoft nævner ingen frist før det.
• Manuelt startede flows (en knap eller en Power App) kører på grænserne for den, der starter dem, også når ejeren er en service principal.

Priserne ændrer sig. De står på Microsofts prisside for Power Automate.

Det der driller#

• Set-AdminFlowOwnerRole skifter ikke ejeren. Den tilføjer medejere af typen User eller Group, og en service principal kan ikke være medejer.
• Med kode kan ejeren af et flow i en løsning sættes gennem Dataverse Web API med ownerid@odata.bind på workflows. At det virker med en applikationsbrugers systemuserid, har jeg ikke efterprøvet.
• Managed identity som ejer af et flow er ikke beskrevet af Microsoft. Power Platforms managed identity understøtter i dag kun plug-ins i Dataverse.
• Forbindelser med OAuth, fx til SharePoint, kan ifølge Microsoft kun deles eksplicit med en bruger, der repræsenterer en service principal. Delingen i trin 2 er altså en særregel for applikationsbrugere.