A port is in one of two states: Running or Stopped. There is no separate publish or deploy step, everything you configure on a port is saved and applied immediately. The state only controls whether the port is live: a running port listens, dispatches, or subscribes; a stopped port is inert and takes no part in routing. The actions that move it between them are Start, Stop, and Restart; Restart is a convenience that stops and starts the port in one step, for example to reset a Scheduler receive port’s timer, an action, not a third state. A Paused state for subscriber (send) ports is coming soon: a paused port's subscriptions keep matching and the matched messages are held, not consumed, until the port is started again, the same hold BizTalk operators got by stopping a send port without unenlisting it, useful during deployments and cutovers.

Where you change the state. Not in the port editor. Start, Stop, and Restart are on the Actions menu of the port’s row in the ports list, the three-dot control in the ACTIONS column. The menu shows one of Start or Stop, whichever the port’s current state allows, plus Restart. Open a port for editing and you will not find the state anywhere in the dialog, so operators work from the list and builders work from the editor.

Building a port. Save Draft stores a port with nothing more than a name; a draft is invisible to the runtime, as if the port did not exist, so you can open one, go gather the details you are missing, and pick it up later. Once the required fields are filled in, Save stores the port properly, and a saved port can never return to draft. Because a stopped port does nothing on the bus, you keep configuring it, adapter settings, pipelines, maps, subscription expressions, while it is stopped, taking as long as you need, with each change stored as you make it. When it is ready, start it.

What a stopped port is. Values you have entered are still validated as you save them (a port will not store an illegal value), but a stopped port may sit with its configuration incomplete.

Starting a port. Starting runs the full validation a live port requires: if anything is missing or invalid the same errors surface and the port stays stopped, with nothing lost. Once validation passes the port is live immediately, there is nothing further to deploy. Starting and stopping are reversible: stop a running port and it goes inert again, then start it again when you are ready. To bring a whole integration online, start the send ports first and the receive ports last, so a receive port never publishes to the bus before its subscribers are live; to take it offline, stop the receive ports first.

Port names follow the usual rule: a name must be unique within its Application whether the port is running or stopped, the two states share one namespace.

A port is edited in a single dialog. The sidebar starts with General and then groups every processing stage under two headings, Solicit and Response. Each carries a direction sublabel that follows the port type, Caller → Bus / Bus → Caller on a receive port, Bus → Adapter / Adapter → Bus on a send port: Solicit is always the initiating leg, Response the return. Which way a group actually points therefore depends on which port type you are looking at, and neither name carries a direction on its own. A receive port’s Solicit side is inbound, the message is on its way onto the bus; a send port’s Solicit side is outbound, the message is on its way off it. Read the two together, port type first, every time: “the Solicit side” with no port type named does not identify a position. The four positions are set out in Components classify the Message Type. The names are grouping labels, nothing more; they were chosen over “request” because not every adapter requests anything, a Scheduler receive port solicits a tick rather than receiving a request. BizTalk veterans will recognise the term.

The General tab opens with a General Information panel holding the port’s identity: Name, Application, Port Type (the dropdown carrying Receive, Send, Loopback, and Null), the Adapter with a button beside it that opens the adapter’s own configuration dialog, and the Adapter Message Type. Below the panel sit the Exception Message Type (covered below) and Way (One or Two). There is no Tracking field and no Running/Stopped toggle in the editor: the tracking level is an Application-level setting that covers every port the Application owns, and the port’s state is changed with the Start, Stop, and Restart actions on the row’s Actions menu in the ports list, not from here. The Adapter Message Type is set here, on General, not on any stage pane, and it belongs to the port’s inbound position: a receive port always carries one, a send port carries one only in two-way mode, and loopback and null ports have no adapter and no Adapter Message Type at all. The footer carries the Save Draft and Save buttons described in the lifecycle section above.

