Kaip sustabdyti DI veiksmą „Power Automate“ iki patvirtinimo

„Power Automate“ eigoje tarp DI vertinimo ir jautraus veiksmo įterpkite žmogaus patvirtinimo veiksmą. DI parengia rekomendaciją ir motyvus, tačiau mokėjimą, personalo įrašo pakeitimą ar išorinį paskelbimą eiga pasiekia tik gavusi teigiamą žmogaus atsakymą. Patvirtinimui galite naudoti „Start and wait for an approval“ ir po jo tikrinti grąžintą „Outcome“ reikšmę.

Konfigūracijos seka: priimkite prašymą, patikrinkite jo įvestis, gaukite struktūruotą DI rekomendaciją, perduokite ją patvirtintojui ir laukite sprendimo. DI neapsisprendimą, netaisyklingą atsakymą, žmogaus atmetimą bei pasibaigusį laukimą laikykite skirtingomis būsenomis. Nė viena iš jų neturi patekti į galutinio veiksmo šaką vien todėl, kad ankstesnis eigos etapas baigė darbą.

Paruoškite prašymą ir atsakingą asmenį

Pradėkite nuo trigerio, kuris pateikia konkretų prašymą. Sąlyginiame išlaidų kompensavimo pavyzdyje išsaugokite prašymo identifikatorių, prašytoją, sumą, pagrindimą, numatomą veiksmą ir patvirtintojo tapatybę. Identifikatorius turi išlikti tas pats per DI vertinimą, žmogaus sprendimą ir galutinį įrašą: taip galima susieti atsakymą su tuo prašymu, dėl kurio jis buvo gautas.

Privalomus laukus patikrinkite prieš DI etapą. Jei nėra sumos, gavėjo ar patvirtintojo, prašymą grąžinkite papildyti, užuot prašę modelio užpildyti spragą. DI etapui perduokite vertinimui reikalingus duomenis ir taisykles, o galutinį veiksmą laikykite atskiroje eigos šakoje. Šis atskyrimas padeda užtikrinti, kad rekomendacijos tekstas pats netaptų nurodymu vykdyti mokėjimą ar pakeisti įrašą.

Paprašykite DI rekomendacijos, kurią galima patikrinti

DI nurodymuose apibrėžkite sprendimo kriterijus ir atsakymo struktūrą. Sąlyginė JSON sutartis galėtų būti tokia: {"request_id":"R-001","recommendation":"review","reason":"Trūksta patvirtinto gavėjo"}. Čia „R-001“ yra pavyzdinis identifikatorius, o „review“ reiškia, kad prašymui reikia papildomos žmogaus peržiūros. Net jei DI grąžina „approve“, ši reikšmė tebėra rekomendacija, o ne žmogaus patvirtinimas.

Po DI veiksmo išanalizuokite JSON ir patikrinkite, ar yra visi privalomi laukai, ar rekomendacija priklauso jūsų nustatytam reikšmių rinkiniui ir ar grąžintas identifikatorius sutampa su pradiniu. Motyvai turi būti pateikti patvirtintojui kartu su pirminiais prašymo duomenimis, kad jis galėtų vertinti patį prašymą. Tuščią paaiškinimą, nežinomą reikšmę arba nesutampantį identifikatorių nukreipkite į analizės klaidos šaką.

Įterpkite patvirtinimo vartą ir laukimo būseną

Po sėkmingai patikrinto DI atsakymo pridėkite „Start and wait for an approval“. Lauke „Assigned to“ įrašykite už sprendimą atsakingą asmenį, o „Title“ ir „Details“ pateikite prašymo identifikatorių, siūlomą veiksmą, DI rekomendaciją, jos motyvus ir nuorodą į pirminį įrašą, jei tokia nuoroda yra. Patvirtintojas turi matyti, ką tiksliai jo sprendimas leis atlikti.

