Gå til innhold

Arbeidsflyter

Arbeidsflyter er ePortal sin regel-motor for automatisering. En arbeidsflyt består av tre blokker: NÅR (en hendelse eller tidsplan utløser flyten), HVIS (filtrerings-betingelser som må være sanne for at handlingen skal kjøres) og GJØR (selve handlingen — varsel, oppgave, integrasjons-kall, osv.). Editoren er blokkbasert og krever ikke programmering. KAI kan foreslå utkast basert på naturlig språk.


Tilgang

Hvem Hva trengs
Rolle som kan endre Administrator
Modul som kreves Portalinnstillinger (moduleID 99) — Arbeidsflyter
Effekt på hvem Alle brukere/poster som matcher flytenes betingelser

KAI-utkast krever i tillegg KAI Arbeidsflyt-rettighet (KAI.Workflow, fail-closed).


Innstillinger

Innstilling Betydning Standard Konsekvens Tilgang
Aktive arbeidsflyter Hvilke flyter som faktisk kjører Ingen Inaktive flyter kjører ikke selv om de er konfigurert Administrator
NÅR-blokk (trigger) Hva som utløser flyten Hendelse Endring av trigger kan endre hele flyt-mønsteret Administrator
HVIS-blokk (filter) Betingelser som må være sanne Ingen filter Uten filter kjører flyten på alle hendelser Administrator
GJØR-blokk (handlinger) Hva som faktisk skjer Påkrevd Minst én handling må være definert Administrator
Maks kjøringer per dag Sikkerhetsstopp mot uendelige løkker 1000 Når grensen nås, deaktiveres flyten med varsel Administrator
KAI-utkast-modus La KAI foreslå arbeidsflyt-utkast Av Krever KAI Arbeidsflyt-rettighet Administrator

Detaljert beskrivelse per innstilling

Aktive arbeidsflyter

Betydning. Liste over arbeidsflyter som er konfigurert i tenanten. Hver flyt har av/på-bryter. Inaktive flyter kjører ikke, selv om alle blokker er gyldig konfigurert. Bruk dette for å teste en flyt i utkast, og slå på når den er klar.

Gyldige verdier. Liste med av/på per flyt.

Standardverdi. Ingen flyter aktivert ved levering — tenanten må selv konfigurere.

Når trer endringen i kraft. Umiddelbart. Allerede køede kjøringer av en deaktivert flyt fullføres.

Påvirker historiske data. Nei.

Konsekvens for andre moduler. Avhenger av flytenes handlinger — kan påvirke varsler, oppgaver, integrasjoner.

Avhengigheter. Avhenger av hvilke hendelser/moduler flyten bruker.

Hvem kan endre. Administrator.


NÅR-blokk (trigger)

Betydning. Definerer hva som utløser arbeidsflyten. To hovedkategorier:

  • Hendelse — utløses idet noe skjer (ny arbeidsordre opprettet, status endret, frist nær).
  • Tidsplan — utløses periodisk (hver morgen kl 08, hver mandag, første i måneden).

Gyldige verdier.

  • Hendelse: velg fra liste over registrerte hendelser per modul (f.eks. WorkOrder.Created, Task.OverdueByNDays, User.LoggedIn).
  • Tidsplan: cron-uttrykk eller forhåndsdefinerte intervaller (daglig, ukentlig, månedlig).

Standardverdi. Hendelse (uten valgt hendelse — flyten er ikke kjørbar før dette er satt).

Når trer endringen i kraft. Umiddelbart for nye hendelser. Tidsplaner kjører ved neste planlagte tidspunkt.

Påvirker historiske data. Nei — kun fremtidige hendelser/tidspunkter utløser flyten.

Konsekvens for andre moduler.

  • Hendelse — modulen som genererer hendelsen må publisere den.
  • Tidsplan — bakgrunnsjobb (Azure Functions) kjører flyten på riktig tid.
  • Performance — hyppige hendelser (f.eks. hver innlogging) kan generere mye flyt-aktivitet.

Avhengigheter. Hendelsen må være registrert i ePortal sin event-bus.

Hvem kan endre. Administrator.


HVIS-blokk (filter)

Betydning. Betingelser som filtrerer hvilke hendelser/poster flyten faktisk behandler. Uten filter kjører flyten på alle hendelser av valgt type — det er nesten alltid for bredt. Filter bygges med felt-sammenligninger (lik, ulik, større enn, inneholder) og OG/ELLER-grupperinger.

Gyldige verdier. Boolsk uttrykk med felt, operator og verdi. Kompleksitet begrenses til 10 nivåer av nesting.

Standardverdi. Ingen filter (alle hendelser triggerer).

Når trer endringen i kraft. Umiddelbart.

Påvirker historiske data. Nei.

Konsekvens for andre moduler. Påvirker hvor selektivt GJØR-blokken kjøres.

