11 articles about Running processes, in reading order.
Running processes
A drawn process that nobody's software follows is a poster. In Parsware the drawing is what runs: you draw who does what on swimlanes, publish a version, and the engine starts it from a record, sends each step to the right person's task list, and keeps a history of every run. This is how the three parts fit together.
Running processes
Save keeps your work; Publish changes what runs. Each publish is a numbered version, a run keeps the version it started on, and the line under the title says whether what you see is live. Writing this we found Publish stopping after it saved unsaved edits, and fixed it.
Running processes
A change request goes to one person, who may correct it, then to a second, who reads a report of it and approves or rejects. We ran it as two different people, and the run's history says who decided each step. Writing this we found four things that only an administrator never notices, and fixed them.
Running processes
An employee asks for a week off, their manager decides, and a branch sends the request one way or the other. We ran it as both people and read the run afterwards. The sample shipped with roles that only opened the app and a manager's step that said read-only; both are fixed.
Running processes
A purchase order goes to Finance and Legal at the same moment, two people decide on their own, and the process waits for both before it gives one answer. We ran it with Finance signing off and Legal refusing, and watched the run wait at the join in between.
Running processes
A step can be due within a set time, and when it isn't done, the process can offer it to somebody else as well or decide it by itself. A timer makes the process wait. We ran a support ticket through all three, and fixed five things on the way, starting with the designer turning every timer into a plain task.
Running processes
A process can start by itself when a record is created, changed or deleted, or from a button on the record's form and list. Either way the run knows which record it's about. Running the sample as two people found a status that never changed and people named by their email address; both are fixed.
Running processes
Small requests go to a department head, bigger ones to the finance director, the biggest to a committee as well. The bands live in a table finance edits, not in the process, so moving one changes who decides the next request. The sample said it worked this way and didn't; now it does.
Running processes
Every run of a process has a page: the route it has taken so far, where it is now, who it's waiting on, and everything that has happened, in order. From there you can pause it, stop it, or hand a waiting task to somebody else. We followed one change request from start to finish.
Running processes
A run's page says where one request has got to. A process's Insights screen says what keeps happening: how many runs got through, how long work waits before anybody picks it up, where runs stall, and how decisions usually go. Trying it, we fixed two things: decisions are named by their button, and the people view names people.
Running processes
A process moves between environments the way everything else does: in its solution, with its table, its form, its app and its roles. Import publishes it, and uninstall takes it out again. Trying that with a run still waiting, we fixed what happens to the run: it's now stopped, and its history says why.
