Core concepts
The key terms and mental model behind Process Map, independent of any single page's task or reference material.
Process Map
| Concept | Description |
|---|---|
| Node | A step in the process. Can be a task, queue, start, or end. |
| Connection | A directed edge between nodes. Can carry a probability weight (probabilistic routing) or a conditional expression (conditional routing). |
| Distribution | The probability distribution used to sample service times or arrival intervals. |
| Resource | A shared constraint (e.g. a person or machine) that limits concurrency across nodes. |
| Scenario | A saved snapshot of the full graph plus its configuration. |
| Simulation run | One execution of the DES engine over a scenario. |
Node flow
Every process you model follows a path: work items enter through a Start node, move through Task nodes where processing happens (optionally waiting in Queue nodes when capacity is limited), and exit through an End node. Understanding when to use each type helps you accurately represent real-world workflows in the simulation.
Use a Queue node in front of any Task that has limited resources. This accurately models the backlog that builds when demand exceeds capacity, and lets you measure wait times in simulation results.
| Concept | Description |
|---|---|
| Work item | A single unit that flows through the process (a customer, a ticket, a job) |
| Arrival | When a new work item enters the process at the Start node |
| Service time | How long a Task takes to process one work item |
| Queue | A buffer where work items wait when downstream capacity is unavailable |
A well-formed process must have exactly one Start node and at least one End node.
Connections
- Output handle — the right side of a node where connections begin. Drag from here to create a new connection.
- Input handle — the left side of a node where connections arrive. Drop onto here to complete a connection.
- Edge direction — connections are directional: work items always flow from the source node (output handle) to the target node (input handle).
- Routing mode — when a node has multiple outgoing connections, you choose either probabilistic or conditional routing to determine which branch a unit takes.
Simulation
Running a simulation means testing your process many times with slightly different random values — like running the same day at your business 100 times to see how it usually goes and what can go wrong.
- Discrete-event simulation — the engine advances a simulation clock from event to event (an arrival, a task start, a task completion) rather than stepping through time in fixed increments. This makes it fast even for long time horizons.
- Simulation clock — the engine's internal time counter, starting at zero. All timing (arrivals, service, waits) is measured against this clock.
- Test runs (reps) — independent simulation runs using the same configuration but different random seeds. Running multiple test runs smooths out randomness so that output metrics reflect the stable behavior of your process, not a lucky or unlucky single run.
See Node flow above for what a work item and service time are.
Resources
- Resource pool — a named asset with a fixed total capacity (number of units). All tasks that require the resource draw from the same pool.
- Unit count — how many units of a resource a single task occupies simultaneously. A task requiring 2 analysts holds 2 units while it runs.
- Acquire — when a task starts, it claims the required units from the pool. If not enough units are free, the task waits in a queue.
- Release — when a task finishes (its service time completes), it returns all acquired units to the pool.
- Cost — an optional dollar-per-period rate used to compute estimated resource cost in the simulation output.
Scenarios
Scenario — a named container for one process map. Each scenario stores its nodes, connections, resources, router definitions, and label configuration independently from all other scenarios.
Auto-save — changes you make on the canvas are saved automatically using a short debounce. You do not need to trigger a manual save, but one is available in the header if you want to force a sync immediately.
Undo/redo stack — a per-session history of every canvas action. The stack is stored in your browser and is cleared when you reload the page.
Version — an internal counter that increments on every save. If two browser tabs have the same scenario open and both try to save, the second write is rejected with a conflict banner so no changes are lost.
Sharing — a scenario can be published with a public read-only link. The link works until you revoke it. Viewers can inspect the canvas and results but cannot edit or run simulations.
Config format
The .conf format is intended for advanced users who want to:
- Store process models in version control alongside other project files
- Share models as plain text files without needing an account
- Automate scenario creation or modification with scripts
A .conf file is the canonical serialization of a process model. Every scenario in the app maps to exactly one valid .conf file, and a valid .conf file can be loaded into any scenario. The format is designed to be diffable — each logical change (adding a node, adjusting a distribution) produces a minimal, readable diff.