This topic was automatically generated from Slack. You can find the original thread here.
It could be useful to have $.context.is_builder = true|false, so that we can use that as a conditional in workflows.
It could be a basic programmatic way to differentiate between dev/builder & prod/deployed environments.
Or it could be called is_development_mode, to go along the UI:
Hi , for this case, you can determine if the execution is in builder mode or production mode by the variable: steps.trigger.context.test .
• steps.trigger.context.test=TRUE means the execution is executed in Builder mode (1st image below)
• steps.trigger.context.test=FALSE means the execution is executed in Deployed mode (2nd image below)
~Note that when you’re on Builder UI, selecting an event received when the workflow in Deployed will still give you steps.trigger.context.test=FALSE~
Awesome, thank you!! 
Ah… 
Note that when you’re on Builder UI, selecting an event received when the workflow in Deployed will still give you
steps.trigger.context.test=FALSE
That’s the issue.
We need the context of the execution, not the context of the event.
Oh actually it the steps.trigger.context.test will give you the data of current execution context. So steps.trigger.context.test will always TRUE in builder mode. My bad .
Oh, so this might work then! 
FYI 
Not sure if you were already aware.
Interesting.
Next time I’m doing some Pipedream automation dev I’ll play around with this.
Currently deep in some CI/CD stuff. But I need to put together a presentation for our usage of Pipedream for the engineering leads so there’s more than myself and a couple other people using it.
Gotta empower our engineers and all that by making them aware of tools we’re using and how to dive in and all that fun jazz.
