### Problem/Motivation When building a workflow, users have no visibility into the outputs or data context produced by prior steps. This forces users to mentally track what data is available at any given point in the workflow, making it harder to configure actions and conditions correctly. Tools like Zapier address this by showing sample data from previous steps when configuring a subsequent step. This is related to [#3577204: Make workflow replay feature discoverable](https://git.drupalcode.org/project/modeler/-/work_items/3577204) (now fixed), which made the replay feature easier to find. ### Proposed resolution The **Test/replay feature** is the chosen mechanism for surfacing prior step context. After a test run, the replay panel exposes the exact data that is available at each step, giving an accurate, runtime-true view of the tokens that can be selected when configuring subsequent steps. This was preferred over two alternatives that were evaluated and rejected: - **Scanning the model backwards** to infer available data — rejected as unreliable, because action plugins do not declare input or output data, so any inferred context would be largely meaningless. - **Per-plugin sample data** — rejected as impractical: it would require manually editing close to a thousand plugins, and even then the sample data would frequently fail to cover all runtime scenarios. In addition to the replay panel, the **`[` trigger key** opens the token picker directly within a field. This token picker can dynamically trigger a replay or load historical data on demand, transparently, without the user even noticing that a replay/data load is happening behind the scenes. This makes the available tokens accessible at the point of configuration, not only after an explicit test run. Building on the existing replay mechanism, the outstanding enhancement is to **dynamically propagate token context to newly added successor nodes**: when replay data already exists for a node and the user adds a new successor to it, the successor has no token data of its own until the next replay run. Because the successor will almost always have at least the same tokens available as its predecessor, the modeler should expose the predecessor's tokens on the new node so users can keep building without re-running the replay each time. This is the most common day-to-day use case and is expected to deliver the greatest benefit. The following behaviors are deliberate and should be preserved: - Step data is scoped to the **currently selected element**; tokens are not shown for other selections because they are most likely unavailable there and selecting them would cause failures at execution time. - Fields that do not declare token support are correctly shown as non-droppable. Where a plugin's config field genuinely supports tokens but does not declare it, the fix belongs in that plugin's config form, not in the modeler. ### Remaining tasks - Implement dynamic propagation of a predecessor node's tokens onto a newly added successor node (before any replay run covers it). - Determine how propagated/predicted tokens are visually distinguished from tokens confirmed by an actual replay run (UX decision). - Decide behavior when a node has multiple predecessors (which token set to expose). ### User interface changes - Newly added successor nodes will expose the predecessor's available tokens in the step-data panel before a replay run covers them. (Presentation of these predicted tokens vs. replay-confirmed tokens to be designed.) - The `[` trigger key opens the token picker in a field and can transparently trigger a replay / historical data load on demand. ### API changes None anticipated at this time. ### Data model changes None anticipated at this time. --- <details> <summary><strong>Original summary as reported (preserved verbatim)</strong></summary> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>When building a workflow, users have no visibility into the outputs or data context produced by prior steps. This forces users to mentally track what data is available at any given point in the workflow, making it harder to configure actions and conditions correctly. Tools like Zapier address this by showing sample data from previous steps when configuring a subsequent step.</p> <p>This may be related to <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/modeler/-/work_items/3577204" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/modeler/-/work_items/3577204</a></span>.</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <h3 id="summary-ui-changes">User interface changes</h3> <h3 id="summary-api-changes">API changes</h3> <h3 id="summary-data-model-changes">Data model changes</h3> </details>