Skip to main content

Flows og automatisering

Flows brukes når organisasjonen vil styre rapportbehandling med mer presise regler enn “alle rapporter går til samme godkjenner”.

Hva en flow kan gjøre

  • sjekke beløp, prosjekt, avdeling eller andre felter
  • kreve review fra bestemte roller eller personer
  • auto-godkjenne eller avvise
  • legge inn kommentarer eller oppdatere felter
  • kalle eksterne webhooker

Begynn enkelt

Den beste første flowen er ofte en enkel regel:

  • rapporter under en viss sum går én vei
  • rapporter over en viss sum går til ekstra godkjenning

Det er bedre å starte med én tydelig flow enn å bygge en stor modell som ingen tør å endre senere.

Viktige begreper

  • Trigger: hva som starter flyten, for eksempel innsendt rapport eller fullført review
  • Condition: en beslutning basert på data
  • Action: noe systemet gjør
  • Draft og published: endringer kan redigeres før de faktisk tas i bruk
  • Trace: spor av hva som skjedde i en konkret kjøring

Hvordan jobbe trygt med flows

  1. Lag eller endre draft.
  2. Valider og simuler.
  3. Publiser.
  4. Aktiver først når du er trygg på utfallet.

Slik lager du din første flow

  1. Bestem hva som skal skje annerledes enn i standard godkjenning.
  2. Velg trigger, som regel innsendt rapport.
  3. Legg inn én condition med tydelig terskel eller regel.
  4. Koble begge utfall til en avsluttende handling.
  5. Simuler med en ekte rapporttype dere kjenner igjen.

Ting å være ekstra obs på

  • alle veier må ende i en meningsfull slutthandling
  • review-baserte flows må ha trigger for videreføring etter review
  • endringer i beløp, prosjekt eller avdeling kan gjøre tidligere review ugyldig

Når du bør stoppe opp og teste mer

  • når samme rapport kan treffe flere regler
  • når avdelings- eller lederstruktur er ufullstendig
  • når flowen kaller eksterne webhooker
  • når dere bruker review-invalidation på endrede rapporter

Når flows gir mest verdi

  • ulike terskler for ulike beløp
  • annen godkjenner per avdeling eller lederlinje
  • strengere krav for bestemte kategorier eller prosjekter
  • automatiske webhooker eller kommentarspor ved spesielle hendelser

Se også

Nerdehjørnet

Praktisk tips: Hvis flowen din kaller webhooker, bør konsumenten være idempotent.

const eventKey = `${event.type}:${event.objectId}:${event.version}`;

if (processed.has(eventKey)) return;
processed.add(eventKey);

Flows endrer hva som skjer etter at en rapport sendes inn. Hvis du bygger webhooker, eksportlogikk eller annen automatisering rundt rapporthendelser, må du ta høyde for publiserte regler, flere review-steg og at samme rapport kan vurderes på nytt etter endringer.