Du vet den følelsen når du finner et lite hjørne av arbeidsflyten som roper “dette burde gå an å automatisere”? Ikke fordi det er kritisk, men fordi det pirrer nysgjerrigheten, det er akkurat passe komplekst til at du får testet noe nytt, og enkelt nok til at det kanskje kan løses på en ettermiddag.

Vel, det var akkurat det som skjedde da vi bestemte oss for å automatisere en liten, men viktig del av rekrutteringsprosessen vår i Snøkam. Uheldigvis hadde den "enkle" løsningen (Jira Automation) veldig mange uforutsette egenskaper som vi skal utforske litt nå.

Caset: Varsler om kandidater klare for kontakt

Vi ønsket en automatisk oppsummering av alle kandidater vi hadde markert som “følg opp senere” i rekrutteringsløpet vårt. Med andre ord kandidater vi har kontaktet før og som vi nå ønsker å ta kontakt med igjen.

Målet var at systemet skulle:

• Finne kandidatene i Jira der status er “FØLGE OPP SENERE” og datoen for å følge de opp har passert.
• Flytte dem automatisk til kolonnen “Klare til å kontaktes”.
• Sende en oppsummeringsvarsel på Slack til en kanal hvor de ansvarlige for kandidatene blir tagget.

Det høres jo trivielt ut, ikke sant? En liten daglig påminnelse, midt i lunsjen, som holder alle oppdatert.

Hvorfor ikke Logic Apps eller Function Apps?

Med tidligere erfaring fra Azure Function Apps og Logic Apps falt tankene raskt dit først. Det er trygt, kjent, fleksibelt, men det betyr også mer kode, mer infrastruktur og mer vedlikehold.

Så da jeg oppdaget at Jira Automation tilsynelatende hadde støtte for Slack-integrasjon og koblinger mot Jira boards, tenkte jeg:
"Hvorfor ikke utforske noe litt annerledes?"

Hva er egentlig Jira Automation? Det er et innebygd verktøy i Jira som lar deg automatisere oppgaver og prosesser uten kode. Det brukes ofte til å håndtere repetitive oppgaver, som å oppdatere statuser, redigere issues i Jira eller sende varsler, mot andre systemer som Slack, Teams eller e-post. Med enkle regler, triggere og betingelser kan du bygge små arbeidsflyter som sparer tid og reduserer manuelle feil, spesielt i prosjekter med faste rutiner eller mange deltakere.

Siden Jira Automation er så tett knyttet mot Jira blir dette åpenbart mindre jobb og raskere utvikling, ikke sant?

Oppsettet i Jira Automation

Oppsettet gikk faktisk overraskende smertefritt.

Vi opprettet en Scheduled rule med en enkel CRON-jobb som kjører hver dag kl. 12:00. Denne kan customises med vanlig CRON format (* * * * *). I tillegg er det mulig å bestemme når jobben skal starte og være aktiv, og potensielt datoen når den skal deaktiveres, uten å faktisk måtte aktivere/deaktivere jobben, som er veldig handy.

Vi gjør så et oppslag mot Jira med denne JQL-spørringen:

status = 'FØLGE OPP SENERE' and 'start Date' <= now()

Vi har nå tilgang til {{lookupIssues}} som er resultatet av oppslaget med å bruke smart variables for å ta i bruk og jobbe videre med dataene.

Hvis ingen kandidater matcher oppslaget, avbrytes regelen. Her kunne vi sendt en melding til Slack med “Ingen kandidater å følge opp i dag”, men vi prøver å unngå støy så vi lot det være.

Dersom det finnes kandidater gjør vi følgende:

1. Itererer over dem.
2. Flytter dem med “Transition issue” funksjonalitet til riktig kolonne (i dette tilfellet: "Klare til å kontaktes").

3. Til slutt Sender en Slack-melding med kandidatens navn og hvem som er Assignee.

Det føltes nesten for enkelt. Helt til vi støtte på veggen aka tagging av Assignee i slack meldingen. "summary" i bildet over er navnet på den aktuelle kandidaten.

Limitations – eller “derfor skriver jeg dette innlegget”

Alt så ut til å fungere perfekt… frem til jeg prøvde å gjøre det siste steget: å tagge de ansvarlige i Slack.

Og det er her Jira Automation viser sitt sanne jeg. Ikke fordi det ikke fungerer, men fordi det fungerer nesten. Her er de største hindringene jeg møtte:

1. Du kan ikke endre variabler. Punktum.

I Jira Automation kan du sette en variabel (og statiske tabeller), men du kan aldri endre den etterpå. Ingen mutasjoner. Ingen akkumulerte verdier. Ikke engang en “midlertidig liste” du kan bygge underveis. Du kan lage en ny variabel basert på en eksisterende, men du kan aldri endre originalen.

Jeg prøvde "alt", inkludert å lage et dummy issue for å lagre informasjon midlertidig, uten hell. Vi ønskte ikke at det kom 10 meldinger når det var 10 personer som var aktuelle å kontakte igjen, så det å sende ut en melding i branchen som vist over, når vi flytter hvert element, var ikke aktuelt. Hvordan skal man da holde oversikt over kandidatene man flytter, uten en liste?

2. Tagging i en Slack post er ikke så lett som du tror

Slack krever at du bruker bruker-ID, ikke navn eller e-post, for å tagge. Den finner en ved å gå inn på profilen til brukeren og bruke Meatballsmenyen for å så bruke "Copy member ID" eller tilsvarende på norsk.

