Why are environments and global variables readonly?

[saswatds]

I want to begin by saying that nothing is wrong with environments or variables. They just work differently in Flows from how they used to work in the Collection Runner or the Request Tab.

Here are the three differences that you might notice when working with flows.

1. Environment variables can only be used within a request. Variables are not first-class citizens in Flows.

   When request templating with {{variable}} was introduced, environments were provided as a means to store sensitive information like API Keys, session tokens, etc. The word environment variable was also chosen because it correlated with operating system environment variables. An environment variable is a simple key-value pair where both keys and values are strings to store information that dictate how the API should behave in different environments like beta, stage, production, etc.

   When the collection runner was introduced, by accident, we realised that using a pre-request script, test script and the postman.setNextRequest API, and we could build a simple Turing machine language with collections. The only problem was that this language did not have an runtime-environment with a scope spanned across multiple requests. Using environment variables seemed like an easy escape hatch to this issue, and the sandbox added support for APIs to update the environment variable.

   Inevitably the problem arose that sensitive data or values that were never supposed to be updated could now get over-written during execution. Therefore we had to introduce the concept of current and initial values in environments. You can realise that this early decision of using environment variables for something that was never intended to be used has been the epicentre of all confusion and problems.

   When we started designing flow language, we added an environment within the language itself. This means that users no longer had to piggyback on the environment variables to send data from one request to another request. They could do it just by connecting two blocks with a connection.

   It was a difficult decision to break the existing pattern, but we firmly believe this is a necessary change as it would simplify problems for both us and users.

2. The environment selection for the workspace has no effect on the entire flows.

   Another design decision that we made with flows was allowing execution requests that belonged to a different collection. We wanted flows to grow to become the de-facto for expressing workflows and collections to be an executable specification of an API.

   The traditional way of representing workflows in a collection meant that collections were no longer a homogenous set of APIs but a mismatch of different APIs, which only make sense in the context of that collection. This way of organisation resulted in the emergence of two kinds of collections, one that was reference-grade material but could not be executed, and the other that was executable but hard to comprehend as a specification.

   Because flows allow running requests across various collections, having a single selection of environments for the entire flow would mean that flows would not allow interfacing APIs hosted in different environments. Therefore, we decided that the environment selection for the entire flow will not be respected, but we will want users to select an environment for each Request block explicitly.

3. Environment works in a read-only mode, updates to the environment from scripts are not respected.

   Expanding on the points raised above in section 1, we want to discourage the usage of environment variables as a storage mechanism. For this reason, environment variables and globals are now treated as read-only values, and any updates made to them through script are not respected. Another reason for enforcing this is to use this opportunity to identify the loose end of the flow language and its ability to provide a robust environment implementation that we have not been able to do with postman for a long time.

How should you work with these new differences?

1. I want to use information from the response of one request in another request.
   

2. I want to use information from the response of one request in multiple requests.
   

3. I want to use information from the response of one request in multiple requests but control the order in which requests are executed.
   

[BrianJonesNMI]

So if I am understanding this correctly in order to use environment variables in flows I have to set the environment on each block.

So if I have a complex flow and want to change environments I have to manually change each block independently?

Variable script blocks do not have an environment drop-down either so I have to use a mixed mode of flow variables and request variables if I want to use any environment variables?

Do you have any plans for being able to change the environment for every block in the flow? This feels like a step back in the idea of being able to create 1 flow and use it in multiple environments which we have in collections.

Please advise if I am not understanding this.

[saswatds]

We want to continue maintaining a mental model of the collection-environment pair and keep it isolated inside the Send Request block.
A few helpers could be added to help with changing environments for requests belonging to the same collection.

We are trying to remove the need for Environment Variables in Flows by introducing the Abstact Data Editor which expresses all kinds of complex data-structures than just the key-value pair that environments support. (Flow variables were an interim solution and will be superseded by ADE).

We would want that, as we advance, everyone defines all of your different data inside the flows and not outside using environments etc. We will also add a block that will let to choose between various data sources, even programmatically.

[jpgr79]

I am sorry to agree with BrianJonesNMI. Flows should use the selected environment, or else, each time I would like to test flows with differente service url, user, password, etc, I will have to change the boxes.

[Centerful]

I suggest referring to vuex, behavior and state need to be separated

[bbbford]

I agree. The change number 2 above is a huge step backward. "The environment selection for the workspace has no effect on the entire flows."

We now have to change each block in the entire flow. It used to be intuitive and easy. Now it is cumbersome and error-prone. I now have to change the environment in every block. If I accidentally miss a block, I will get incorrect data.

[saswatds]

What we are thinking is to make the association of collections and their environments something that flows understands and makes the process faster. We have an improvement coming in the next few weeks that will make the bulk changing a one-click process.

[bbbford]

@saswatds Why not allow the user to select "Use global environment" on each block? That way it is completely flexible. We can use it the way it used to be, or we could customize each block.

[saswatds]

There is indeed value in making the globals available as a scope within the flow program, which I think we can implement rather quickly. But I would still think of them as read-only data. The global scope will also be the place where OS-level process environment variables would be made available, similar to Node~process.env. Which are again fundamentally non-editable.

Another reason, why I am avoiding making the environment editable, is because the flows concurrency model relies on immutable to guarantee memory safety. We all know how difficult it is to write programs with threads and shared memory. The previous way of using Environment as storage, essentially makes it shared memory and each block a thread racing to update it. Mutable data brings with it all kinds of locks and synchronization problems that in the long run will make flows very complicated to use for non-programmer.

[mikymigs]

Yes please, add the option to select the "global scope" even as read-only (I personally never change environment variables dynamically anyway).
Right now this constraint is forcing us to duplicate the same flow for each environment and it's a pain in the butt to maintain...

[ilbambino]

We have quite a few environments, and having to either change the env in all the boxes or maintain different flows a pain. So big that currently we are looking for other alternatives. I understand the use case that a complex flow could span different envs. But having either a check to use a global environment or a box that will let you choose it would do the trick

[musaburak]

1. There is a request in my collection so, in the test script, I parse the Html body and find some values in it then set a global variable to carry value to the next request.
   Response body:

<a href="https://example.com/login?login_challenge=c064b19857724ef894575508dfd8fce9">Found</a>.

Test script:

const $ = cheerio.load(pm.response.text());
var link = $('a').attr('href')

var sdk = require('postman-collection');
var url = new sdk.Url(link);

var login_challenge = url.query.get('login_challenge')

console.log(login_challenge);
pm.globals.set("login_challenge", login_challenge);

pm.expect(login_challenge).not.empty;

Is there any method so I can parse manipulate as I want all Html responses in Flows.

2. In addition, the whole purpose of this flow is to get a token and set it in globals to use another API request. Will be any terminal block so that we can store results and use them in other collections or requests.

[saswatds]

@musaburak This is a great example.
Data manipulation is something flows intends to add as part of its core.

1. The way I am imagining is that we will add an HTML Parser block which will enable you to pick any information from the UI. All you will need to do is click on the UI or write a simple query. This data will then be made available in the output port of the parser block, which you can then connect to any other block and use in those blocks.
2. If this data is something like an access token then you can use the Create Durable block to persist over multiple blocks.

We encourage using the connection to pipe data from one block to another, rather than using Globals/Environments, etc.

[ArtsiomHilevich]

@saswatds is it possible to write some warning to console when trying to update a read-only Environment/Global variable in Flows? As for me, it would help users to understand why post-request test is passing, but the variables does not get updated.

[saswatds]

I will get that done right away. Thanks for the suggestion

[prabodhprakash]

is this done?

[jasondamour]

What about hiding the warnings when reusing collections which are supposed to update vars outside of flows...

[kellewic]

Definitely needs some explanation on updating variables since I just spent 20 minutes trying to figure this out.

What's the suggested process when you need to ensure you have a valid authentication token? Put the same blocks in every flow? Run requests manually to get the token into the environment and then use that in flows?

Was hoping to create a flow like:

• enable token authentication
• does user (in environment variable) have a token?
  • YES
    • if token is expired - delete it, create a new one, and set token environment variable
    • if token is not expired - get it and set token environment variable
  • NO - create token and set token environment variable

and then I have a token for all further requests, which they use as part of the headers they send (bearer token).

It would be nice to call a flow from another flow and use flow_1 output as initial input to flow_2 - that might work in this case to avoid writing to the environment or having to recreate token flow blocks in every flow.

For the above scenario, all I can see as a solution is run all the token requests manually to get the environment set up, then use flows since they can read the environment. I'm definitely not duplicating the same token logic across flows and I don't see that you can chain flows.

Collection runners don't seem to handle conditionals - maybe in the pre-request and testing scripts? But would the scripting for a collection run interfere with using a request individually?

Am I missing something in how to approach this? If you want to discourage use of environment and global variables then it needs to be simple to get something like a token and re-use it across flows. I don't see that as possible right now without using environment / global variables or re-creating the same blocks in every flow.

[prabodhprakash]

yeah - agreed - flows is nearly unusable right now with the amount of work that is needed to be done to get it working - there could be a lot of thought process behind what works/does not work for Postman - but, end of the day - at least for me, as a consumer of the product, it does not work.

[samay-v]

Hi @prabodhprakash @kellewic
I appreciate you trying out Flows, and regret that its not everything you thought it could be. My team and I believe we're still in the nascent stages of this tool and are iterating on our approach frequently.

What we would love is to have conversation with people like you whose use-cases we're not able to get to yet. So if you're wishing to give feedback on a call with the team, Fill out this form (It just asks your email address so that neither of us have to share it on the open internet) and we'll schedule something ASAP.

https://forms.gle/zdDJ3tdh52kgd3kSA

[leonpros]

"Flows" has lots of defects.
It begins with obsolete documentation and examples that do not match updated UI.
Using requests from collection api, that have variable assigns, will always show a warning (for each request) in logs that it is not supported.
Some responses require parsing and only then assigned to variables using JS, not supported by Flows.
Using requests from collections that already have some logic in pre/post request actions, will have to be re-created in a different way when using flows (double work).
UI is not fully intuitive.

As i see it at the moment, the idea of "Flows" is awesome, the implementation is unusable

[dk-carma]

broken all Flows...all the efforts of 6 months are wasted!!!!! 😡

[bbbford]

Yep. All flows completely broken. What a poorly managed product. We have completely abandoned Postman after this fiasco.