Pretty sure the answer is “no” as far as I can tell, in which case I suppose this would be more of a feature request. But it would be great if builders could bind an object set itself to a scenario such that scenario metadata follows the object set, and load/save operations are always applied to the scenario. Then widgets and functions could operate on them simply as object sets, entirely agnostic as to their scenario status, but with access to scenario metadata if needed via the object set’s API. Perhaps this could also enable builders to selectively apply (filtered) object (sub)sets of a scenario, instead of applying the entire scenario, similar to the selective publishing capabilities in Gotham.
Hey! Happy to provide some color here:
How scenarios work today:
A scenario is a fork of Ontology data created by Actions and Models, storing only deltas — modified properties, created/deleted objects and links. A few key constraints:
-
Immutable — you can’t modify a scenario, only duplicate and recreate.
-
All-or-nothing apply — either all changes commit or none. No selective apply.
-
No context travel — scenarios don’t propagate through object sets. Widgets and Functions must explicitly reference a scenario variable to read scenario state.
Result: every consumer independently knows it’s operating in a scenario. There’s no way for an object set itself to carry scenario metadata and make downstream consumers automatically scenario-aware.
What it sounds like you’re asking for:
-
Scenario context on object sets — the set carries scenario metadata, so downstream consumers read it automatically without explicit wiring.
-
Selective apply — commit a filtered subset of scenario changes instead of all-or-nothing (similar to Gotham’s selective publishing).
Current workarounds:
For (1): Wire a single scenario variable through your Workshop module so all scenario-aware widgets reference the same context — should work for isolated modules.
For (2): Decompose into multiple smaller scenarios scoped to different object subsets (harder to scale with complex workflows).
Next step:
This is a well-framed feature request — feel free to post it to the Developer Community with the feature-request tag. Include your use case and workarounds you’ve tried as the product team uses that context to prioritize!
Docs: