Spring til indholdet

Trigger conditions i Power Automate

Et udtryk i triggerens indstillinger, der afgør, om flowet overhovedet starter. Felterne fra SharePoint, de mønstre der bruges oftest, og hvorfor “Status er Godkendt” ikke er det samme som “blev lige godkendt”.

Opdateret Power AutomateSharePoint Online 3 min. læsning

When an item is created or modified starter flowet ved hver eneste ændring på listen. En betingelse inde i flowet kan stoppe arbejdet, men så er kørslen allerede startet og tæller med i Power Platform-forespørgslerne. En trigger condition bliver vurderet, før flowet starter. Er udtrykket falsk, bliver der ingen kørsel.

Hvor den står#

Triggerens Settings → Trigger conditions → Add. I det klassiske design ligger Settings under triggerens …. Udtrykket skal begynde med @ og give true eller false. Står der flere betingelser, skal de alle være sande. Er én nok, samles de i ét udtryk med @or(...).

Triggerens indstillinger i det klassiske design. Trigger Conditions står nederst.

Mit udtryk fra 2023, hvor en liste startede oprettelsen af et websted, når kolonnen OpretSite stod til Ja (flowet bag står i Opret et websted med Power Automate og SPSiteManager):

@equals(triggerBody()?['OpretSite'], 'Ja')

triggerBody()?['OpretSite'] og triggerOutputs()?['body/OpretSite'] er det samme felt. Udtrykket virker kun, hvis OpretSite er en tekstkolonne. En valgkolonne skal have ?['Value'] på, og en ja/nej-kolonne giver true eller false, ikke teksten Ja.

Et udtryk kan bygges uden at skrive det selv: tilføj en Filter array, byg betingelsen dér, vælg Edit in advanced mode, kopiér udtrykket ind i triggeren og slet handlingen igen.

Felterne fra SharePoint#

KolonnetypeUdtryk
Tekst, tal, datotriggerBody()?['Title']
ValgtriggerBody()?['Status']?['Value']
Ja/nejtriggerBody()?['Aktiv'], som er true eller false
PersontriggerBody()?['Ansvarlig']?['Email']
OpslagtriggerBody()?['Projekt']?['Value'], eller ?['Id']

Navnet er kolonnens interne navn, ikke det viste. Æ, ø og å bliver kodet i det interne navn, så Område hedder noget i retning af Omr_x00e5_de. Den sikre vej er at køre flowet én gang uden betingelse og kopiere navnet fra triggerens output i kørslen.

Mønstre#

Ikke lig:          @not(equals(triggerBody()?['Status']?['Value'], 'Kladde'))
Og:                @and(equals(triggerBody()?['Prioritet']?['Value'], 'Høj'), equals(triggerBody()?['Status']?['Value'], 'Ny'))
En af flere:       @contains(createArray('Godkendt', 'Afvist'), triggerBody()?['Status']?['Value'])
Tekst indeholder:  @contains(toLower(triggerBody()?['Title']), 'haster')
Større end:        @greater(triggerBody()?['Beloeb'], 10000)
Ikke tom:          @not(empty(triggerBody()?['Ansvarlig']?['Email']))

contains skelner mellem store og små bogstaver, derfor toLower. På en liste giver contains sand, hvis værdien er et af elementerne, så En af flere slipper for en kæde af or.

“Status er Godkendt” er ikke “blev godkendt”#

Triggeren ser kun elementet, som det er nu, ikke som det var før ændringen. En betingelse på Status = Godkendt starter altså flowet ved hver senere ændring af et godkendt element, også når nogen retter en stavefejl i titlen.

Den enkleste løsning er en kolonne, som flowet selv sætter, når det er færdigt, fx ja/nej-kolonnen Behandlet:

@and(equals(triggerBody()?['Status']?['Value'], 'Godkendt'), not(equals(triggerBody()?['Behandlet'], true)))

Skal flowet vide præcis, hvilke kolonner der blev ændret, kan Get changes for an item or a file (properties only) fortælle det, men det er en handling. Flowet er altså startet, før svaret kommer.

Et flow, der starter sig selv#

Opdaterer flowet det element, det blev startet af, er det en ny ændring, og flowet starter igen. Behandlet-kolonnen ovenfor stopper det. Det samme gør en betingelse på, hvem der sidst ændrede elementet:

@not(equals(triggerBody()?['Editor']?['Email'], '<forbindelsens konto>'))

Den virker kun, så længe flowets forbindelse er den eneste, der bruger den konto. Et flow, der alligevel er løbet løbsk, stoppes som i Stop mange kørsler af et flow på én gang.

Det der driller#

  • Ingen kørsel at se. Er betingelsen falsk, bliver der ingen kørsel i historikken. Microsofts fejlfindingsside nævner, at et sprunget trigger-tjek kan ses under All runs. Det har jeg ikke efterprøvet. Virker flowet ikke, er første skridt at fjerne betingelsen og se, om det så starter.
  • Split On. SharePoint-triggeren har Split On slået til, så hvert element bliver sin egen kørsel, og betingelsen bliver vurderet for hvert element. Med Concurrency Control slået til kan en kørsel af triggeren højst deles op i 100 elementer.
  • Tomme felter. ?[...] giver null i stedet for en fejl, når feltet er tomt. Uden spørgsmålstegnet fejler udtrykket på elementer, hvor feltet ikke er udfyldt.

Alle noter