Avhengigheter. Feltene som brukes må finnes på objektet hendelsen sender.

Hvem kan endre. Administrator.


GJØR-blokk (handlinger)

Betydning. Definerer hva flyten faktisk gjør når NÅR + HVIS er oppfylt. Flere handlinger kan kjedes sekvensielt eller parallelt. Vanlige handlinger:

  • Send varsel (e-post, in-app)
  • Opprett oppgave (Task / WorkOrder)
  • Oppdater felt på et objekt
  • Kall ekstern integrasjon (webhook, integration builder)
  • Vent N minutter / timer / dager
  • Forgren basert på betingelse

Gyldige verdier. Liste med handlinger, hver med egne parametre.

Standardverdi. Påkrevd — minst én handling.

Når trer endringen i kraft. Umiddelbart for nye kjøringer.

Påvirker historiske data. Nei.

Konsekvens for andre moduler. Direkte — handlingen påvirker mål-modulen.

Avhengigheter. Hver handling kan avhenge av at mål-modulen er aktivert.

Hvem kan endre. Administrator.


Send e-post fra CRM

Handlingen Send e-post er tilgjengelig for CRM-arbeidsflyter. Mottaker, emne og melding kan bruke feltbrikker som {{ContactEmail}}, {{ContactName}} og {{DealName}}.

  • Som ansvarlig bruker sender fra e-postadressen til brukeren som eier eller opprettet CRM-objektet.
  • Delt postkasse sender fra adressen administrator skriver inn.
  • Meldingen sendes som HTML via Microsoft Graph, lagres i avsenderens Sendte elementer og logges som utgående CRM-korrespondanse.
  • En manglende eller ugyldig mottaker gjør at handlingen hoppes over. Manglende eller ugyldig avsender gjør at handlingen feiler og vises i kjøreloggen.

Microsoft 365-integrasjonen må være aktivert, og appregistreringen må ha application-tillatelsen Mail.Send med administratorsamtykke. Begrens helst hvilke postkasser appen kan sende som med en Exchange Application Access Policy.


Ekstra e-postadresse på Varsle og Oppsummering

Handlingene Varsle (Notify) og Oppsummering (Digest) har et valgfritt felt Ekstra e-postadresse. Adressen mottar varselet/oppsummeringen i tillegg til den oppslåtte mottakeren (bruker → e-post via varslingsinnstillinger). Feltet er ment for en fast arkiv-/fellesadresse (f.eks. arkiv@bedrift.no).

  • Tomt felt = ingen ekstra mottaker (ingen endring for eksisterende arbeidsflyter).
  • Adressen er en ren e-postmottaker — den bruker ikke brukerens varslingspreferanser, og den vises ikke som in-app-varsel.

Abonnement (masterordre) — arbeidsflyter og oppsummeringer

Modulen Abonnement (intern modul 50) er tilgjengelig i arbeidsflyt-editoren med objektene Masterordre, Ordrelinje, Ordreforslag og Tilbud. Mottaker kan settes til ordrens ansvarlige, selger eller begge (i tillegg til «Bestemt bruker» og den valgfrie ekstra e-postadressen).

Oppsummeringer er standardmodellen. De ferdige abonnement-malene er Oppsummering-flyter (Cron/tidsplan): én melding per kjøring som lister alle ordrer/forslag/tilbud med ønsket status, gruppert per status og med direktelenke per rad — aldri én e-post per ordre. Tre maler følger med under «Bruk mal»:

  • Ordrer til gjennomgang — ukentlig oppsummering av masterordrer med status-endringer (bl.a. «NeedsReview»).
  • Åpne ordreforslag — ukentlig oppsummering av ordreforslag som venter på beslutning.
  • Ubesvarte tilbud — ukentlig oppsummering av utsendte tilbud som ennå ikke er besvart.

Per-hendelse-flyter (f.eks. varsle når et tilbud sendes) er også mulige som opt-in, men standardene er oppsummeringer for å unngå varselstøy. Arbeidsflyt kan aldri produsere tilbud, sende kundebrev eller endre ordre-/forslag-/tilbudsstatus — den varsler, oppretter oppgaver og eskalerer kun.


Maks kjøringer per dag

Betydning. Sikkerhetsmekanisme som stopper en arbeidsflyt fra å kjøre over en gitt grense per døgn. Beskytter mot uendelige løkker (flyt A trigger flyt B trigger flyt A) og runaway-scenarier (f.eks. en flyt som genererer hendelser den selv lytter på).

Gyldige verdier. Heltall 1–100000.

Standardverdi. 1000.

Når trer endringen i kraft. Umiddelbart. Ved overskridelse deaktiveres flyten automatisk og administrator får varsel.

Påvirker historiske data. Nei.

