Ajoittain tulee tarve osallistaa organisaation ulkopuolisia käyttäjiä prosesseihin. Esimerkiksi pysäköintipaikan hakeminen paraatipaikalta toimiston edestä. Hakemusprosessi voitaisiin sähköistää Power Platformin työkaluilla esimerksi seuraavasti:

  • Hakija hakee pysäköintipaikkaa MS Forms -lomakkeella
  • Cloud flow tallentaa hakemuksen automaattisesti SharePoint-listalle
  • Flow lähettää pyynnön hyväksyttäväksi (flow’n approval-toiminto) pysäköintipaikoista vastaavalle
  • Hyväksynnän jälkeen flow lähettää pyynnön ulkoiselle toimijalle
  • Ulkoinen toimija kuittaa kaiken valmiiksi. Mutta miten?

Viimeiseen kohtaan asti kaikki on suoraviivaista. Mutta miten saamme automaattisesti tallennettua tuon ulkopuolisen toimijan kuittauksen siitä että kaikki on tehty?

Kokeillaan!

Vaihtoehto 1 – Approval-toiminto

Lähetetään ensin hyväksyntäpyyntö (approval) ulkopuoliselle käyttäjälle, jolla on Microsoft365-tili omassa organisaatiossaan.

Kiville menee heti. Hyväksyntäpyynnön voi lähettää ainoastaan saman tenantin käyttäjille.

Entä jos lisäämme tämän ulkopuolisen käyttäjän vieraskäyttäjäksi?

Läpi tulee!

Tosin vaihtoehtoa (Approve / Reject) klikkaamalla kirjaudutaan ensin (pyynnön lähettäneeseen tenanttiin), jonka jälkeen vahvistetaan annettu vastaus

Ei mitenkään erityisen sulava kokemus.

Approval-toiminnon hyödyntäminen toimii, mutta sen käyttö edellyttää ulkoisten käyttäjien lisäämistä ympäristöömme vieraskäyttäjiksi.

Vaihtoehto 2 – Send email with options -toiminto

Yritetään seuraavaksi lähettää sähköposti, jossa on mukana valinta. Tämä onnistuu send email with options -toiminnolla. Lähetetään se kokeeksi organisaation ulkopuoliselle M365-käyttäjälle. Lopputulos on mielenkiintoinen. Pienen odottelun jälkeen Send email with options -toiminto palauttaa valinnaksi ”Rejected”.

Ongelmana on se, että sähköpostin vastaanottaja ei ole tehnyt valintaa. Ei edes avannut kyseistä sähköpostia.

Oudommaksi menee kun kokeillaan eri vastausvaihtoehdoilla. Joskus toiminto palauttaa ensimmäisen, joskus toisen ja joskus kolmannen vaihtoehdon. Vastaus tulee aina ennen kuin vastaanottaja saa koko sähköpostia.

Mutta… joskus sama käyttäjä kykenee valitsemaan vastausvaihtoehdon ja se tallentuu oikein.

Lähetetään pyyntö kokeeksi vielä toiseen tenanttiin. Sinne lähetettäessä se menee aina kiville.

Toiminto toimii luotettavammin, jos sähköpostin lähettää esimerkiksi gmail-osoitteeseen.

Sähköpostin voi lähettää myös toisen tenantin jaettuun sähköpostilaatikkoon. Testissäni ensimmäinen viesti meni mönkään (flow päätteli vastauksen ennen kuin viesti edes saapui perille). Tämän jälkeen lähetetyt viestit toimivat kuten pitääkin.

Ei tämän päälle mitään uskalla rakentaa, ennen kuin ymmärtää paremmin milloin tämä oikeasti toimii ja milloin ei. Tilanteessa jossa vastaus pitäisi saada organisaation ulkopuolelta.

Vaihtoehto 3 – Vastauksen tulkinta custom promptilla (cloud flow)

Entä jos antaisimme ulkopuolisen käyttäjän vapaasti vastata saamaansa sähköpostiin. Vastauksen saapuessa, tulkitsemme toimenpiteen oman kehoitteen (custom prompt) avulla.

Flow käynnistyy kun sähköposti saapuu. Rajataan flow käynnistymään vastausten tullessa ennalta määrätyistä osoitteista.

Lisätään työnkulkuun oma kehoite, jossa pyydetään AI:ta poimimaan sähköpostivastauksesta meitä kiinnostavat tiedot:

  • Minkä käyttäjän pyyntöä käsitellään
  • Mikä on vastaus (pyyntö käsitelty tai hylätty)
  • Mikäli pyyntö on hylätty, niin vielä syy hylkäykselle

Kehote saa syötteekseen saapuneen sähköpostin sisällön (body).

Käytännössä ulkopuolinen toimija saa automaattisen sähköpostin, johon hän voi vapaamuotoisesti vastata.

Vastauksen saapuessa flow käynnistyy ja AI hoitaa loput!

Kokeillaan myös kieltävää vastausta.

Lopputulos on oikea.

Tosin tässä kohtaa on hyvä hengähtää. Ja testata useammalla eri tapaan kirjoitetulla vastauksella, että AI tulkitsee sen oikein.

Lopuksi voi vielä miettiä, onko tämä sellainen prosessi, joka kestää AI:n mahdollisesti tekemät virhetulkinnat.

Vaihtoehto 4 – Vastauksen tulkinta autonomisella agentilla

Agentit ovat nykyään se juttu. Entä jos toteuttaisimme edellisen vaihtoehdon autonomisena agenttina? Luodaan agentti ja annetaan sille vastaavat ohjeet, mitä annoimme kehotteelle.

Lisätään agentin käynnistimeksi (trigger) When a new email arrives -toiminto. Aivan kuten teimme työnkulussakin.

Testataan saapuneella sähköpostilla.

Ja sieltähän se tulee.

Cloud flow’hun verrattuna agentilla on hieman työläämpää tallentaa parsittu vastaus SharePoint listalle, mutta onnistuu sekin.

Lisätään agentille tarvittavat toiminnot

  • SharePoint – Get items. Tällä etsitään päivitettävä rivi käyttäjän id:n perusteella
  • SharePoint – Update item. Tällä päivitetään oikean rivin tiedot.

Kyllä ne sinne menee.

Vaihtoehto 5 – HTML-lomakkeen luominen ja käsittely cloud flow’lla

Voimme toki lähettää ulkopuoliselle taholle linkin html-lomakkeeseen, johon käyttäjä kuittaa miten parkkipaikan kanssa lopulta kävi. Lomake muodostetaan http-kutsusta käynnistyvällä cloud flow’lla. Samalla tapaa käsitellään lomakkeella lähetetyt vastaukset.

Tätä kieroa menetelmää olen käsitellyt esimerkiksi tässä postauksessa.

Yhteenveto

No millä minä tämän esimerkin ongelman ratkaisisin? Jos voisin, niin lisäisin ulkopuoliset käyttäjät ympäristöön vieraskäyttäjäksi ja käyttäisin flow’n hyväksyntä-toimintoa (approval). Nopeaa ja helppoa. Eikä mahdollisuutta siihen että AI tulkitsee vastauksen väärin.

Mikäli vieraskäyttäjäksi lisääminen on pois laskuista, etenisin flow’lla ja omalla kehoitteella. Mikäli kestämme sen, että AI mahdollisesti tulkitsee viestejä joskus väärin. Autonomiseen agenttiin en tässä kohtaa lähtisi, sillä tämä työnkulku ei muilta osin hyödy AI-ominaisuuksista. Tekevät perus työnkulun toteutuksesta ainoastaan hieman hankalampaa.