Skip to main content

Core concepts

Processita is a workflow automation tool: you design a process as a diagram, and Processita runs real instances of that process, step by step, tracking exactly where each one is and what data it carries. This page introduces the handful of terms everything else in these docs builds on.

Tenants​

A tenant is your organization's own workspace — its models, process instances, tasks, and members all belong to exactly one tenant, and are never visible to another tenant. If your company uses Processita, you'll typically only ever work inside your own tenant.

A single user can belong to more than one tenant at once (useful if you consult for, or work across, more than one organization), and can hold a different role in each:

  • Admin — can manage the tenant itself: inviting and removing members, and changing tenant settings.
  • User — a regular member: can create and edit models, start and manage process instances, and complete tasks.

To add someone to your tenant, an admin sends them an invitation by email; the invitee accepts it to join.

Models​

A model is a process diagram — drawn as a BPMN flowchart in the built-in editor, made up of steps (tasks), decision points (gateways), and the connections between them.

Saving updates whichever version you currently have open, in place — it never silently creates a new one. Starting a new version on top of your current one (so you can keep iterating without touching what's already there) is a separate, deliberate action. Whichever version a process instance started with is permanently frozen for that instance — editing or even replacing that version later never affects an instance already running on it, so in-flight work is never disrupted by a later change. Starting a brand-new instance, or waiting on a call activity, normally uses whichever version is currently the latest, unless you explicitly pick an older one.

A model needs at least one start event before it can be run at all — and can have several coexisting at once, each an independent alternative entry point: whichever one actually triggers determines where a new instance begins, never all of them together.

  • A plain start event (no message/timer attached) is triggered directly — starting it yourself (via the API or the editor's Run button), or another model's call activity targeting it (see "Call activities" below). At most one of these per model — there's no way to pick between several if you tried to manually start one.
  • A message start event (see "Messages") is triggered by a correlated message arriving. Any number of these are allowed, each distinguished by its own message name.
  • A timer start event (see "Timers") triggers itself automatically on its own schedule. Any number of these are allowed too, each independently scheduled.

A model with, say, a plain start event and a timer start event supports both: start it yourself whenever you like, and it also starts itself on schedule — the two don't interfere with each other.

Process instances​

A process instance is one running (or finished) execution of a model — think of the model as the blueprint, and an instance as one actual case following it. Each instance carries its own set of variables: a bag of data (names and values) that gets read and updated as the instance moves through the diagram — for example, a user task might ask someone to fill in a value, and a later decision point might branch based on it.

An instance always has one of these statuses:

  • Running — actively moving through the diagram, or waiting on something that will resolve on its own (like a timer).
  • Waiting — paused at a task that needs a person to act on it.
  • Done — finished successfully.
  • Error — stopped because something in the process failed (for example, a step's data didn't make sense).
  • Cancelled — a user manually stopped it before it finished.

"Done", "Error", and "Cancelled" are all final — the instance won't progress any further.

Call activities​

A model can include a call activity step that starts another model as its own, separate child process instance, and waits for it to finish before continuing — much like calling a reusable sub-routine. Once the child instance finishes, its parent can read back whatever data the child produced and carry on. The parent instance's detail view links straight through to each child instance it started.

Tasks​

A task is a step in a process instance that needs a person to do something — fill in information, make a decision, approve something — before the instance can move on. Tasks aren't assigned to a specific person: any member of the tenant can see and complete any open task. Once someone completes a task (optionally supplying some data), the instance resumes from that point.