Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Aston2710/mc-modeler/llms.txt

Use this file to discover all available pages before exploring further.

MC Modeler ships with 37 BPMN 2.0 elements drawn directly from src/domain/bpmnElements.ts. They span five categories — Events (12), Activities (9), Gateways (5), Connections (4), and Containers (7) — and are organized in the left-side palette in whichever display mode you prefer. Every element maps to an official OMG BPMN 2.0 type, ensuring that diagrams you export open correctly in Bizagi Modeler, Camunda, and any other standards-compliant tool.
The maximum number of elements per diagram is 500 (MAX_ELEMENTS = 500). If you attempt to add element 501, a warning notification appears. For diagrams approaching this limit, consider splitting the process into linked sub-diagrams.

Palette Display Modes

The palette can be shown in three modes, configurable in User Preferences (UserPreferences.paletteMode):

Grid mode

All elements shown as a flat icon grid, grouped by category with a count badge. Best for users who know all element icons by heart.

Dropdown mode

Each category has a collapsible chevron. Only the category headings are visible by default; expand any group to reveal its elements.

Bizagi mode

Mirrors Bizagi Modeler’s palette: a compact grid of base elements with a small dropdown arrow on each cell to access variant sub-types. Best for teams migrating from Bizagi.

Bizagi-Style Grouped Palette

In Bizagi mode, each palette cell shows a base element. Click the small dropdown arrow on the cell to reveal its variants. The groupings come directly from BIZAGI_GROUPS in the source:
Base elementVariants accessible via dropdown
Start eventTimer, Message, Signal, Conditional
TaskUser, Service, Script, Send, Receive, Business Rule, Sub-process, Call activity
Intermediate eventMessage, Timer
Exclusive gatewayParallel, Inclusive, Event-based, Complex
End eventMessage, Error, Terminate
PoolLane
Group(no variants)
Phase(no variants)
Text annotation(no variants)
Image(no variants)
Data object(no variants)

Events (12 elements)

Events represent something that happens during a process. They are shown as circles with visual markers inside indicating the trigger or result type.
Element keyBPMN typeEvent definitionDescription
startEventbpmn:StartEventNonePlain start event — process begins here
startTimerEventbpmn:StartEventbpmn:TimerEventDefinitionProcess triggered at a specific time or interval
startMessageEventbpmn:StartEventbpmn:MessageEventDefinitionProcess triggered by receiving a message
startSignalEventbpmn:StartEventbpmn:SignalEventDefinitionProcess triggered by a broadcast signal
startConditionalEventbpmn:StartEventbpmn:ConditionalEventDefinitionProcess triggered when a condition becomes true
intermediateEventbpmn:IntermediateCatchEventNonePlain intermediate event — pause or checkpoint
intermediateMessageEventbpmn:IntermediateCatchEventbpmn:MessageEventDefinitionWait for an incoming message mid-process
intermediateTimerEventbpmn:IntermediateCatchEventbpmn:TimerEventDefinitionWait for a timer to expire mid-process
endEventbpmn:EndEventNonePlain end event — process finishes normally
endMessageEventbpmn:EndEventbpmn:MessageEventDefinitionSend a message when the process ends
endErrorEventbpmn:EndEventbpmn:ErrorEventDefinitionProcess ends by throwing an error
endTerminateEventbpmn:EndEventbpmn:TerminateEventDefinitionImmediately terminates the entire process instance
BPMN 2.0 color convention: start events render with a green fill, end events with a red fill, and intermediate events with a white/gray fill — matching the OMG standard color scheme.

Activities (9 elements)

Activities represent work performed within a process. All activities render as rounded rectangles with a type icon in the upper-left corner.
Element keyBPMN typeDescription
taskbpmn:TaskGeneric task — no specific performer or mechanism assigned
userTaskbpmn:UserTaskHuman-performed task; supports assignee and candidate group properties
serviceTaskbpmn:ServiceTaskAutomated task executed by a system or service
scriptTaskbpmn:ScriptTaskTask that executes a script (e.g., JavaScript, Groovy)
sendTaskbpmn:SendTaskTask that sends a message to another participant
receiveTaskbpmn:ReceiveTaskTask that waits to receive a message
businessRuleTaskbpmn:BusinessRuleTaskTask that invokes a business rule engine
subProcessbpmn:SubProcessContains a nested process; can be collapsed or expanded inline
callActivitybpmn:CallActivityReuses a globally defined process or task (calledElement attribute)

Sub-process: Collapsed vs Expanded

A sub-process has two visual states:
Rendered as a task with a + icon at the bottom center. The internal content is hidden. Size defaults to 90 × 60 px — same as a regular task.

Gateways (5 elements)