On a receive port the Solicit stages appear, and run, in this order: Open Variables → Pipeline → Map → Close Variables. On a send port the group opens with Subscription, the home of the subscription expression, and continues Open Variables → Map → Pipeline → Close Variables, with the adapter dispatch following Close Variables. The order of the two transformation stages tracks the direction of the position, not the port type: an inbound position, meaning the message is on its way onto the bus, runs Pipeline then Map; an outbound position, meaning it is on its way off the bus towards a wire or a caller, runs Map then Pipeline. A receive port’s Solicit side and a two-way send port’s Response side are the inbound ones; a send port’s Solicit side and a two-way receive port’s Response side are the outbound ones. The Pipeline pane is a single selector, labelled Inbound Pipeline at an inbound position and Outbound Pipeline at an outbound one, defaulting to None; the Map pane is a Map Assignment panel offering None, Typed, or Universal; and Open Variables and Close Variables are lists of assignments, empty until you add one.

Typing is settled before any of that runs. At an inbound position the runtime stamps the port’s Adapter Message Type the instant the adapter hands the message to the next step inside the port; at an outbound position the message comes off the bus already carrying the type it was published under. Either way no message inside the port is ever untyped. The Pipeline then restates the type: every component sets a Message Type on every message it emits, see Components classify the Message Type. Publishing, the moment a message lands on the bus, is not a stage you configure: on a receive port it happens after Close Variables, as the final act of the flow. The Map step’s configuration and each stage’s behaviour are covered per port type in Receive port and Send port.

On a two-way receive port the Response group opens with the Subscription tab, a single required Expression field holding the Response Subscription Expression, for example {{Promoted.EDI_Initiate.TPCode}} == "123", followed by Open Variables → Map → Pipeline → Close Variables, the inbound flow mirrored.

Loopback and null ports reuse the send-port editor with the Adapter picker empty. Way is pinned, Two for a loopback, One for a null port, and the null port drops both the Response group and the Exception Message Type field.

One configuration option is independent of port type and direction and applies equally to receive, send, and loopback ports, the Exception Message Type; a null port’s editor has no Exception Message Type field at all. Tracking also applies to every port, but it is not configured on one: the level is set on the Application and governs all of its ports, including null ports.

Exceptions. Exceptions are configured by setting the port’s Exception Message Type. On error, the in-flight message's Message Type is swapped to the exception Message Type and republished to the bus, the payload itself is untouched. Subscribe to that Message Type from another port to handle the failure centrally (a send port that emails an alert, writes to a log, files a ticket). Error traffic flows on its own Message Type rather than mixed in with the original.

Tracking. Not a port setting. The level is chosen once on the Application and applies to every port it owns, so an Application’s runs are recorded at one uniform level end to end on the Tracking screen. Three levels:

A separate, minimal internal tracking is always on for the runtime dashboard (running and suspended transactions), it does not depend on the Application’s tracking level and it is not something you switch on or off anywhere. Mind the cost tradeoff: every tracked step writes to the tracking database and is subject to retention and reindexing jobs.

Send, loopback, and null ports each carry a subscription expression, a Boolean filter the bus evaluates against every published message. Two-way receive ports use one as well, the Response Subscription Expression, to identify which message on the bus is the response to send back to the caller through that same port.

Pub/sub. When a message hits the bus, every send, loopback, and null port has its expression evaluated. Every match gets its own copy and runs its outbound flow independently. The same message can be picked up by any number of ports, or by none.

Message Type. Every message on the bus carries a Message Type, a string identifier, similar in concept to BizTalk's. Subscription expressions most commonly match on it, but can evaluate any of six sources:

Value, NULL, or absent. When a subscription evaluates a promoted value, that value has three states, and the expression grammar can test each of them separately. This matters whenever the promoted field is optional in the payload, because a plain value comparison against a promotion that never resolved just fails to match, telling you nothing about why.

A common shape is a pair of ports that split an optional field between them, one handling the messages that carry it and one catching the rest, so nothing falls through unrouted:

Exists({{Promoted.Order.Region}})     <- regional handler
!Exists({{Promoted.Order.Region}})    <- default handler

Exists takes a single token and returns a Boolean, so it combines with the rest of the grammar like any other predicate, and ! negates it.

For the complete binding-token reference, every family above plus Constants, and where each is used, see Expressions & bindings.