Jei pakanka vieno paskirto žmogaus sprendimo, rinkitės „First to respond“; jei reikia visų paskirtų žmonių pritarimo, rinkitės „Everyone must approve“. Po laukimo veiksmo pridėkite sąlygą, kuri lygina „Outcome“ su „Approve“. Tik teigiamoje šakoje įdėkite galutinį veiksmą. „Reject“ šakoje išsaugokite žmogaus sprendimą ir užbaikite prašymą be to veiksmo; vien sėkmingai pasibaigęs laukimo etapas dar nėra pritarimas.

Prieš paleisdami eigą patikrinkite teises naudoti kiekvieną jos jungtį ir DI funkciją. „Sinkur“ patvirtinimo eigos pavyzdys taip pat atskiria atmetimą nuo techninės klaidos ir numato atskiras laukimo pabaigos būsenas. Jei svarbu išsaugoti patvirtinimo identifikatorių dar prieš laukimą, atskiri „Create an approval“ ir „Wait for an approval“ veiksmai leidžia jį įrašyti į prašymo būseną.

Atskirkite neapsisprendimą, atmetimą ir klaidą

DI grąžintas „review“ turėtų reikšti, kad žmogus turi patikslinti prašymą arba vertinimo taisyklę prieš naują bandymą. Netaisyklingas JSON ar nepavykęs DI veiksmas yra techninė arba analizės klaida: pažymėkite prašymą kaip neapdorotą, praneškite atsakingam asmeniui ir nevykdykite jautraus veiksmo. Žmogaus „Reject“ yra aiškus sprendimas dėl galiojančio prašymo, todėl jį registruokite atskirai nuo klaidos.

Patvirtinimo veiksmui nepavykus arba pasibaigus laukimo laikui, naudokite „Run after“ nustatymus klaidos šakai. Joje išsaugokite prašymo ir eigos paleidimo identifikatorius, būseną bei laiką, tada informuokite už procesą atsakingą žmogų. Jei prašymas teikiamas iš naujo, patikrinkite ankstesnę jo būseną, kad pakartotinis paleidimas nesukurtų antro patvirtinimo ar nepakartotų jau atlikto galutinio veiksmo. Audito įraše išlaikykite pirminį prašymą, DI rekomendaciją, patvirtintojo atsakymą ir vykdymo rezultatą pagal organizacijos duomenų saugojimo taisykles.

Ką keičia „Copilot Studio“ kelių etapų patvirtinimai

„Copilot Studio“ agentų srautuose galima sudėti DI ir žmogaus etapus į vieną kelių etapų patvirtinimą, tačiau „Microsoft“ dokumentacija visą šią galimybę žymi kaip peržiūros funkciją, neskirtą produkciniam naudojimui. Šiame variante eigos reikšmes reikia susieti su patvirtinimo etapų įvestimis, o DI etapo maršrutą nustatyti taip, kad didelio poveikio prašymas pasiektų žmogų.

DI etapo būsena „Analysis failed“ reiškia, kad nepavyko priimti aiškaus sprendimo, pavyzdžiui, dėl prieštaringų kriterijų ar nepakankamų duomenų. Pagal numatytąjį maršrutą toks prašymas gali pereiti į kitą etapą, o DI atmetimas gali užbaigti patvirtinimą dar nepasiekęs žmogaus; abu maršrutus nustatykite sąmoningai. DI etapui aplinkoje taip pat turi pakakti „Copilot Studio Copilot Credits“, kitaip patvirtinimas stringa. Kelių etapų patvirtinimams taikomi ir dalijimosi bei perkėlimo tarp aplinkų apribojimai.

Patikrinkite, kada galutinis veiksmas tampa pasiekiamas

Prieš įjungdami eigą realiems prašymams, naudokite sąlyginius bandymus: DI rekomenduoja pritarti, rekomenduoja atmesti, grąžina „review“ arba netaisyklingą JSON; žmogus pritaria arba atmeta; patvirtinimo laukimas baigiasi klaida. Kiekvienu atveju patikrinkite prašymo būseną ir galutinio veiksmo šaką. Jautrus veiksmas turi būti pasiekiamas tik po galiojančio žmogaus „Approve“, susieto su tuo pačiu prašymu, kurį žmogus matė ir vertino.

Taip pat skaitykite: