Skip to main content

​
Overview

This guide walks you through building and running a basic simulation by hand. By the end you’ll have a working model, a completed run, results you can read, and a Snapshot ready for experiments.
The fastest path to a first simulation is conversational: describe your process to Dexter — or start from your own data with Your First Project — and the agent builds the model for you. This page is the manual walkthrough for when you want to understand each piece yourself. The two paths produce the same artifacts and mix freely: Dexter already knows which model you have open, so you can hand any step below to it mid-build.

​
Step 1: Pick a Factory and Create a Model

A model lives inside a factory. Pick the factory you want to work in from the global selector at the top, then open the Modeler and create a new model from the model selector in the top bar. Give it a name and an optional description. The model is your container: every component, configuration field, and run lives inside it.

​
Step 2: Define Your Entities

Entities are the items that flow through your simulation: raw materials, intermediates, finished goods. They’re factory-scoped, so anything you define here is reusable across every model in the same factory. In the Modeler’s left panel, open the Library tab. At the bottom of the panel are Entities and Lookups buttons: click Entities to open the modal and add the items your model needs. Each entity type carries typed attributes (Boolean, Number, Text, Text List, Number List) that get stamped when the entity is created at a Source, travel with it through the graph, and can be read by any expression along the way.

​
Step 3: Build the Model Graph

The canvas is where you build your simulation as a graph of connected components. The Library tab holds the component palette:
  • Source: generates entities and introduces them into the model
  • Process: applies a delay, optionally consuming resources
  • Buffer: holds entities in a queue with an optional capacity limit
  • Router: splits entity flow based on logic you define
  • Station: a capacity-constrained container that groups components into a work center
  • Combiner, Separator, Transformer: batch entities together, split one into many, or change/mutate an entity. Typically attached to a Station rather than standalone.
  • Sink: removes entities from the model. The exit point.
Resources aren’t dragged onto the canvas. They’re model-scoped capacity pools (workers, machines) defined in the side panel and attached to the Processes that draw from them. Drag a component from the Library onto the canvas, then connect components by dragging from one node’s output handle to another’s input handle. The minimum viable model is Source → Process → Sink.

​
Step 4: Configure Components

Click any component on the canvas to open its configuration panel. For a first model:
  • Source: which entity type to generate, arrival logic (a fixed interval, a distribution, or a DSL expression), and initial attribute values
  • Process: processing time, resource requirements, optional Station placement
  • Router: routing logic — conditional rules, percentage splits, or round robin
  • Resource (side panel): capacity and allocation discipline
Most numeric fields accept either a literal value or an expression referencing constants and lookup tables, entity attributes, and simulation state. Define a constant for any number you expect to tune later — it pays off the first time you sweep a scenario.
A Transformer doesn’t have to change the entity type: configuring the same input and output type is the standard way to mutate attributes mid-flow (incrementing a rework counter, marking a QC result). And when you need batching, a Hold-mode Buffer with a conditional Release Entity hook often beats Combiner + Separator because it preserves per-entity lineage. See Combiners, Separators & Transformers.

​
Step 5: Set Simulation Duration

In the model’s top bar, set how long the simulation should run using the DDD:HH:MM:SS duration picker. This controls the length of each run in simulated time. If the run should follow real calendar time — shifts, planned releases, downtime windows — pair the model with a schedule instead. Schedule material releases are a second arrival mechanism that coexists with your Sources’ own arrival logic, so decide deliberately which one (or both) drives each entry point.

​
Step 6: Run the Simulation

The run controls live at the bottom of the canvas: Run simulation (green play), Step, and Playback speed. Click Run simulation to execute the model end to end. Runs execute against your live working model, so iteration is fast: tweak, run, repeat. The play button doubles as the validation indicator. Green means the model is structurally valid and ready. Red means there’s a specific blocker: hover the button to see the error and a Fix with Assistant action that hands the failure to Dexter for a one-click proposal.

​
Step 7: Review Results

Open Results to see your run’s output:
  • KPIs: single-number metrics. KPIs aren’t a fixed built-in set — they’re authored on your model (describe the metric you want and Dexter writes the underlying query), then computed automatically on every subsequent run. Formats cover counts, percentages, durations, currency, and more.
  • Charts: visualizations authored the same way, from time series and bar charts to histograms and mixed multi-series charts.
  • Event-level data: every run records a full event-level trace — entity lifecycles, process activity, resource activity — that the results views and Dexter can drill into when a KPI looks off.
When you want to share what you found, ask Dexter for a report: it can produce PDF, Word, PowerPoint, or Excel deliverables straight from your results.

​
Step 8: Capture a Snapshot

Click the disk icon in the Modeler’s top bar to open the Create Snapshot dialog. Give it a name (e.g., “First run baseline”) and an optional description, then click Create Snapshot.
A Snapshot isn’t Save. The Modeler auto-saves your edits continuously, and plain runs execute against the live model. A Snapshot is an immutable capture of model + schedule — the unit that Experiments and Monte Carlo replay as cases. Capturing one now gives you a frozen baseline to compare every future change against.

​
What’s Next