Tillbaka till Bloggen

När, var och hur körs regler i Easit GO?

Att veta när man ska välja vilken typ av regel kan vara lite av en utmaning, men det måste inte vara så. För den inbitne kanske namnen är självförklarande men för den nyfrälste Easitianen så kanske det inte är helt uppenbart. Jag kommer därför i det här inlägget gå igenom vilka olika typer av regler som finns, när det kan lämpa sig att använda vilken typ och inte. Kom dock ihåg, det finns många sätt att flå en katt.
AUTOMATISERING


Exekveringsflöde

Innan vi går in på de olika typerna av regler som finns behöver vi gå igenom ”flödet” för hur en regel utvärderas och körs. Grovt indelat sker det i tre steg:

  • Ett event sker i systemet
  • Utvärdering
  • Körning/Exekvering

När ett formulärfält ändrar värde, eller ett objekt sparas, kallas detta ett event. När ett event inträffar kontrollerar systemet vilka regler som lyssnar på detta event. Dessa regler är inställda på att reagera på ändringar av vissa fältvärden – regler som reagerar på de fält som ändrat värde filtreras fram.

Sedan utvärderas de fältregler som finns satt i regeln för att se om formuläret eller objektet som triggat eventet uppfyller dessa. Om formuläret eller objektet uppfyller fältreglerna så körs regeln på formuläret eller objektet, annars hoppas regeln över.

Formulärregler

Denna typ av regel utvärderas och körs endast när ett objekt (tex. en kontakt eller organisation) öppnas eller värden i ett formulär förändras. Formulär används för att visa objekt, olika formulär kan användas för olika roller i systemet. Det går inte att köra formulärregler utan att visuellt ”öppna” objektet.

formulärregler

När ett formulär laddas (ON_FORM_LOAD)

När du öppnar ett objekt, vare sig det är via tex. en vy eller direktlänk så triggas ett event i systemet som kallas ON_FORM_LOAD och är ett av de 2 event som triggar formulärregler. Saker som man kan tänkas vilja utföra här är (det finns säkerligen fler än dessa):

  • Dölja eller inaktivera fält om ett visst villkor uppfylls.
  • Sätta standardvärden i fält.
  • Sätta filter på objektsöksfält


När ett formulär förändras (ON_FORM_CHANGE)

Det andra eventet som triggar formulärregler är när ett formulär förändras, dvs. om man tex. byter status på ett ärende (inte om man ändra hur formuläret ser ut) och kallas ON_FORM_CHANGE. Beroende på hur mycket dynamik man vill ha, förmodligen jättemycket, i formulär så kan samma saker som utförs vid ON_FORM_LOAD även utföras här. Tex. så vill man kanske i ett ärende filtrera anmälare utifrån vilka organisation som är vald, beräkna prioritet utifrån påverkan och brådskan eller visa fältet Lösning när status sätts till Löst.


Generellt om formulärregler

I en regel kan man välja ett eller flera fält som ’Ändrade fält’. Om ett fält väljs som ändrat fält i en regel MÅSTE detta fält vara inställt på formuläret att trigga händelse. Om du i en regel väljer tex. Land som ändrat fält men Land på formuläret inte triggar händelse kommer inte regeln att utvärderas eller köras.

Det går alldeles utmärkt, men det är inte nödvändigt, att köra en regel vid båda eventen och det är går lika bra att ha två regler som gör samma sak men en körs vid vartdera eventet. Allt handlar om behov och förutsättningar.

Om man väljer att ha flera fält som Ändrade fält i en formulärregel så är det endast ett fält som behöver förändras för att regeln ska utvärderas. Om regeln har flera fält som ändrade fält och flera av dessa förändras kommer regeln utvärderas en gång per förändrat fält. Alla fält behöver INTE förändras.


Tips från coachen om formulärregler

