Connections
Connections are the arrows between components. Each one has a type — request, response, message, publish, data, control, or error — and the editor picks the type from the ports you connect.
Two ways to connect
On the canvas, drag from an output port to an input port (in Design mode). While you drag, ports that can accept the connection light up green; ports that can’t are crossed out. Prefer the keyboard? Open the Connect panel, pick the source component and output port, the target component and input port, add an optional label, and press Add typed connection. Both paths apply exactly the same rules.
Hover a port to inspect the fields Mockflow uses before it accepts a connection. A useful mental model is “same message, same contract”:
| Port field | What it controls |
|---|---|
| Direction | The source must be output and the target must be input. |
| Message kind | Must match exactly, such as request, response, command, event, record, control, or objectRef. |
| Payload contract | Must match the full versioned identifier, for example mockflow.request.v1. Similar labels do not make different contracts compatible. |
| Role | The source and target roles derive the edge kind. You do not choose the kind from a separate menu. |
| Max connections | When a port declares a limit, the editor rejects the next connection after that limit is reached. |
Response handles are reserved for the reverse side of a request. If the editor will not let you start or finish on a response handle, create the forward request first.
Requests get their response for free
When you draw a request between two components, Mockflow automatically creates the return path — the dotted response line — and keeps the pair linked with one interaction ID. You only draw the forward arrow; trying to draw the response directly is rejected.
The same atomic creation applies to two intrinsic data queries: a service command into a database's query input adds the database result return, while a command into an Object Storeget input adds both its object and missing returns. The reverse ports must exist, have compatible message kinds and contracts, and have room for the new edges.
Change the line routing
The Connection routing control changes only how edges are drawn in your browser. Choose Straight for direct lines, Smooth step for softened orthogonal corners (the default), or Bezier for curves.
Routing is a visual preference, not graph data. One style applies to every connection in that diagram, it is saved for that diagram in the current browser, and it does not change validation or simulation. Another collaborator may see a different routing style.
Conditions and conditional paths
Conditions on behavior actions are edited in a selected component'sBehavior tab. Choose whether all orany clauses must match, then compare a value from the payload, input, variables, a fixture, or the current arrival. The pointer uses JSON Pointer syntax; the supported operators areequals, not equals, exists, and not exists, with up to eight clauses. A false condition skips that action; it does not delete or hide the connection.
An edge-level when expression is narrower: it is valid only on a Topic's deliverOut subscription route, and uses expression v2. It is not a general condition field for every connection. If it is attached to another edge, the graph Problems report marks the condition scope invalid.
Example: a handler can run emit only when/order/status equals paid. For a topic filter, keep the expression on the Topic delivery route; putting it on the request or response pair will not make that pair conditional.
The seven connection types
You never pick a type from a menu — it follows from the ports you connect. The line style and the small badge on each arrow tell you what kind of traffic it carries:
| Type | When you’ll see it |
|---|---|
| Synchronous request | One component asks another and waits for the answer. Solid teal line. |
| Synchronous response | The answer coming back. Dotted teal line — created for you automatically. |
| Asynchronous message | Fire-and-forget: send it and move on, like publishing to a queue. Dashed purple line. |
| Event publish | A publish or subscribe route for an event. A topic can fan one event out to several subscription connections. Fine-dotted purple line. |
| Data access | A read, write, acknowledgement, or negative acknowledgement involving stored or queued data. Solid amber line. |
| Control | A signal that steers behavior rather than carrying business data, like starting a timer. Solid dark-teal line. |
| Error | A path leaving a terminal port, such as a rejected request or dead-letter route. Solid orange line. |
What the editor checks for you
Mockflow validates every connection as you make it, so a diagram that looks right also behaves right. The rules, in plain terms:
- Connections run from an output port to an input port — never the other way.
- Both ports must have the same message kind and the same versioned payload contract. A request output cannot plug into an event input, even if the labels look similar.
- A component cannot connect a port to itself.
- An identical endpoint pair with the same label can exist only once. A different label or a paired interaction is distinct, subject to port limits.
- Some ports have a connection limit — for example a queue's dispatch port takes one consumer.
- Draw the request first. Mockflow adds the matching response connection itself, so you never draw responses by hand.
When a connection is rejected, the editor tells you exactly why — for example “mockflow.request.v1 is incompatible with mockflow.event.v1.” Check direction, message kind, payload contract, and port multiplicity before trying again. If you selected an existing response or intrinsic result port, create its request edge instead.