Konsekvens for andre moduler. Flyt som treffer grensen slutter å kjøre — alle dens handlinger pauses.

Avhengigheter. Ingen.

Hvem kan endre. Administrator.


KAI-utkast-modus

Betydning. Lar administrator beskrive ønsket arbeidsflyt i naturlig språk, og KAI foreslår et utkast med ferdig konfigurerte NÅR/HVIS/GJØR-blokker. Utkastet er alltid deaktivert ved levering — administrator må aktivt aktivere det etter gjennomgang. KAI inspiserer ikke kundedata for å lage utkastet.

Gyldige verdier. Av eller på.

Standardverdi. Av (fail-closed).

Når trer endringen i kraft. Umiddelbart.

Påvirker historiske data. Nei.

Konsekvens for andre moduler.

  • KAI — KAI-tjenesten må være aktivert.
  • Datatilgang — KAI har ikke tilgang til kundedata utenfor utkast-generering; respekterer normalt fail-closed-prinsipp.

Avhengigheter. Krever KAI.Workflow-rettighet og at KAI-modulen er aktivert for tenanten.

Hvem kan endre. Administrator med KAI Arbeidsflyt-rettighet.


Slik endrer du en arbeidsflyt

  1. Åpne Innstillinger → Portalinnstillinger → Arbeidsflyter.
  2. Klikk Ny arbeidsflyt eller velg eksisterende.
  3. Skriv navn og beskrivelse.
  4. Konfigurer NÅR: velg hendelse eller tidsplan.
  5. Konfigurer HVIS: legg til filter-betingelser.
  6. Konfigurer GJØR: legg til handlinger sekvensielt.
  7. Sett maks kjøringer per dag.
  8. La bryteren "Aktiv" stå av under utvikling.
  9. Klikk Lagre.
  10. Test med en kjent hendelse — sjekk kjørelogg.
  11. Når flyten er validert, slå på "Aktiv".

Slik bruker du KAI-utkast

  1. Klikk Foreslå med KAI (kun synlig hvis du har KAI Arbeidsflyt-rettighet).
  2. Beskriv flyten i naturlig språk, f.eks. "Send varsel til prosjektleder hver fredag kl 14 hvis det finnes oppgaver med frist neste uke som ikke er startet".
  3. Gjennomgå KAI-utkastet — alle blokker skal være tydelige.
  4. Juster manuelt hvis nødvendig.
  5. Lagre som inaktiv utkast.
  6. Test og aktiver.

Vanlige problemer

Flyten kjører ikke

Sjekk: 1. Flyten er aktiv ("Aktiv"-bryter på). 2. NÅR-blokk har valgt hendelse/tidsplan. 3. HVIS-blokk filtrerer ikke ut alle hendelser ved feil (test med tom filter). 4. Maks kjøringer per dag ikke er nådd. 5. Kjørelogg viser hendelse — hvis ikke, treffer ikke triggeren.

Flyten kjører for ofte

Sjekk filter-blokken. Et for løst filter kan trigge flyten på mer enn ønsket. Vurder å snevre inn med flere AND-betingelser.

Handling feiler — "Mottakeren har ingen tilgang"

GJØR-blokk respekterer DataAccess. Sjekk at mottaker/bruker faktisk har tilgang til objektet handlingen prøver å påvirke.

Maks kjøringer ble nådd

Du har sannsynligvis en uventet looping. Sjekk om en handling i flyten utløser samme hendelse som triggeren. Deaktiver flyten, ryd opp i logikken, og slå på igjen.

KAI-utkast viser feil hendelse

KAI tolker naturlig språk — vær spesifikk. "Når arbeidsordre blir laget" er klart; "når noe skjer" gir uforutsigbart utkast. Juster manuelt etter behov.

Tidsplan kjører ikke til riktig tid

Tidsplaner bruker UTC i kjørelogg, men input er i tenantens tidssone. Sjekk tenant-tidssone under Dato og tid.


Konsekvensanalyse før endring

Før du aktiverer eller endrer en arbeidsflyt, vurder:

  • [ ] Hvor mange ganger per dag forventer du flyten kjører? Sammenlign med maks-grensen.
  • [ ] Hvem mottar varsler/oppgaver fra flyten? Test med "kun deg selv" først.
  • [ ] Påvirker handlingene eksterne integrasjoner? Webhook-handlinger kan generere stor trafikk mot mottaker.
  • [ ] Kan flyten utløse seg selv? Test med inaktiv flyt og inspiser logg for løkke.
  • [ ] Trengs varsel til berørte brukere? Ny flyt som sender e-post hver mandag kan oppfattes som spam hvis ikke kommunisert.
  • [ ] Kan flyten reverseres? Deaktivering stopper umiddelbart, men allerede utførte handlinger (utsendte e-poster, opprettede oppgaver) må ryddes opp manuelt.

Relaterte sider