Kom ihåg att peka ut ett fält under ’Ändrade fält’. *hytter med pekfingret*
Om man skapar en regel som inte har något fält som ändrat fält så kommer regeln att utvärderas och potentiellt köras för varje fält som triggar händelse. Detta kan göra att regeln körs vid fel tillfälle och skapar sidoeffekter man inte räknat med.

New call-to-action

Objektregler

Regler som körs när man klickar på Spara, eller svarar Ja på frågan om man vill spara de förändringar som gjorts på objektet när man försöker ”gå bort från objektet” kallas Objektregler. Precis som för formulärregler så finns två event som hör ihop med dessa regler, dessa är ON_ITEM_SAVE och ON_AFTER_ITEM_SAVE. Objektregler körs oavsett hur en förändring görs av objektet och använder ”före-efter”-scenario för att veta när den ska köras. Tex. så kan en regel köras om prioritet ändras från 5 till 1.

När ett objekt sparas (ON_ITEM_SAVE)

Det första eventet som sker när man valt att spara ett objekt är ON_ITEM_SAVE och vid det här eventet kan man fortfarande förändra värden på objektet som kommer sparas. Tex. skulle man kunna välja att hämta organisation från Ägare (Kontakt) på en inventarie och sätta den organisationen i fältet Ägare (Organisation) när Ägare (Kontakt) förändras.

Efter ett objekt sparats (ON_AFTER_ITEM_SAVE)

Det andra eventet som sker är ON_AFTER_ITEM_SAVE och till skillnad mot föregående event så kan man här INTE förändra värden på objektet som sparas. Saker man skulle kunna tänkas vilja utföra vid det här eventet är utskick av automatiska e-post eller kommunikation med externa system.

Generellt om objektregler

Till skillnad mot formulärregler kan man för objektregler bestämma om Alla eller minst ett fält behöver förändras för att regeln ska köras. Det innebär att om jag valt Status och Typ som ändrade fält så kan jag välja om båda dessa eller endast ett måste förändras för att regeln ska utvärderas.

Som jag nämnde tidigare så används ett ”före-efter”-scenario för att konfigurera när en regel ska köras och inte. Detta innebär att man jämför värdena på objektet från innan man klickat på Spara med vad fältet har när man väljer Spara. Dvs. vad objektet hade för värden med vad den kommer få för värden.

Tips från coachen om objektregler

Kör alltid, ALLTID, följande funktioner endast vid ON_AFTER_ITEM_SAVE.

  • Auto e-post
  • Exportera objekt
  • Uppdatera underobjekt med data från huvudobjektet

Då objektets värden kan förändras efter att en regel körs vid ON_ITEM_SAVE så vill man inte skicka iväg dessa värden innan alla ev. förändringar är gjorda. Ponera att du vill skicka en bekräftelse till anmälaren av ett ärende med information om att denne blir kontaktad så fort ärendet påbörjas när status sätts till Registrerad. Om du skulle köra den regeln som skickar bekräftelsen vid ON_ITEM_SAVE skulle det potentiellt kunna finnas en regel som sätter status Väntar kund efter regeln som skickar bekräftelsen och då hamnar man i ett läge där båda parter väntar på varandra, kund på oss och vi på kund. Kanske inte det vanligaste scenariot men ni fattar principen.

Meddelanderegler

Säg att ni vill att status ska sättas till pågående om ett e-postmeddelande skickas in till ett ärende, det kan då styras av meddelanderegler. Det är regler som körs när e-postmeddelande importeras till ett objekt. Det handlar alltså inte om regler som körs när ett meddelande skickas från systemet.

Tex. kan man vilja kontrollera meddelandet efter grovt språk, klassificera bilder i meddelandet eller ändra status. Det är några av de saker som kan utföras vid inkommande meddelande.

Tips från coachen om meddelanderegler

Det finns saker som kan utföras av både meddelanderegler och objektregler, tex. ändra värdet för ett fält eller skicka notifiering till handläggare om att ett nytt e-post inkommit till ärendet.

