Your first flow in 15 minutes

Nothing to authenticate, nothing to provision, no code. You will build a flow whose only job is to exist visibly: a clock publishes a heartbeat onto the bus once a minute, a subscription picks it up and discards it, and Tracking shows you every hop. Fifteen minutes, and the mental model that runs this whole platform is yours.

The shape you are building is the shape of every Art2link flow, something publishes, a subscription selects, something delivers:

Why a Null port as the destination? Because it is the one delivery target with zero setup, it subscribes, runs its stages, and discards. Every minute you wait for a real database or mailbox to be configured is a minute not spent understanding the bus. The real adapters are step six.

Build it, step by step.

Step One

Create the Application

Create an Application named QuickStart with namespace QuickStart. Names are code-safe identifiers, letters and digits, no dots, no spaces, because they appear inside expression tokens later. Select it; everything you build next belongs to it.

Step Two

Create the clock, a Scheduler receive port

Create a receive port named HeartbeatClock on the Scheduler adapter: Repeat Every 1, Repeat Unit Minutes, Time Zone yours, Daily Window off. Set Payload to:

{ "hello": "bus" }

Set Publish Message Type Fallback to HeartBeat. The fallback is what stamps the type here: this port runs no classification, so every tick publishes its payload as a HeartBeat. Setting the fallback also registers HeartBeat as a message type the moment you save the port, so the sink you build next has a type to subscribe to. Set this port’s tracking level to Enabled + Body too.

Step Three

Create the sink, a Null send port

Create a Null port named HeartbeatSink. Give it one subscription:

{{Message.MessageType}} == "HeartBeat"

That line is the whole routing system in miniature: the port volunteers for every message on the bus whose type is HeartBeat, the type your clock just published. Nothing addresses a destination directly. Set the port’s tracking level to Enabled + Body, so you can see everything while you learn.

Step Four

Start, sink first, clock second

Start HeartbeatSink, then start HeartbeatClock. The order is a habit worth keeping from day one: subscribers before publishers, so the first message out finds its subscription waiting. Configuration takes effect immediately, there is no deploy step, and stopping a port is just as instant and just as reversible.

Step Five

Watch it in Tracking

Open Tracking. Within a minute, a run appears: the tick received by HeartbeatClock, published to the bus as a HeartBeat, matched by HeartbeatSink’s subscription, delivered, discarded. Click into the run: one Tracking ID stitches every hop together, and the body viewer shows your { "hello": "bus" } payload at each stage. This screen is where every debugging session on this platform starts, you now know the answer to “where did my message go?” before you have ever lost one.

Step Six

Stop the clock, keep the model

Stop HeartbeatClock so it does not tick forever, and keep the Application as a scratchpad. You have now used every load-bearing idea once: a port published, a type was stamped, a subscription selected, a port delivered, Tracking saw it all. Everything from here is the same shape with real payloads: swap the Scheduler for an API Listener and the Null port for a SQL or O365 Mail send port and you have the order intake tutorial, the recommended next build. The full mental model lives in three short reads: Applications, Ports, Expressions & bindings.

Tracking levels, the day-one habit. Enabled + Body is the right setting while you build and debug; production ports usually drop to Only on Error so the TrackingDB stores what you need and nothing more, the trade-off is described in Tracking.