A constant has exactly one value at any moment — the value configured in this deployment. The Constants list inside an Application is three columns wide: Name, Description, Value. There is no Dev column, no Prod column, no resolution-by-environment at runtime. There is only the value in this deployment.

Variation across environments does not happen at runtime — it happens at the seam between deployments. An Application that has been wired to {{Constant.DbHost}} in one deployment is moved to another deployment as a snapshot; the destination supplies its own value for DbHost, and the wiring never changes. See Snapshot import below.

Constants are scoped to an Application. From the application menu, the Constants list shows every constant defined in that application. Each entry has these fields:

The list view follows the platform's Selected Application behavior — with an Application selected, the list filters to it and the Application column is hidden; with no selection, the list spans every Application you have access to and the column is shown. Creating a new constant uses the same flow: with an Application selected, the form opens with that Application preemptively chosen; without one, the form exposes an Application picker.

A constant does not declare a data type. The value is a string — literally the characters in the Value field — and the consuming context decides how to interpret it. A constant holding 1433 is text until a SQL adapter's Port setting reads it as an integer; a constant holding true is text until a subscription expression compares it to another string.

This matches how Variables behave when read: the same expression engine resolves both, and string-context coercion is identical. The difference is that a Variable's runtime shape can be a scalar, a list, a sub-tree, or a whole message depending on what wrote to it; a Constant's value is only ever the text the user entered.

Constants are not assigned from XPath, not written by pipeline components, and not mutated by the runtime. The only way the value changes is an operator editing the Constants list, or a snapshot import writing a new value into the slot.

Anywhere a string can be typed in the platform — subscription expressions, map bindings, pipeline component property values, custom function arguments, port adapter settings — you can reference a constant with a double-curly-brace token. The exception is naming an object itself: the Name field on a constant, variable, port, message type, schema, etc. is a literal, never an expression.

The token grammar is identical to {{Variable.Name}}, {{Promoted.MessageType.Name}}, and {{Message.MessageType}} — the same expression engine evaluates all four. A subscription expression that filters a send port to messages whose currency matches a deployment-specific region code, for example:

{{Message.MessageType}} == "Invoice" && {{Promoted.Invoice.Currency}} == "USD" && {{Constant.RegionCode}} == "EU"

The high-value case is wiring an adapter to constants so the wiring is the same in every deployment and only the values differ. An SFTP send adapter wired this way:

Host:      {{Constant.SftpHost}}
Port:      {{Constant.SftpPort}}
Username:  {{Constant.SftpUser}}
Root path: {{Constant.SftpRootPath}}/{{Variable.CurrentBatchId}}/

moves to the next deployment unchanged. The four {{Constant.…}} tokens resolve against the destination's Constants list; {{Variable.CurrentBatchId}} resolves against runtime state as it always did.

Constants travel through snapshots in two layers. The definitions — names, descriptions, and every reference to {{Constant.Name}} in ports, pipelines, maps, and expressions — are part of the snapshot's open structure. The values are encrypted with a snapshot password.

When the snapshot is imported into a destination deployment, the importer chooses one of two paths:

Three patterns account for most of how constants are used in practice. The platform does not enforce any of them — a constant is just a value — but the patterns are worth recognizing because they cover almost every reason to reach for a constant in the first place.

Pattern 1 — Endpoint. Hosts, ports, base URLs, connection strings — values that differ between deployments and never inside one. Wire the adapter setting to {{Constant.Name}} and the wiring is final. Moving the Application across deployments is a snapshot import; the new deployment supplies its own endpoints.

Pattern 2 — Path or identifier. Inbound root folders, outbound drop folders, table name prefixes, tenant IDs, region codes. Strings that show up in more than one place and would otherwise be hard-coded across ports and maps. Centralizing them as a constant means a single row to edit when the value changes, and the change is reflected everywhere the next time the affected stages execute.

Pattern 3 — Feature flag. A boolean-shaped value (held as the string "true" or "false") that gates a subscription expression or a pipeline branch. Toggling the flag is a one-row edit in the Constants list, with no port reconfiguration and no snapshot motion.

{{Message.MessageType}} == "Invoice" && {{Constant.AutoForwardOn}} == "true"

Constants are read-only at runtime. The expression engine resolves each {{Constant.Name}} token at the moment the stage that contains it executes, by looking up the value in the application's Constants list as it currently stands. There is no port assignment stage, no pipeline write, no map write.

An empty constant (definition exists, value is blank) resolves to an empty string. Adapter settings that depend on a non-empty value — a host, a port number — will fail at the adapter's validation stage, not at the expression engine. The expression engine itself is permissive: an empty string is a valid resolution.

Constants, Variables, and Promotions are referenced by the same expression engine and share the same token grammar. They describe three different kinds of value, and a single expression can mix all three freely.

The three are intentionally separate. A value that describes this message belongs on a promotion. A value that the integration mutates as it goes belongs in a variable. A value that differs only between deployments and never within one belongs in a constant. Mixing them in a single expression is fine and common:

{{Message.MessageType}} == "Invoice"
  && {{Promoted.Invoice.Currency}} == "USD"
  && {{Variable.InvoiceForwardingEnabled}} == "true"
  && {{Constant.RegionCode}} == "EU"