Om man är noga med att rätt ska vara rätt så bör man till exempel köra regler som notifierar handläggare som en meddelanderegel, annars kommer ordningen av e-post på fliken E-post bli fel. Om notifieringsmeddelandet skulle skickas med en objektregel kommer det hamna före, kronologiskt, meddelandet som kunden skickat in. Inte hela världen kanske men det ser lite tokigt ut kan jag tycka. Och rätt ska vara rätt.

Eskaleringsregler

Ibland kan man vilja utföra saker i systemet enligt ett schema (varje måndag) eller man vill löpande kontrollera om ett objekt uppfyller ett visst villkor och om det gör det utföra något. I dessa fall passar eskaleringsregler utmärkt, systemet har något som kallas bakgrundsjobb som körs normalt var 10:e minut, det går att ändra så det inte säkert att det är så hos just dig, och utvärderar då objekt med de villkor som uppsatt i alla eskaleringsregler och om något objekt uppfyller dessa så körs regeln. Tex. kan man vilja skicka en påminnelse till avtalsansvarig 3 månader innan ett avtal löper ut eller man vill avsluta alla ärenden som inte uppdaterats på 1 månad.

Exempel på funktioner som kan användas i en eskaleringsregel är:

  • Auto e-post
  • Arkivera objekt
  • Radera objekt
  • Ändra objekts fält

Fler funktioner finns också men det finns funktioner som bara kan utföras av objektregler och det man kan ta med sig då är att man kan trigga objektregler, i och med att objektet sparas vid förändring och därmed triggar ON_ITEM_SAVE samt ON_AFTER_ITEM_SAVE, med eskaleringsregler. Tex. så kan en eskaleringsregel förändra ett fält på ett objekt som gör att objektet uppfyller villkoren för en objektregel.

Snabbfunktioner - ”Ninjans objektregel”

Låt oss säga att du sitter och tittar i en vy och ser 7 objekt som alla behöver få samma steg utförda på sig, då kan man använda sig av en Snabbfunktion. Snabbfunktioner är lite som en eskaleringsregel fast on demand. Högerklicka på ett objekt i en vy, välj snabbfunktion du vill utföra, ev. gör de val som krävs, klart.

Snabbfunktioner konfigureras på samma sätt som en formulärregel, minus ändrade fält. Om ett objekt i en vy inte uppfyller snabbfunktionens villkor så döljs snabbfunktionen. Snabbfunktioner har ett smutt tillägg, Ställ verifieringsfråga innan körning. Detta tillägg ger användaren av snabbfunktionen en möjlighet att ångra sig. Kan vara bra att ha ibockad om snabbfunktionen tex. använder sig av funktionen Radera objekt. 😊

Exempel på vanliga scenarion där man kan använda snabbfunktioner är:

  • Sätta sig själv som handläggare och påbörja ärenden.
  • Ta bort en kontakt som ägare får alla hens inventarier.
  • Byta kundansvarig på organisationer eller avtal.

 

Slutord

Hoppas detta inlägg inte skapat fler frågetecken kring regler än du hade innan, men om så är fallet eller om du har följdfrågor kring detta så tveka inte att kontakta mig via e-post, LinkedIn eller annat sätt som passar dig!

E-post: anders.thyrsson@easit.se
Min Github:
 https://github.com/easitanth
Easits Github: https://github.com/easitab
Twitter: https://twitter.com/easitanders
LinkedIn: https://www.linkedin.com/in/anders-thyrsson

Lär dig mer om plattformen genom att klicka på bilden.

New call-to-action

 

Följ oss i sociala medier

Ta del av nyheter, tips, aktuella händelser och mycket mer i våra sociala medier.

Få tips och inspiration direkt från oss

Som prenumerant får du ett mejl varje gång vi publicerar nya blogginlägg och läsvärda artiklar. Missa inget – prenumerera på Easit Blogg redan idag!

Relaterat innehåll