In Appian process modeling, why is it considered an architectural anti-pattern to configure complex business logic transformations across both the Node Inputs and Node Outputs of the same node, and how do their execution times differ? Is there a specific exception where a Node Input configuration dynamically alters a property that can only be captured in the Node Outputs of that same node?
Answer
Node Inputs and Node Outputs execute at completely different times during a node's lifecycle. Node Inputs evaluate first during the node's initialization phase to instantiate local Activity Class parameters (ac!). The Node Outputs execute last, during the commit phase after the node's core logic finishes, mapping data back to Process Variables (pv!). Forcing both tabs to handle sequential data dependencies on a single node fails because the modified state isn't available globally until the node completely terminates. Yes, the primary exception is the Write Records Smart Service when creating a brand-new record where the primary key is auto-incremented by the database.
- At Node Input: The record data is passed into the node input with a null or empty Primary Key identifier.
- At Execution: The database writes the row and generates a unique primary key.
- At Node Output: The Write Records smart service dynamically captures that newly generated primary key from the database transaction. Developers must use the Node Outputs tab (ac!StoredValues) during this exact commit phase to map the complete record back to its target pv! to capture that new key for downstream processing.