I am trying to use information in between two different runs of two different workflows however it looks like the storage set and get value nodes do not work across different workflows.
Currently I have a user endpoint that gives me 8 out of 10 values that I need into a data table.
I have another user endpoint that gives me the last two values, the problem is that I need a way to identify which row in the table to insert those last two values into.
One option is to use the newest row in the table, however if we have two people signing up at one time it might confuse the system. So instead to identify the row I take two pieces of information from the first workflow and store it in variables. Then in the second workflow, I pull those variables and use their values to look up the row in the table that I need to insert the last two values into.
When I try to pull the search variables out of a storage get node and use them to search for the row in, they come out as null.
Any work-arounds? How do I pass these kind of values in between workflows without storing it on a device key value pair
Before I offer a workaround, I would love to learn more about your use case.
Would you be able to tell me a bit more about what type of data you are storing in the data table? What 8 values are you getting in the first endpoint and what other 2 values are you getting from the other endpoint?
Having this information will definitely help me point you in the right direction.
We are using the table to store our customer information. The first page that they use to sign up for an account stores basic information about the customer, and with the other page we are recording device registration.
Everything is a string, and everything is required.
Would you be able to tell me a bit about why you’re using data tables over User Tags? Are you immediately creating a device for that user when they sign up?
A workaround could be that you have two endpoint triggers in a single workflow. This would allow you to access the workflow storage in different paths. But, this may not be the best solution for this. I’d love to talk more about your architecture and what you’re planning for your users!
It was just an easy way to visualize all that written data and export if needed. The user tags are a little bit annoying to get to because you have to click on an individual user to access them. This has that data all in one place and it can be easily sorted
If I did go that route and use a tag for a user. How would I know which user to choose in between workflows? So if a user goes through the first workflow and enters some id 1234 and another one enters 55555. Now they are both registering their device, how would I know on the second work flow which user to associate with each device?
Well, if we’re talking about the payload from the initial request POST /create-account request, then no, there won’t be a user object available. However, if you are creating the user as part of this process using a User: Create Node, then you can store the result of the creation (the new user object) on the payload by setting a Result Path.
But going back to your original question, I wonder if you need to leverage workflow storage at all. It sounds like you just need to store little bits of information per user, some of which may be temporary as part of the device registration process. Why not leverage user tags? Then you don’t need to fight the “multiple users in the process” problem because all the information is scoped to the user instead, and that’s not something that can be faked or crossed with another user. On top of that, they’re easy to set using the User: Create Node and they are also queryable via the User: Get Node.
