Dokumenttien työnkulkujen suunnittelu Folderitissa

Kun dokumenttien hyväksyminen hoidetaan sähköpostissa, odottaminen on vain osa ongelmaa. Jonkun pitää löytää oikea versio, lähettää se oikeille ihmisille ja siirtää tiedosto päätöksen jälkeen oikeaan kansioon. Yksi unohtunut vaihe voi riittää siihen, että hyväksytyn sopimuksen sijasta käytetään vanhaa luonnosta tai kukaan ei tiedä, mikä tiedosto on lopullinen.

Dokumenttien työnkulkujen suunnittelija tekee tästä ketjusta näkyvän ja toistettavan. Määrität käynnistävän tapahtuman, rajaukset, tehtävät ja tuloksesta seuraavan toiminnon. Folderitin Workflow Designer toimii dokumentinhallintajärjestelmän sisällä. Tiedostot, versiot, käyttöoikeudet ja tapahtumahistoria ovat samassa ympäristössä, joten prosessin seuraaminen ei edellytä tietojen kokoamista postilaatikoista ja erillisistä taulukoista.

Englanninkielinen lähdeartikkeli julkaistiin 29. tammikuuta 2026. Toimintokuvaukset on tarkistettu dokumentaation perusteella 10. marraskuuta 2026. Esimerkit havainnollistavat mahdollista määritystä; ne eivät ole tässä artikkelissa testatun tuotantoprosessin tuloksia.

Mitä dokumenttien työnkulkujen suunnittelijalla tehdään?

Työkalulla kuvataan toistuvia dokumenttiprosesseja yleensä visuaalisella työalueella. Uusi sopimusversio voi esimerkiksi käynnistää hyväksyntäpyynnön, jonka tulos määrää tiedoston seuraavan sijainnin. Kun sovittu toimintatapa on määritetty järjestelmään, jokaista tapausta ei tarvitse järjestää alusta sähköpostiviesteillä ja muistutuksilla.

Moni tiimi aloittaa hyväksymisestä. Arjessa aikaa kuluu kuitenkin myös siihen, mitä tapahtuu ennen päätöstä ja sen jälkeen. Kenen kuuluu tarkastaa tiedosto? Mihin valmis dokumentti kuuluu? Mistä myöhemmin nähdään, mitä versiota päätös koski? Hyödyllinen työnkulku vastaa näihin kysymyksiin yhdessä. Ihmisen vastuulla säilyy sisällön arviointi ja tarvittavan päätöksen tekeminen.

Perusmalli: tapahtuma → ehdot → vaiheet → tulokset

Käynnistävä tapahtuma kertoo, milloin prosessi alkaa. Folderitin tapahtumia ovat esimerkiksi File version added, Item moved, metatiedon muutos, Tag added, Share added ja Request responded. Tapahtumien merkitykset eroavat toisistaan. Yhden vastauksen saapuminen ei esimerkiksi todista koko hyväksyntäkierroksen valmistuneen.

Ehdot rajaavat kohteet. Voit käyttää esimerkiksi kohdetyyppiä, nimeä, sijaintia, metatietoja tai pyyntöjen valmistumista koskevaa Requests completed -ehtoa. Kansio itse on eri kohde kuin sen sisältö. Valitse tietoisesti vain kyseinen kansio, kaikki alikansiot tai rajattu määrä tasoja. Näin yhden sopimusryhmän sääntö ei ala käsitellä koko dokumenttivarastoa.

Vaiheet määrittävät toiminnan. Dokumentoituja vaihtoehtoja ovat Condition, Delay, Move, Run automation, Send reminder, Wait for event ja Request action. Condition-vaiheen Success tarkoittaa ehdon täyttymistä ja Failure sen jäämistä täyttymättä. Nämä haarat eivät itsessään merkitse dokumentin hyväksymistä tai hylkäämistä.

Tulokset ohjaavat jatkoa. Request action -vaiheessa on erilliset Success-, Failure- ja Timeout-tulokset. Liitä jokainen tarpeellinen tulos seuraavaan vaiheeseen ja tarkista myös poikkeustilanteet. Pelkkä onnistuneen reitin piirtäminen ei kerro, kuka vastaa asiaan silloin, kun päätöstä ei saada.

Neljä tavallista ongelmaa

• Versiot sekoittuvat. Joku tarkastaa vanhan version tai oikean hyväksynnän jälkeen lähetetään väärä tiedosto. Päätös koskee tarkastettua versiota; uusi lataus ei tule samalla hyväksytyksi. Tarkista käytettävä versio ja sen päätöshistoria yhdessä.
• Reititys katkeaa. Hyväksytty dokumentti jää luonnoksiin tai päätyy väärään projektikansioon. Tulokseen sidottu Move-vaihe auttaa pitämään sijainnin sovitun tilan mukaisena.
• Jakaminen jää huomaamatta. Jakamistapahtuman seuranta voi tuoda asian vastuuhenkilön tarkastettavaksi. Se ei sellaisenaan estä jakamista eikä todista vastaanottajan olevan ulkopuolinen tai jakamisen olevan asiatonta.
• Tapahtumista puuttuu näyttö. Versiot, vastaukset ja tapahtumahistoria auttavat selvittämään, kuka teki mitä ja milloin. Lokin olemassaolo ei yksin takaa vaatimustenmukaisuutta. Myös säilyttäminen, oikeudet ja tietojen käyttäminen on sovittava.