Planen var å hente denne Slack-IDen via e-posten fra Jira-brukeren, men da vi ikke har noen lett måter å lagre dette svaret på har vi ikke mulighet til å lage en oppsummeringspost som var oppgaven. I tillegg gjør Jira det litt vanskelig da de gir mulighet for brukere å skjule e-posten sin (skjult er også default). Informasjonen under er tatt fra dokumentasjonen til Jira relatert til å hente brukere:

• Jira Cloud end users can choose to hide their personal account details, including an email address from others. For more details, see the Profile visibility overview.
• To easily retrieve all users' email addresses, use the user management page (<yourcompany>.atlassian.net/admin) on the website for a straightforward export option.

Med andre ord litt tungvint, men en kunne funnet en vei rundt problemet relatert til å hente ut eposten til en bruker (ref: https://support.atlassian.com/jira/kb/retrieve-email-addresses-of-users-through-jira-cloud-rest-api/). Problemet er bare at å kunne lagre verdien til brukeren når en får den tilbake vil bli et større problem uansett.

3. Løkker og oppsummeringer = dårlig kombo

På grunn av at en ikke kan akkumlere opp data fra loops på en fornuftig måte må en enten spamme Slack med én melding per kandidat, eller så må du ty til kreative (og ganske hacky) løsninger med regex og statiske templates som vi kommer til å se mer på senere.

4 Andre interessante egenskaper

Branch loops kjører parallelt, ikke sekvensielt. Jira gir ingen garanti for rekkefølgen. Med andre ord om du forventer sekvensiell logikk kan du glemme det.

Når en itererer over en smart value (med å bruke {{#lookupIssues}}... {{/}}{{/lookupIssues}} notasjon) vil alle verdier utenfor scopet være utilgjengelige. Dette betyr at i vårt tilfelle når vi skal sende Slack-posten har vi ikke tilgang til andre ting en verdiene fra lookupIssues som gjør det vanskelig å lage en fin melding uten duplikat informasjon.

Løsningen

I stedet for å gi opp (eller skrive en Function/Logic App som jeg kanskje burde gjort), valgte vi en enklere, men litt mer manuell løsning.

Statisk ID-tabell:
Vi lagde en enkel key-value-oversikt der nøkkelen er Jira-brukerens ID og verdien er Slack-IDen.
Når noen nye blir med på rekrutteringsteamet, oppdateres tabellen manuelt. Ulempen? Ja, litt manuelt arbeid.
Fordelen? Det fungerer, og vi får beskjed i Slack når noen ikke blir tagget, så det er lett å fikse eventuelle mangler.

Regex-magi:
For å hente riktig bruker fra den statiske listen måtte vi bruke litt regex-magi, heldigvis med god hjelp fra flere Jira community poster. Når vi så lager en variabel med regexen vil vi faktisk kunne bruke den variabelen utenfor loopen i Slack posten som vi så over, og unngår da den begrensningen.

Først må vi gjøre den statiske id tabellen vår mer søkbare så vi gjør den om til ren tekst på følgende format: jiraId1~slackId1;jiraId2~slackId2;

idTableAsString = {{#ids.entries}}{{key}}~{{value}};{{/}}

Deretter må vi lage en Regex expression ut av hvilke personer vi ønsker å tagge slik at vi kan matche disse med den søkbare teksten vi lagde over. Regexen under blir følgende: jiraId1~.*|jiraId2~.* hvor jiraId1~ er for å matche jiraIden i den statiske tabellen, .* er for å finne resten av teksten, med andre ord slackId, og | for å matche jiraId1 eller jiraId2 osv.

jiraIdsMatchRegex = ({{#lookupIssues.assignee.accountId}}{{.}}~.*{{^last}}|{{/}}{{/}})

Til slutt skal vi gjøre selve matchingen:

1. Vi splitter den søkbare idteksten vår i hver key value pair
2. Matcher de med regexen
3. Tar den siste delen av hver key value pair, med andre ord slackIden
4. Før vi assigner den på følgende format: <@slackId1>,<@slackId2> som er måten en tagger personer når en poster mot slack.

allAssigneeToTag = {{#idTableAsString.split(";").match(jiraIdsMatchRegex).substringAfter("~")}} <@{{.}}>,{{/}}

Duplicates everywhere

I stedet for å få en fine liste med Kandidat - @Ansvarlig blir det nå bare tekst og selve taggingen kommer som en liste på slutten. Egentlig skulle jeg ønske det var mulig å gjøre det inline i selve Slack actionen, men en har ikke tilgang til out-of-scope variabler når en itererer over en smart value som {{lookupIssues}}. Derfor må vi dessverre legge en duplikatliste med på bunnen med tags. Resultatet:

Lesson learned

Til syvende og sist lærte jeg mer av denne lille automasjonsøvelsen enn jeg forventet.

Ikke fordi Jira Automation løste alt for meg, men fordi begrensningene tvang frem en forståelse av hvor verktøyet skinner, og hvor det ikke bør presses lenger enn nødvendig.

Jira Automation er et glimrende verktøy når du:

• vil automatisere små, repeterende prosesser,
• opererer med tydelige og enkle regler,
• ikke trenger avansert tilstands­håndtering,
• og ønsker rask gevinst uten infrastruktur.

Men når du:

• trenger databehandling over flere steg,
• må matche eksterne systemer som ikke deler ID-format,
• vil bygge konsistente integrasjoner,

da er det på tide å ta frem bedre verktøy, som Function Apps eller Logic Apps – og la Jira Automation gjøre det det er best til:
enkel, effektiv automasjon innenfor Jira sitt univers.

Resultatet er ihvertfall at vi nå har en automatisk prosess for å minne oss selv og hverandre på å holde kontakt med kandidater som ønsker inn i Snøkam⚡