<div dir="ltr"><div><pre style="margin-top:1.5em;margin-bottom:1.5em;padding:0px;border:0px;font-size:12px;font-family:'andale mono','lucida console',monospace;vertical-align:baseline;white-space:pre-wrap;font-stretch:normal;line-height:18.0018005371094px;color:rgb(83,83,83)">> What you’re saying is that whatever is under “$.env” is just the exact same environment that we passed when we started the workflow? If yes then it definitely makes sense to me (it just allows to explicitly access environment, not through the implicit variable lookup). Please confirm.</pre></div><div>Yes. the $.env that I original proposed would be the same dict as the one supplied at start_workflow.  Although we have to agree whether the variables in the environment are allowed to change after the WF started.  Unless there's a valid use case, I would lean toward making env immutable.</div><div><br></div><div>> <span style="color:rgb(83,83,83);font-family:'andale mono','lucida console',monospace;font-size:12px;line-height:18.0018005371094px;white-space:pre-wrap">One thing that I strongly suggest is that we clearly define all reserved keys like “env”, “__actions” etc. I think it’d be better if they all started with the same prefix, for example, double underscore.</span></div><div><span style="color:rgb(83,83,83);font-family:'andale mono','lucida console',monospace;font-size:12px;line-height:18.0018005371094px;white-space:pre-wrap"><br></span></div><div>Agree. How about using double underscore for env as well (i.e. $.__env.var1, $.__env.var2)?<br></div><div><div><br></div></div></div>