Työnkulun luominen Folderitissa

Avaa Admin tools → Workflows, anna työnkululle tunnistettava nimi ja tarkista sen enabled-tila. Lisää vähintään yksi Starting point, valitse tapahtuma ja määritä tarkat ehdot. Nimetty käynnistyspiste voidaan tarvittaessa suorittaa myös kohteen Workflow-valikosta käsin. Sovi, milloin manuaalista käynnistystä käytetään ja miten tarpeettomat rinnakkaiset pyynnöt vältetään.

Vanhan kuvakaappauksen Resolution-nimitystä vastaa nykyisessä määrityksessä muodollisen tehtävän lähettävä Request action -vaihe. Valitse osallistujat käyttäjinä tai ryhminä. Päätä, työskentelevätkö he samanaikaisesti vai peräkkäin, ja aseta valmistumissääntö: vaaditaanko kaikkien, tietyn lukumäärän vai tietyn prosenttiosuuden vastaukset. Määritä lisäksi, kuinka moni hylkäys aiheuttaa epäonnistuneen tuloksen.

Menetelmiin kuuluvat Approval, Acknowledgement, Folderit eSign, DocuSign, eID ja Fill fields. Tarkastaminen voi olla tilille määritetty mukautettu menetelmä; sitä ei pidä olettaa kaikille tileille samaksi vakiovalinnaksi. Allekirjoitustapojen saatavuus ja käyttöönotto vaihtelevat. Tarkista tarvittava menetelmä ja sen asetukset erikseen, sillä työnkulun käyttäminen ei itsessään lupaa oikeudellista vaatimustenmukaisuutta.

Due By on tiedoksi näytettävä määräaika. Erillinen Timeout määrää, milloin automaatio siirtyy aikakatkaisun haaraan; arvo 0 tarkoittaa, ettei aikakatkaisua ole. Pelkkä määräajan ylittyminen ei siis lupaa automaattista eskalointia. Jos vastaamaton asia pitää ohjata käsiteltäväksi, määritä aikakatkaisu, jatkotoimi ja ihminen, joka vastaa asian selvittämisestä.

Kansiot dokumentin elinkaaren tukena

Selkeä malli on Luonnos → Tarkastuksessa → Hyväksytty → Arkistoitu. Kansiot voivat näyttää tiimille, missä vaiheessa dokumentit ovat. Tämä toimii, kun kansioon siirtämistä vastaava päätös on todella saatu ja käyttöoikeudet tukevat sovittuja rooleja. Kansion nimi ei korvaa päätöstietoa.

Arkistoitu-kansioon siirtäminen ei itsessään määritä lakisääteistä säilytysaikaa eikä lupaa automaattista poistamista. Sopikaa, kuka saa muuttaa hyväksyttyä sisältöä, mikä versio on tarkoitettu käytettäväksi ja miten arkistoa hoidetaan. Muuten rakenne voi näyttää järjestelmälliseltä, vaikka sen perusteella ei voi luotettavasti päätellä dokumentin todellista tilaa.

Esimerkki 1: sopimuksen tarkastus ja tuloksen mukainen reitti

Oletetaan, että uudet sopimusversiot lisätään Sopimukset/Tarkastuksessa-kansioon. Tavoitteena on kerätä nimettyjen vastuuhenkilöiden päätös ja siirtää tiedosto sen perusteella eteenpäin. Molemmat osat voidaan kuvata yhdessä visuaalisessa työnkulussa:

1. Valitse File version added. Rajaa sijainti tarkastuskansioon ja tarvittaviin alikansioihin sekä kohdetyyppi tiedostoksi.
2. Lisää Request action ja menetelmäksi Approval. Nimeä lakiasioiden, talouden ja johdon osallistujat käyttäjinä tai ryhminä. Esimerkiksi kaikkien kolmen vastaus voidaan vaatia ja yhden hylkäyksen vaikutus määrittää erikseen. Metatiedot eivät tässä esimerkissä valitse osaston henkilöitä automaattisesti.
3. Yhdistä pyynnön Success tulokseen Move → Hyväksytty ja Failure tulokseen Move → Korjattava.
4. Jos asetat aikakatkaisun, yhdistä Timeout tulokseen Move → Jatkoselvitys. Nimetty omistaja tarkistaa tilanteen ja päättää jatkosta.

Myös erillinen jatkoautomaatio on mahdollinen, kun valmistumisen ja tuloksen ehdot on määritetty oikein. Pelkkää Request responded -tapahtumaa ei saa käsitellä koko hyväksynnän valmistumisena: se kertoo yhden vastauksen saapumisesta. Jatkoreitin on perustuttava sovittuun valmistumissääntöön ja asianmukaiseen lopputulokseen.

