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.
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. Set the Application’s tracking level to Enabled + Body while you learn: tracking is an Application-level setting, so this one choice covers both of the ports you are about to create.
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 Adapter Message Type to HeartBeat, a message type you create inline with Format JSON. Every receive port carries this setting and it is required: the type is stamped on the message the instant the adapter hands it to the next step inside the port, so nothing reaches the bus untyped. This is the plainest case there is, the port runs no pipeline, so nothing re-types the message after the adapter and every tick publishes its payload as a HeartBeat. Add a pipeline later and every component in it types what it emits, see Components classify the Message Type.
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. There is nothing to set for tracking here, the Application-level Enabled + Body from step one already covers this port, so you will see everything while you learn.
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.
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.
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.