Definitions for core concepts used across the Priostack platform, from process modelling standards to credit terms.
Business Process Model and Notation (BPMN 2.0) is the ISO/IEC 19510 standard for describing business processes as flow diagrams. It defines elements such as events, tasks, gateways, and sequence flows that represent how work moves from start to end.
Priostack deploys BPMN 2.0 XML process definitions directly to its execution engine. Each deployed definition can be instantiated any number of times.
See also: Definition, Instance, Token (BPMN)
A case is a CMMN construct representing a unit of work whose exact path is not fully predetermined. Unlike a BPMN process, a case can have tasks that are enabled, disabled, or manually triggered depending on conditions that emerge at runtime.
Priostack supports case management for knowledge-work scenarios such as fraud investigation or insurance claims, where a rigid flowchart is insufficient.
Case Management Model and Notation (CMMN 1.1) is an OMG standard for describing adaptive, knowledge-intensive processes. It models cases as containers of tasks, milestones, and sentries (triggers) that activate work when conditions are met.
CMMN complements BPMN: use BPMN for well-structured flows and CMMN when the process is event-driven and ad-hoc.
A connector is a pre-built integration module that links Priostack workflows to external systems — REST APIs, message brokers, CRMs, ERPs, and cloud services — without custom code. Connectors appear as tasks in the BPMN modeller.
Priostack ships connectors for HTTP, Kafka, Slack, Salesforce, SAP, and SMTP. Custom connectors can be built with the Connector SDK and published to your workspace.
Credits are the unit of compute consumed on Priostack. Every process start, job completion, DMN evaluation, and connector call deducts credits from your workspace balance.
Credits are included free: 100 at signup and 100 every month. The Sandbox tier ships with 100 free credits. Unused credits roll over for 12 months.
See also: Workspace
A decision table is a DMN construct that maps input conditions to output conclusions using a grid of rules. Each row in the table is a rule; when the inputs satisfy a row's conditions, that row fires and its outputs are returned.
Decision tables support hit policies (UNIQUE, FIRST, COLLECT, etc.) that control what happens when multiple rows match.
A process definition is the deployed artefact — the BPMN, CMMN, or DMN XML — registered with the execution engine. Deploying a definition assigns it a key and a version number; prior versions remain active for running instances.
On Priostack, definitions are deployed via the dashboard's Processes tab or via the REST API at POST /api/v1/definitions.
Decision Model and Notation (DMN 1.3) is an OMG standard for representing business decision logic independently of any process. DMN models describe what decisions exist, what information they need, and how they are made — typically as decision tables or literal expressions.
Priostack evaluates DMN decisions inline during BPMN execution or as standalone calls, using the FEEL expression language for rule conditions.
See also: Decision Table, FEEL
The execution engine is the runtime component that interprets BPMN/CMMN/DMN models, manages process state, schedules jobs for workers, and persists audit trails. Priostack's engine is horizontally scalable and processes events asynchronously.
You interact with the engine via the REST API or the dashboard; the engine itself is fully managed — you do not operate it.
Friendly Enough Expression Language (FEEL) is the expression language defined by the DMN specification. It is used in decision table cells and literal expressions to evaluate conditions such as loan_amount > 50000 or credit_score in [700..900].
FEEL is side-effect-free, strongly typed, and designed to be readable by business analysts as well as developers.
See also: DMN, Decision Table
A process instance is one live or completed execution of a process definition. Each instance has its own isolated set of variables, its own current position in the flow, and its own audit trail.
Instances are created by calling POST /api/v1/instances with a definition key and an optional map of input variables. They can be active, waiting for a job, or completed.
See also: Definition, Variable, Token (BPMN)
A job is a unit of work that the engine creates when a process instance reaches a service task. The engine holds the job in a queue until a worker polls for it, executes the work, and completes or fails it.
Jobs carry the instance's variables as input and return updated variables as output. Failed jobs can be retried with configurable back-off.
Layer 2 is Priostack's integration layer that sits between the process engine and external systems. It handles protocol translation, credential management, retries, and fan-out so that BPMN tasks can invoke external services without custom glue code.
Configure Layer 2 connectors in the Connectors tab. Each connector can be reused across multiple process definitions within the same workspace.
A Petri net is a mathematical model of concurrent systems, consisting of places (states), transitions (events), and tokens (markers that move through places when transitions fire). BPMN's execution semantics are formally grounded in Petri net theory.
Priostack's engine uses an extended Petri net representation internally to verify process correctness (deadlock detection, reachability) and to power the token-level audit trail visible in the dashboard.
See also: Token (BPMN), BPMN, Engine
In BPMN, a process is a sequence of activities, events, and gateways that collectively describe how a piece of work is accomplished from a start event to an end event. Processes can be independent or callable from parent processes as sub-processes.
On Priostack, a "process" in the UI refers to a deployed definition together with all its running and completed instances.
See also: BPMN, Definition, Instance
A token is a conceptual marker that traverses the sequence flows of a BPMN process, indicating where in the flow an instance currently is. When a token reaches a parallel gateway, it splits into multiple tokens; when all tokens converge at a joining gateway, they merge back into one.
Priostack visualises tokens in real time on the process diagram in the instance detail view, making it easy to see exactly which step a running instance is at.
Variables are key-value data attached to a process instance. They are set when the instance is started, updated by service tasks and workers, and read by gateways to determine flow direction. Variables are typed (string, integer, boolean, JSON object).
All variable mutations are recorded in the audit trail, making it possible to replay the exact state of an instance at any point in its history.
A webhook is an HTTP callback that Priostack sends to an external URL when a process event occurs — for example, when an instance completes or a job fails. Webhooks let external systems react to workflow events without polling the API.
Configure webhooks in Settings → Webhooks. Each webhook can filter by event type and process definition key.
A worker is any external service that subscribes to a job type, polls the Priostack engine for jobs, executes the business logic, and reports the result back. Workers can be written in any language that can make HTTP calls.
Priostack provides a Simulate Worker button in the dashboard for testing flows without deploying real worker code.
A workspace is the top-level organisational unit on Priostack. It contains process definitions, instances, decisions, connectors, team members, and the credit balance. All billing, permissions, and audit logs are scoped to a workspace.
A user account can belong to multiple workspaces, each with its own credit pool.
See also: Credit