Building and changing the processes your work runs through, without writing code.
The workflow builder is available to users with administrative permissions. If you cannot see Admin in your navigation, ask your internal admin to change your role.
Statuses are the stages a task moves through. A meeting workflow might run: arrange meeting, awaiting meeting, minutes, actions in progress, actions followed up, cancelled or postponed. Each one is a real point in the process that someone can recognise at a glance.
Name statuses for what is happening, not where they sit in the list. Awaiting Client Response tells your team something. Stage 2 does not.
The Forms & Actions tab controls what appears on the status page. Drag an item from the Available Actions bar on the right into the blank box to add it, then configure it in place.
Forms capture data. Actions do things: add a note, put the task on hold, list the documents attached to the case, present a button that moves the task on. Every one of them can be limited to particular user types and hidden behind visibility rules.
Moving rules decide when a task leaves a status and where it goes. They live on the Moving Rules tab. Three kinds are available.
| Rule | How it works |
|---|---|
| Questions answered | Set the status to move to, then choose the question that has to be answered. Tick Specific Answer if only one answer should trigger the move, and type it in. Click Add Question to require more than one. |
| Button clicked | Set the status to move to, then type the button key you gave the button on the Forms & Actions tab. |
| Expert allocated | Moves the task on once an expert has been allocated to it. |
Workflows are versioned, so changing one never quietly rewrites history. Every save creates a revision, stamped with the date and time.
| Revision status | What you can do with it |
|---|---|
| Revision | A historical version. It cannot be edited. |
| Draft | Not in use yet. It can be published or deleted. |
| Live | The version currently running. Create a new revision from it to make changes. |
Run test cases through a new workflow before your team uses it for real work. Finding a broken transition in testing costs minutes. Finding it in production costs a case.
Internal admins can decide which workflows each team member sees, down to individual statuses.
How SwiftCase organises work, how to create your first task, and how to find it again.
Capturing the data your process depends on, and reusing it everywhere else.
Clients, team members, roles, passwords, two-factor authentication and the audit trail.
Everything that records what happened on a case, and who was involved.
Templates that fill themselves in, and the two ways to send email from SwiftCase.
What happens on its own when a task reaches a status, and how to control the timing.
Building your own reports, reading the management information, and telling everyone something.
