Ja dokumentu apstiprināšana notiek e-pastā, atbildes gaidīšana ir tikai daļa no problēmas. Kādam jāatrod pareizā versija, jānosūta tā īstajiem cilvēkiem un pēc lēmuma jāpārvieto fails uz atbilstošo mapi. Pietiek izlaist vienu posmu, lai komanda izmantotu vecu līguma projektu vai apstiprinātu dokumentu meklētu starp melnrakstiem.
Dokumentu darbplūsmu veidotājs palīdz šo secību padarīt pārskatāmu un atkārtojamu. Jūs nosakāt sākuma notikumu, nosacījumus, darbības un nākamo soli atkarībā no rezultāta. Folderit Workflow Designer atrodas pašā dokumentu pārvaldības sistēmā, kur glabājas faili, to versijas, piekļuves tiesības un darbību vēsture. Procesa gaitu var vērtēt kopā ar dokumentu, nevis vākt no atsevišķām sarakstēm un tabulām.
Sākotnējais raksts angļu valodā publicēts 2026. gada 29. janvārī. Funkciju apraksts pārskatīts atbilstoši dokumentācijai 2026. gada 10. novembrī. Piemēri ir iespējamu iestatījumu ilustrācijas, nevis šajā rakstā pārbaudīta produkcijas procesa rezultāti.
Kas ir dokumentu darbplūsmu veidotājs?
Tas ir rīks atkārtotu dokumentu procesu izveidei, parasti vizuālā darba laukumā. Piemēram, jaunas līguma versijas augšupielāde var sākt apstiprināšanas pieprasījumu, bet pieprasījuma rezultāts noteikt faila nākamo atrašanās vietu. Saskaņoto kārtību sasaistot ar sistēmas notikumiem, katra gadījuma organizēšana nav jāsāk no jauna.
Daudzas komandas sāk ar apstiprināšanu. Taču laiks pazūd arī pirms un pēc paša lēmuma: jāiesaista atbildīgie, jāsagatavo dokuments izskatīšanai un jāsakārto tā atrašanās vieta. Vēlāk var būt jānoskaidro, kas apstiprināja tieši konkrēto versiju. Noderīga darbplūsma aptver šo kopumu. Tā neaizstāj cilvēka vērtējumu, bet padara uzdevumu un tā sekas saprotamas visiem iesaistītajiem.
Pamatmodelis: notikums → nosacījumi → soļi → rezultāti
Sākuma notikums nosaka, kad process tiek ierosināts. Folderit piemēri ir File version added, Item moved, metadatu maiņa, Tag added, Share added un Request responded. Šie notikumi nenozīmē vienu un to pašu. Viena dalībnieka atbilde vēl nav pierādījums, ka pabeigts viss apstiprināšanas pieprasījums.
Nosacījumi ierobežo darbības jomu. Var izmantot vienuma tipu, nosaukumu, atrašanās vietu, metadatus vai pieprasījumu pabeigšanas nosacījumu Requests completed. Pati mape atšķiras no tās satura. Norādiet, vai iekļaut izvēlēto mapi, visas apakšmapes vai ierobežotu līmeņu skaitu. Pretējā gadījumā vienai līgumu grupai domāta kārtība var sākt ietekmēt visu krātuvi.
Soļi apraksta veicamās darbības. Dokumentētās izvēles ietver Condition, Delay, Move, Run automation, Send reminder, Wait for event un Request action. Condition soļa Success nozīmē, ka nosacījums ir patiess, bet Failure – ka tas ir aplams. Šīs atzaru nozīmes nav dokumenta apstiprināšana un noraidīšana.
Rezultāti nosaka turpinājumu. Request action solim ir atsevišķi Success, Failure un Timeout iznākumi. Savienojiet katru vajadzīgo iznākumu ar plānoto darbību un apskatiet arī izņēmumus. Ja aprakstīts tikai veiksmīgais ceļš, ne vienmēr būs skaidrs, kurš pārņem neatbildētu vai noraidītu pieprasījumu.
Četras problēmas, ko palīdz risināt pārskatāms process
- Versiju sajukums. Cilvēks izskata vecu versiju vai pēc pareiza lēmuma tiek nosūtīts cits fails. Apstiprinājums attiecas uz izskatīto versiju; jauns augšupielādēts saturs tādēļ nav automātiski apstiprināts. Pirms izmantošanas pārbaudiet gan versiju, gan tai atbilstošo lēmumu.
- Pārrāvumi dokumenta virzībā. Apstiprināts fails paliek melnrakstos vai nonāk nepareizā projektā. Ar iznākumu sasaistīts Move solis palīdz saskaņot atrašanās vietu un faktisko statusu.
- Nepamanīta kopīgošana. Kopīgošanas notikums var pievērst atbildīgā uzmanību. Tas pats par sevi nenosaka, ka saņēmējs ir ārējs vai kopīgošana neatļauta, un nav preventīvs aizliegums.
- Trūkst pierādījumu. Versijas, atbildes un darbību vēsture palīdz noskaidrot, kas noticis un kad. Audita ieraksti vien negarantē atbilstību prasībām; jānosaka arī glabāšanas kārtība, tiesības un pierādījumu izmantošana.
Darbplūsmas izveide Folderit vidē
Atveriet Admin tools → Workflows, piešķiriet darbplūsmai saprotamu nosaukumu un pārbaudiet, vai tā ir iespējota. Pievienojiet vismaz vienu Starting point, izvēlieties notikumu un precīzus nosacījumus. Nosauktu sākuma punktu var palaist arī manuāli no vienuma Workflow izvēlnes. Vienojieties, kad to darīt un kā novērst viena procesa lieku atkārtotu palaišanu.
Senākajā ekrānuzņēmumā lietots nosaukums Resolution. Pašreizējais solis formāla uzdevuma nosūtīšanai ir Request action. Izvēlieties dalībniekus kā lietotājus vai grupas un nosakiet, vai viņi darbojas paralēli vai secīgi. Atsevišķi iestatiet pabeigšanas kārtību: vai vajadzīgas visu dalībnieku, noteikta skaita vai procentuālas daļas atbildes. Norādiet arī noraidījumu slieksni neveiksmīgam rezultātam.
Metožu vidū ir Approval, Acknowledgement, Folderit eSign, DocuSign, eID un Fill fields. Izskatīšana var būt kontā konfigurēta pielāgota metode, tādēļ to nevajag uzskatīt par visiem vienādu standarta izvēli. Parakstīšanas veidu pieejamība un iestatīšana atšķiras. Pārbaudiet nepieciešamo metodi atsevišķi: darbplūsmas izmantošana pati par sevi nedod juridiskās atbilstības garantiju.
Due By ir informatīvs termiņš. Atsevišķais Timeout nosaka, kad automatizācija pāriet uz gaidīšanas laika beigu atzaru; vērtība 0 nozīmē, ka šāda ierobežojuma nav. Termiņa iestāšanās vien neapsola automātisku eskalāciju. Ja neatbildētu gadījumu paredzēts nodot atbildīgajam, jāiestata laiks, turpmākā darbība un cilvēks, kurš uzņemas lietu.
Mapes kā dokumenta dzīves cikla pamats
Modelis Melnraksts → Izskatīšanā → Apstiprināts → Arhivēts komandai dod kopīgu orientieri. Mapju saraksts var palīdzēt saprast, kurā posmā atrodas dokumenti. Taču atrašanās vietai jāatbilst pieņemtajam lēmumam, bet piekļuves tiesībām – dalībnieku lomām. Mapes nosaukums viens pats nav apstiprinājuma pierādījums.
Pārvietošana uz arhīva mapi nenosaka juridisku glabāšanas termiņu un nenozīmē automātisku dzēšanu. Atsevišķi vienojieties, kurš drīkst mainīt apstiprinātu saturu, kura versija ir izmantojama un kā tiks uzturēts arhīvs. Tad struktūra palīdz vadīt darbu un nerada tikai šķietamu sakārtotību.
1. piemērs: līguma izskatīšana un virzība pēc rezultāta
Pieņemsim, ka līgumu jaunās versijas nonāk mapē Līgumi/Izskatīšanā. Mērķis ir iegūt konkrēto atbildīgo lēmumu un atbilstoši tam pārvietot failu. Abus posmus iespējams skaidri attēlot vienā vizuālā darbplūsmā:
- Izvēlieties File version added. Ierobežojiet atrašanās vietu līdz izskatīšanas mapei ar vajadzīgo satura tvērumu un pievienojiet nosacījumu, ka vienums ir fails.
- Pievienojiet Request action ar Approval metodi. Norādiet juridiskās, finanšu un vadības lomas pārstāvjus kā konkrētus lietotājus vai grupas. Piemēram, prasiet visu trīs atbildes un atsevišķi nosakiet viena noraidījuma ietekmi. Metadati šajā piemērā automātiski neizvēlas nodaļas darbiniekus.
- Savienojiet pieprasījuma Success ar Move uz Apstiprināts, bet Failure ar Move uz Labojams.
- Ja noteikts gaidīšanas laiks, savienojiet Timeout ar Move uz Eskalācija. Ieceltais atbildīgais pārbauda kavējuma iemeslu un lemj par turpinājumu.
Iespējama arī atsevišķa turpinājuma automatizācija ar pareizi konfigurētiem pabeigšanas un rezultāta nosacījumiem. Taču Request responded vien nav visa apstiprinājuma pabeigšanas apliecinājums: tas nozīmē vienas atbildes saņemšanu. Dokumenta virzībai jābalstās uz kopējo prasīto iznākumu, nevis pirmo reakciju.
Pārbaudiet jaunas versijas pievienošanu jau atvērtas izskatīšanas laikā. Lēmums paliek saistīts ar izskatīto versiju, un jaunajam saturam nepieciešama saskaņotā apstrāde. Vienlaikus pārliecinieties, ka atkārtoti notikumi nerada vairākus nevajadzīgus paralēlus pieprasījumus. Tieši labojumu laikā saiknei starp dokumentu, versiju un lēmumu jābūt īpaši skaidrai.
2. piemērs: kopīgošanas uzraudzība konfidenciālā mapē
Cita iespējamā darbplūsma reaģē uz Share added ierobežotā konfidenciālā mapē. Precīzi iestatiet atrašanās vietu un vienuma tipu, tad nosūtiet Request action drošības pārbaudītājam. Izmantojiet atbilstošu pielāgotu izskatīšanas metodi, ja tā kontā ir pieejama; citādi var izmantot Approval ar skaidriem norādījumiem.
Pārbaudītājs izvērtē faktisko saņēmēju un piešķirtās kopīgošanas tiesības. Darbplūsma sākas pēc kopīgošanas izveides. Tā nav ārējās kopīgošanas iepriekšēja bloķēšana, automātiska saņēmēju klasificēšana vai piekļuves atsaukšana. Nepieciešamības gadījumā cilvēks izlabo pašu kopīgošanu, izmantojot dokumentētās piekļuves vadības iespējas. Faila pārvietošana viena pati nepierāda, ka saite vai kopīgošana atsaukta.
Izmēģiniet gan parastu atļautu kopīgošanu, gan kopīgošanu ārpus uzraugāmās mapes. Tas palīdz novērtēt uzdevumu lietderību un pārbaudīt faktisko tvērumu. Atbildīgajam jāzina, ko pārbaudīt un kā novērst atrasto problēmu, lai paziņojums nepārvērstos tikai vēl vienā neatbildētā uzdevumā.
Trīs izplatītas kļūdas
Pārāk plašs tvērums. Visu notikumu uzraudzība visā krātuvē rada troksni. Sāciet ar vienu dokumentu grupu, pareizo vienuma tipu un nepieciešamo notikumu. Paplašiniet tikai pēc reālas vajadzības izvērtēšanas.
Vienā darbplūsmā mēģina ietvert visu. Saglabājiet shēmu lasāmu. Vienu pieprasījumu un tā rezultātu ceļus var ērti attēlot kopā. Atsevišķi procesi var palīdzēt lielākā risinājumā, ja skaidri definēta pabeigšana un atbildība; sadalīšana pati par sevi neizlabo kļūdainu loģiku.
Nav saskaņots virzības modelis. Ja apstiprināts dokuments izskatās pēc nepareizā vietā atstāta melnraksta, lietotāji statusam neuzticas. Pirms automātiskās pārvietošanas nosakiet katras mērķa mapes nozīmi un tiesības.
Pārbaudes saraksts pirms lietošanas
- Paredzētajā vietā pievienota jaunā versija sāk procesu; ārpus tvēruma esošs fails to nesāk.
- Apstiprināšana un noraidīšana noved pareizajās vietās saskaņā ar pabeigšanas kārtību.
- Neatbildēšana un skaidri iestatītā gaidīšanas laika beigas tiek apstrādātas paredzēti.
- Jauna versija atvērta pieprasījuma laikā netiek kļūdaini uzskatīta par apstiprinātu un nerada nekontrolētus dublikātus.
- Ir saskaņota pārbaudītāja aizvietošana prombūtnē un eskalētā gadījuma atbildīgais.
- Gala fails, versija, tiesības un vēsture atbilst iecerētajam iznākumam.
Trīs praktiski jautājumi
Vai veidotājs paredzēts tikai apstiprināšanai? Nē. Arī dokumentu virzība un kontrolēta reakcija uz metadatiem, atzīmēm, kopīgošanu un pieprasījumu izmaiņām var samazināt manuālo darbu. Izvēlieties posmu, kur šobrīd rodas aizķeršanās.
Vai jāprot programmēt? Vizuālai konfigurēšanai parasti programmēšana nav nepieciešama. Grūtāk ir vienoties par procesu, lomām un izņēmumiem. Administratoram tomēr jāsaprot nosacījumu un piekļuves tiesību ietekme.
Ar ko sākt? Izvēlieties vienu kavējumus vai kļūdas izraisošu procesu: līgumu apstiprināšanu, iepazīšanās apliecinājumu, pārvietošanu pēc lēmuma vai kopīgošanas pārbaudi. Vispirms pierakstiet tā notikumu, nosacījumus, soļus un rezultātus.
Nākamais solis
Konfigurācijas izvēles skatiet Workflow Designer rokasgrāmatā (angļu valodā). Plašāku kontekstu sniedz Folderit dokumentu darbplūsmu pārskats. Cenrādī pārbaudiet pašreizējā plāna iespējas un nepieciešamās parakstīšanas konfigurāciju. Sāciet ar vienu pilnu, pārbaudītu procesu un pievienojiet jaunus ceļus tad, kad tiem ir skaidrs pamatojums.