Testaa uuden version lisääminen avoimen tarkastuksen aikana. Aiempi päätös pysyy sidottuna tarkastettuun versioon, joten uusi sisältö tarvitsee sovitun käsittelyn. Samalla on varmistettava, etteivät toistuvat tapahtumat synnytä tarpeettomia päällekkäisiä pyyntöjä. Muuten automaatio voi tehdä kokonaisuudesta epäselvemmän juuri silloin, kun sopimusta muutetaan.

Esimerkki 2: luottamuksellisen kansion jakamisten tarkastus

Toinen mahdollinen työnkulku käynnistyy Share added -tapahtumasta rajatussa luottamuksellisessa kansiossa. Määritä sijainti ja kohdetyyppi tarkasti ja lähetä Request action tietoturvasta vastaavalle tarkastajalle. Käytä sopivaa mukautettua tarkastusmenetelmää, jos tilillä on sellainen; muussa tapauksessa Approval voi toimia selkeiden ohjeiden kanssa.

Tarkastaja selvittää todellisen vastaanottajan ja jakamisen oikeudet. Työnkulku reagoi jakamisen luomisen jälkeen. Se ei ole ennakoiva ulkoisen jakamisen esto, automaattinen vastaanottajaluokitus tai käyttöoikeuden peruutus. Jos korjausta tarvitaan, ihminen muuttaa varsinaista jakamista dokumentoitujen käyttöoikeustoimintojen avulla. Tiedoston siirtäminen ei yksin todista linkin tai jaon poistuneen.

Kokeile myös tavanomaista sallittua jakamista ja jakamista seurattavan kansion ulkopuolella. Näin selviää sekä tarkastustehtävien tarkoituksenmukaisuus että rajauksen toiminta. Vastuuhenkilöllä pitää olla ohjeet löydöksen arviointiin ja korjaamiseen, jotta näkyvyys johtaa tarpeelliseen toimintaan.

Kolme vältettävää virhettä

Liian laaja rajaus. Kaikkien tapahtumien seuraaminen kaikkialla synnyttää hälyä. Aloita yhdestä kansiosta, oikeasta kohdetyypistä ja tarpeellisesta tapahtumasta. Laajenna vasta ymmärretyn tarpeen perusteella.

Yksi työnkulku yrittää tehdä kaiken. Pidä kaavio luettavana. Yksi selkeä pyyntö tulosreitteineen voi kuulua samaan työnkulkuun. Erilliset automaatiot voivat auttaa laajemmassa prosessissa, jos niiden valmistumisehdot ja vastuut ovat täsmälliset. Jakaminen ei itsessään korjaa virheellistä logiikkaa.

Reititysmalli unohtuu. Jos hyväksytty tiedosto näyttää väärään paikkaan jääneeltä luonnokselta, käyttäjät eivät luota tilaan. Sopikaa kohdekansioiden merkitys ja oikeudet ennen automaattisia siirtoja.

Käyttöönoton tarkistuslista

• Uusi versio sovitussa paikassa käynnistää prosessin; rajauksen ulkopuolinen tiedosto ei käynnistä sitä.
• Hyväksyntä ja hylkäys johtavat oikeisiin kohteisiin vasta valmistumissäännön mukaisesti.
• Vastaamatta jättäminen ja määritetty aikakatkaisu käsitellään suunnitellusti.
• Avoimen pyynnön aikana lisätty uusi versio ei muutu vahingossa hyväksytyksi eikä synnytä hallitsemattomia kaksoispyyntöjä.
• Poissa olevan tarkastajan korvaamisesta ja eskaloinnin omistajasta on sovittu.
• Lopullinen tiedosto, versio, käyttöoikeudet ja tapahtumahistoria vastaavat tavoitetta.

Kolme käytännön kysymystä

Onko suunnittelija vain hyväksyntöjä varten? Ei. Myös reititys sekä hallittu reagointi metatietoihin, tunnisteisiin, jakamisiin ja pyyntöjen tuloksiin voivat vähentää käsityötä. Aloita siitä, missä työ nyt katkeaa.

Pitääkö osata ohjelmoida? Visuaalinen määritys ei tavallisesti edellytä ohjelmointia. Vaikeampi tehtävä on sopia prosessi, roolit ja poikkeukset. Ylläpitäjän pitää silti ymmärtää valittujen ehtojen ja oikeuksien vaikutukset.

Mistä kannattaa aloittaa? Valitse yksi viiveitä tai virheitä aiheuttava prosessi: sopimusten hyväksyntä, ohjeeseen tutustumisen kuittaus, päätöksen jälkeinen siirto tai jakamisen tarkastus. Kirjoita sen tapahtuma, ehdot, vaiheet ja tulokset ennen kaavion rakentamista.

Seuraava askel

Tutustu Workflow Designerin käyttöohjeeseen ja dokumenttien työnkulkujen yleiskuvaukseen. Tarkista hinnastosta nykyisen tilauksen mahdollisuudet ja tarvittavan allekirjoitustavan määritykset. Ota ensin käyttöön yksi kokonainen, tarkistettu prosessi ja lisää vaiheita vasta, kun niille on selvä tarve.