Inputs, outputs, and bindings
Each node parameter receives a value under a typed contract. Ormuz distinguishes a configured value, a direct context binding, and a transformation expression; the editor checks compatibility before the process can be used.
Three parameterization modes
All three modes converge on the same parameter contract: the type expected by the node remains the final authority.
| Mode | When to use | Behavior |
|---|---|---|
value | Value configured in the definition | Suitable for constants and structured content known at design time. Strings and structures may also contain `{{ ... }}` interpolations resolved at runtime when the parameter allows them. |
binding | Directly reuse a context value | Reads an `input`, `node`, `var`, or `env` source without transformation. This is the preferred mode for passing platform objects and already-typed values. |
expression | Calculate or transform a value | Evaluates a JSONata expression over available context. Reserve it for calculations, coalescing, aggregation, and transformations that a direct binding cannot express. |
A message such as Send to {{ env.support_email }} remains a value keeps its structure defined in the process and renders placeholders at runtime. Switch to expression
when the value genuinely needs to be calculated or transformed.
Type system
Each parameter declares the type or types it accepts. The editor compares the source type with the expected type and rejects incompatible wiring. This check notably covers object subtypes: a platform.company is not interchangeable with a platform.invoice.
Types primitifs
| Type | Description |
|---|---|
string | Text, optionally enriched with a semantic subtype or enum. |
integer | Integer, optionally bounded. |
number | Decimal number, optionally bounded. |
boolean | Boolean true/false. |
object | Structured object: platform object, draft, common object, or extension object. |
array<T> | Collection whose element type is declared and checked. |
Examples of semantic subtypes
Subtypes add semantics and validation rules to a base type. The list below is deliberately representative, not exhaustive; the schema and type reference is the entry point for detailed public contracts.
| Subtype | Meaning |
|---|---|
common.email | Email address. |
common.phone | Phone number. |
common.url | HTTP or HTTPS URL. |
common.datetime | ISO 8601 date and time. |
common.date | Date ISO 8601. |
common.duration | ISO 8601 duration, for example `P7D` or `PT2H`. |
common.country_code | Code pays ISO 3166-1 alpha-2. |
common.currency_code | ISO 4217 currency code. |
common.address | Structured postal address. |
Platform objects
Platform objects use a subtype such as platform.company, platform.invoice
or platform.order. When a parameter expects a persisted platform object, it normally receives that object through a binding or expression; it is not free-form JSON to re-enter in the process.
Drafts use the same business object with type mode draft. They remain distinct from a persisted resource carrying an id.
Binding sources
A binding reads directly from one of the four execution-context scopes. It adds no calculation: the read value must already be compatible with the target parameter.
| Scope | Source | Description | Example |
|---|---|---|---|
input | Process input | Value supplied when the instance starts. | input.invoice |
node | Node output | Value produced by an upstream node guaranteed on the current path. | nodes.resolve_contact.selected_contact |
var | Process variable | Mutable value carried by the instance to share or accumulate explicit state. | vars.company_draft |
env | Variable d’environnement | Value configured for the merchant environment and captured in execution context. | env.approval_limit |
Object relationships
When a source is a typed platform object, a binding may traverse a declared relationship without turning the identifier into implicit access. For example, from an invoice the editor can offer the relationship to its buyer company. Ormuz then explicitly resolves the target of that relationship within the process's authorized scope.
Resource references
Some parameters expect only the typed identity of a resource, conceptually written
ref(T), rather than the complete object platform.T.
A complete object can feed a reference of the same type: Ormuz then projects its id
without an additional read. The reverse is never automatic: knowing an identifier does not grant access to resource content. Use an explicit read node when the process needs the object.
| Source | Destination | Compatibility |
|---|---|---|
platform.T | ref(T) | Yes, project the ID. |
ref(T) | platform.T | No, an explicit read is required. |
Extension-configuration references are also qualified by extension: knowing a configuration identity reveals neither its content nor its secrets.
Guaranteed ancestors
A node output can be used only when the source node is a guaranteed ancestor of the current node on the relevant routing paths. A conditional branch that may be skipped therefore does not provide a safe output after convergence merely because it appears visually upstream.
This check prevents a valid process from depending at runtime on an output that does not exist on the path actually taken.
- Move the calculation before the branch when this value can be produced before the decision.
- Design convergence explicitly when each branch must provide a compatible value.
- Use a process variable only when the process model genuinely guarantees it will be initialized before reading.
Process variables
Process variables carry an explicit value throughout an instance's lifetime. They are useful when state must be shared across several steps without depending directly on one node's output.
Some primitives can create a variable; others can update an existing one. A common pattern is to evolve a typed draft through several interactions, then explicitly materialize it once the business contract is complete.
Variables d’environnement
Merchant- or environment-specific values are available under the envscope. They can be used directly by a binding, referenced in a template value or consumed by an expression as needed.
A reference such as env.approval_limit must identify its key statically so Ormuz can record the process dependency and validate its type before deployment. Configuration details are described in Accounts, merchants, and environments.
Data classification
Wiring preserves the data-protection class on which it depends. A sensitive or
secret value remains protected when passed directly, placed in a variable, or used in an expression.
When a transformation depends on several sources, the result inherits the classification needed to protect those dependencies. An explicit classification reduction may require consent when saving the process.
See Data protection in processes for the complete propagation, downgrade, and targeted-reveal model.