Gateways control the flow of the process by splitting or merging paths. They render as diamond shapes with a symbol inside.
Element keyBPMN typeSymbolRouting semantics
exclusiveGatewaybpmn:ExclusiveGateway× (X)Exactly one outgoing path is taken (XOR)
parallelGatewaybpmn:ParallelGateway+All outgoing paths are taken simultaneously (AND)
inclusiveGatewaybpmn:InclusiveGatewayOne or more outgoing paths are taken based on conditions (OR)
eventBasedGatewaybpmn:EventBasedGatewayThe first event that occurs determines the path taken
complexGatewaybpmn:ComplexGateway*Complex routing condition defined by a custom expression
BPMN 2.0 routing rules:
  • An exclusive gateway must have exactly 1 incoming and 2+ outgoing flows, OR 2+ incoming and 1 outgoing. A single input / single output gateway is flagged by the validator.
  • An event-based gateway can only have outgoing flows that connect to intermediate events (message, timer, signal, conditional).

Connections (4 elements)

Connections link flow elements together. The type of connection used depends on whether the elements are in the same pool or different pools.
Element keyBPMN typeDescription
sequenceFlowbpmn:SequenceFlowStandard flow between elements within the same pool — shown as a solid arrow
messageFlowbpmn:MessageFlowCommunication between different pools — shown as a dashed arrow with an open arrowhead
associationbpmn:AssociationConnects artifacts (annotations, data objects) to flow elements — shown as a dotted line
dataAssociationbpmn:DataAssociationConnects data objects to activities — shown as a dotted arrow
Critical routing rules enforced by MC Modeler:
  • Sequence flows can only connect elements within the same pool. Attempting a cross-pool sequence flow is blocked.
  • Message flows can only connect elements in different pools. Using a message flow within a single pool is blocked.
  • Connections that violate these rules display an error and the connection is not created.

Containers (7 elements)

Containers group or frame other elements visually or semantically.
Element keyBPMN typeDescription
poolbpmn:ParticipantRepresents a process participant (organization, system, role). Sequence flows stay inside; message flows cross pool boundaries.
lanebpmn:LaneSubdivides a pool into swimlanes (department, role). Cannot exist outside a pool.
groupbpmn:GroupVisual grouping artifact — no routing semantics. Shown as a rounded dashed rectangle.
phasebpmn:GroupMC Modeler custom extension — a vertical phase column. Maps to bpmn:Group in XML with a flujo:phaseName extension attribute. Exported as a Bizagi Milestone in .bpm format.
textAnnotationbpmn:TextAnnotationFree-text comment linked to elements via an association.
imagebpmn:TextAnnotationAn image placeholder element backed by the image library. Links to a LibraryImage by ID via the flujo:linkedImages attribute. Rendered via ImageBadgeModule.
dataObjectbpmn:DataObjectReferenceRepresents data produced or consumed by activities. Default size: 36 × 50 px.

Pool and Lane Rules

Pool (bpmn:Participant)
 └─ Lane (bpmn:Lane)        ← optional, can have multiple
     └─ Flow elements       ← tasks, events, gateways
  • Lanes cannot exist outside a pool.
  • If at least one pool is present in the diagram, flow elements must be placed inside a pool or lane — they cannot float on the canvas independently.
  • A pool with no lanes is valid (pool simple).

Phase Element

The Phase is a custom Flujo/MC Modeler extension not found in standard BPMN tools. It is stored as a bpmn:Group in the XML with the flujo:phaseName and flujo:phaseColor extension attributes. When exported to Bizagi’s .bpm format, phases are converted to Milestones with relative coordinates inside their parent pool.
<!-- Phase stored in BPMN XML -->
<bpmn:group id="Phase_abc123" flujo:phaseName="Approval Phase" flujo:phaseColor="#5B8DEF" />

BPMN 2.0 Rules Summary

Every process with activities must have at least one start event and one end event. In a collaborative diagram with multiple pools, each pool that contains activities needs its own start and end events. The validator reports MISSING_START_EVENT and MISSING_END_EVENT errors for pools that are missing them.
Boundary events attach to the border of a task or sub-process only — not to gateways, other events, or containers. Interrupting boundary events cancel the host activity when triggered; non-interrupting boundary events allow the activity to continue running.
The validator checks all flow elements (tasks, events, gateways) for connectivity. Any element that has no incoming and no outgoing connections is reported as a DISCONNECTED_ELEMENT warning, except for start events (no incoming required) and end events (no outgoing required).
Every element receives an auto-generated ID in the format {Type}_{shortUUID} (e.g., Task_3f2a1b, Gateway_9c4d2e). IDs are immutable after creation and are not displayed in the palette or canvas label — only in the properties panel (read-only field).

Build docs developers (and LLMs) love