Avancerade automationer

Konfiguration · Automatisering · 9.2.1

En enkel regel går igång en gång och är klar: trigger, villkor, ett par åtgärder. Motorn kan mycket mer än så. Steg kan köras samtidigt, ett väntesteg kan hålla tillbaka resten av regeln i timmar eller veckor, en villkorsgrind kan skilja den lyckliga vägen från undantaget, och en gren per post kan följa varje skapad uppgift genom dess eget liv. Det är det som gör en regel till en process: en definition som startar dag ett och tyst avslutar sig själv tre veckor senare.

Den här sidan förklarar varje sådant alternativ. Har du inte byggt en enkel regel än, börja med Automationer; vill du se alternativen kombinerade till verkliga processer, fortsätt med Användningsfall för automationer.

Två vyer av en regel: Redigerare och Diagram

Båda vyerna redigerar samma regel, så inget går förlorat när du byter. En bra vana för allt med grenar: bygg i Redigeraren, läs sedan Diagrammet och kontrollera att bilden stämmer med den process du hade i huvudet. Hänger ett steg på fel gren ser du det där på några sekunder.

När startar ett steg?

Varje steg du lägger till får ett av två startlägen. Väljaren frågar uttryckligen efter det:

Parallella spår är hur en enda regel betjänar flera avdelningar samtidigt: ett IT-spår, ett HR-spår och ett Facility-spår skapar var och en sina egna uppgifter och väntar in sina egna människor, utan att någon blockerar de andra. Ett sammanslagningssteg (se nedan) är där spåren möts igen.

Villkorsgrindar

Steget Villkor är en grind mitt i flödet: fortsätt bara när kriterierna matchar. När de inte gör det hoppas stegen bakom grinden över, och körhistoriken skriver “stoppat av ett tidigare villkorssteg” på var och en av dem, så du alltid ser vilken grind som stängde.

Två egenskaper gör grindarna exakta:

• En grind håller bara tillbaka sin egen väg. Inuti en gren eller ett spår spärrar den bara den grenen; på huvudvägen spärrar den allt nedanför sig. Diagrammet ritar precis det den håller tillbaka.
• En grind är omedelbar. Den kontrollerar posten som den ser ut i det ögonblicket och går vidare. Vill du vänta på att posten ska bli något är det ett väntesteg, inte en grind.

Använd en grind där en process delar sig utifrån data som redan finns (“är det här en extern besökare?”); använd villkor per steg där bara ett steg är valfritt; använd ett väntesteg där svaret ännu inte finns.

Väntesteg: fyra sorter

Ett Vänta-steg håller tillbaka allt nedanför sig tills något händer. Det finns fyra sorter, och redigeraren erbjuder bara de som är meningsfulla på just den platsen.

Tidsgränser

Varje väntesteg kan bära en tidsgräns: ge upp efter så och så många timmar eller dagar, och sedan antingen köra stegen nedanför ändå eller stoppa regeln. Utan en gräns väntar ett väntesteg på uppgifter eller på ett ögonblick helt enkelt så länge det tar; ett väntesteg på en poständring har ett tak på ett år som skyddsnät, och ett väntesteg som löper ut på det taket fortsätter aldrig som om ändringen hade kommit.

Använd “kör stegen nedanför ändå” för eskalering (“är uppgiften inte klar på tre dagar, mejla chefen och gå vidare”) och “stoppa regeln” för erbjudanden som går ut.

Ett väntesteg, eller en gren per post

Ett väntesteg som bevakar flera poster släpper normalt en gång, när de alla har ändrats. Ställ om det till en separat gren per post och regeln öppnar i stället en gren per matchande post, där varje gren kör de steg du lägger inuti den mot just den posten. Tio uppgifter, tio grenar, var och en som petar på sin egen ansvariga. Sammanslagningssteget är hur du samlar in dem igen. Grenar kan nästlas i upp till tre nivåer.

Väntande uppgifter: processen syns från dag ett

När en regel pausar på ett väntesteg skjuts stegen Skapa uppgift nedanför väntesteget inte upp osynligt. Uppgifterna skapas omedelbart som väntande: de visas på posten med allt ifyllt, så att alla kan se hela processen framåt. En väntande uppgift kan inte redigeras eller slutföras förrän dess grind släpper, dess ansvariga meddelas först vid aktiveringen, och dess SLA-klocka startar också vid aktiveringen.

Två följder är värda att känna till:

• Att ta bort en väntande uppgift är nödutgången. Ändras en plan, ta bort den väntande uppgiften; allt som berodde på den faller bort med den i stället för att aktiveras under en bruten kedja.
• Regeln du ser kanske inte är regeln som körs. En pausad körning bär en fryst kopia av sina återstående steg, så att redigera eller ta bort regeln ändrar aldrig en process som redan är i gång. Körhistoriken anger vilken version som faktiskt kördes.

Trappor: kör bara den första matchande åtgärden

Regelinställningen Kör bara den första matchande åtgärden gör stegen till en trappa: det första steget vars villkor matchar körs, resten hoppas över. Det är den naturliga formen för trappade utfall, som en avbokningsavgift som är gratis mer än en vecka i förväg, 50 % inom en vecka och 100 % inom 48 timmar: tre steg Sätt pris, vart och ett med ett snävare villkor, ordnade med det snävaste först.

En trappa väljer en väg och slutar, så den kan inte innehålla väntesteg eller villkorsgrindar; formuläret säger till om du försöker. Behöver du ett trappat utfall inuti en längre process, lägg trappan i en egen regel.

Hur regler samspelar

Det finns också skyddsnät i hela motorn som du sällan möter men bör veta att de finns: ett tak för hur många regler en händelse får köra, ett tak för hur många körningar en post får orsaka per dag, och en säkerhetsbrytare som avaktiverar en regel som fortsätter att misslyckas. En regel som agerar på sin egen post triggar inte sig själv igen, och effekter mellan poster kaskaderar bara några nivåer djupt, så två regler som pekar på varandra kan inte loopa för evigt.

Att läsa en process i körhistoriken

En regel med många steg skriver mer intressant historik än en enkel. Körningen som når ett väntesteg registrerar stegen nedanför som överhoppade med skälet väntar; varje släpp skriver sin egen körning, så en process kan sträcka sig över flera körningar under veckor. Skälen berättar precis var en process står:

Testkörningen förstår flöden också: den visar vilka steg som skulle köras nu, vilka uppgifter som skulle skapas som väntande och var regeln skulle pausa, utan att röra posten.