Flyt og automatisering
Flyt brukes når organisasjonen vil styre rapportbehandling med mer presise regler enn "alle rapporter går til samme godkjenner". En flyt er en graf av noder med en trigger, betingelser og handlinger, som kan publiseres, simuleres og spores.
Eksempel: avansert godkjenningsflyt
Eksempelet over viser en typisk avansert flyt:
- Triggere:
Rapport innsendtogRapport godkjent - Først en Krev godkjenning fra rolle i avdeling (Godkjenner)
- Hvis ingen godkjennere finnes på avdelingen → fallback til Krev godkjenning fra brukerrolle Administrator
- Innenfor avdelingen rutes videre til Krev godkjenning fra Nærmeste leder
- Til slutt Krev godkjenning fra brukerrolle Eier
- Avsluttes med Fullfør (godkjenn rapporten)
Standard godkjenning (uten flyt)
Hvis ingen flyt er publisert, gjelder standardregelen:
Når en rapport sendes inn, går den til avdelingens leder (
AvdelingsRolle = Manager) eller — hvis avdelingen ikke har leder — til alle administratorer.
Du trenger ikke en flyt for grunnleggende godkjenning. Bygg flyt når du vil ha terskler, vilkår, eller automatiske handlinger.
Hva en flyt består av
| Konsept | Beskrivelse |
|---|---|
| Trigger | Hva som starter flyten |
| Node | Et steg i grafen (handling, betingelse eller forsinkelse) |
| Betingelse | Forgrener basert på rapportdata |
| Handling | Noe systemet gjør |
| Forsinkelse | Vent på tid eller hendelse før neste node |
| Utkast / Publisert | Endringer skjer i utkast, blir aktive ved publisering |
| Spor | Fullstendig spor av en konkret kjøring |
Triggere
| Trigger | Når den fyrer |
|---|---|
Rapport innsendt | Rapporten sendes inn første gang eller på nytt etter avvisning |
Rapport godkjent | En godkjenning i flyten besvares positivt |
Handlinger
| Handling | Beskrivelse |
|---|---|
| Fullfør | Godkjenn rapporten og avslutt flyten (terminal) |
| Avvis | Avvis rapporten (terminal) |
| Krev godkjenning | Send til godkjenner — én eller flere personer/roller |
| HTTP-forespørsel | Send HTTP-kall til ekstern URL (webhook) |
Alle veier i grafen må ende i en terminal handling (Fullfør eller Avvis).
Betingelser
Betingelser sammenligner et felt på rapporten med en verdi. Felt angis som dot-path: report.totalAmount, report.departmentId, report.projectId, report.expenseTypeId, report.userId, osv.
Operatorer
| Operator | Betydning | Type |
|---|---|---|
eq, neq | Lik / ulik | tall, streng, boolean |
gt, gte, lt, lte | Større/mindre enn | tall, dato |
contains | Inneholder delstreng | streng |
startsWith, endsWith | Starter/slutter med | streng |
in | Verdien er i listen | tall, streng |
isNull, isNotNull | Tomt eller satt | alle |
Samlingsoperatorer
For felter som inneholder lister (f.eks. utleggslinjer):
| Operator | Betydning |
|---|---|
ONE_OF | Minst ett element matcher |
ALL | Alle elementer matcher |
NONE | Ingen elementer matcher |
Fallbacks
- Betingelser har en standard-gren (
defaultNodeId) som brukes når ingen gren matcher. - Krev godkjenning har en
Ingen godkjennere-fallback når ingen gyldig godkjenner finnes (f.eks. hvis avdelingsleder er deaktivert) — vist som stiplet linje i editoren.
Forsinkelser
Vent-noden lar flyten pause på tid eller hendelse før neste node. Brukes f.eks. til å sende en påminnelse hvis en godkjenning ikke besvares innen en viss tid.
Krev godkjenning — kriterier
Velg godkjenner ved hjelp av et Godkjennerkriterium:
- Spesifikk bruker (ID)
- Rolle i avdeling (f.eks.
Avdelingsleder) - Rolle i prosjekt
- Brukerrolle (f.eks.
Administrator,Eier)
Konfigurasjonen invalidateOnChange styrer når en eksisterende godkjenning blir ugyldig hvis brukeren endrer rapporten:
| Verdi | Betyr |
|---|---|
amount | Beløp endret → godkjenning må gjøres på nytt |
departmentId | Avdeling endret → ny godkjenning |
projectId | Prosjekt endret → ny godkjenning |
Bare disse tre feltene støttes i dag.
HTTP-forespørsel (webhook)
Bruk for å varsle eksterne systemer eller integrere med egne backender. HTTP-forespørsel er admin-måten å trigge eksterne kall når noe skjer på en rapport — uten å bygge eget abonnement på hendelsesstrømmen.
For utviklere: Hvis du heller vil lytte på alle hendelser kontinuerlig fra din egen backend, bruk SSE-endepunktet i stedet. Se Sanntid, dypelenker og notifikasjoner.
Konfigurasjon
| Felt | Beskrivelse | Grenser |
|---|---|---|
url | Mål-URL (HTTPS) | — |
method | POST (default), PUT, PATCH | — |
headers | Custom headers (auth, content type) | — |
body | Payload med templating (rapportfelter) | — |
timeout | Maks tid for et kall | ≤ 60 s |
maxRetries | Antall forsøk ved 5xx/timeout | ≤ 5 |
initialDelayMs | Første ventetid mellom forsøk | ≤ 10 000 ms |
maxDelayMs | Tak for eksponentielt backoff | ≤ 60 000 ms |
Hvis alle retries feiler kjører flyten videre på error-grenen (eller stopper hvis den ikke har en).
Idempotens
Konsumenten din bør være idempotent — flyten kan re-fyre samme event ved retry, og en rapport kan sendes inn på nytt etter avvisning.
const eventKey = `${event.type}:${event.reportId}:${event.attemptId}`;
if (processed.has(eventKey)) return;
processed.add(eventKey);
Utkast → publisering → simulering
- Utkast: rediger fritt — ingen påvirkning på live rapporter.
- Test: kjør flyten mot historiske rapporter for å se hva som ville skjedd.
- Valider: systemet sjekker at alle veier ender i en terminal handling.
- Publiser: flyten blir aktiv (status
Aktiv) for nye rapporter.
Versjonering bevares — du kan rulle tilbake til en tidligere publisert versjon i Historikk-fanen.
Spor (audit-trail)
Hver kjøring lagrer et spor: hvilken trigger som fyrte, hvilke noder som ble besøkt, betingelses-evalueringer, handling-resultat, og HTTP-respons (med redactede secrets). Bruk spor til feilsøking. Lagring følger audit-retention; se Sporbarhet, sikkerhet og kontroll.
Eksempler
Auto-godkjenn småbeløp
Trigger: Rapport innsendt
└─ Betingelse: report.totalAmount lt 500
├─ true → Fullfør
└─ false → Krev godkjenning (avdelingsleder) → Fullfør
Strengere kontroll for store beløp
Trigger: Rapport innsendt
└─ Betingelse: report.totalAmount gte 10000
├─ true → Krev godkjenning (avdelingsleder) → Krev godkjenning (CFO) → Fullfør
└─ false → Krev godkjenning (avdelingsleder) → Fullfør
Webhook ved godkjenning
Trigger: Rapport godkjent
└─ HTTP-forespørsel → https://din-tjeneste.no/utleggsappen/approved
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 flyten kaller eksterne webhooker.
- Når du bruker
invalidateOnChangepå rapporter brukerne ofte endrer.