We LOVE using connector functions calling the Tulip API to create records. It really streamlines the triggers (suddenly a record create and 20 data manipulations are 1 action). See example below:
On the road of making as much stuff streamlined we are converting basically all of our record creation into this format. Unfortunatly we can’t currently use this approach to record loading and setting to app variables. When I create a GET request it returns an array of response outputs from the API. It would be incredible if instead, like post inputs, it would allow me to set each individual output to variables in the run connector action. Right now the flow is:
Run connector>set outputs to array>Set each index of array to the correct variable (1 action per variable)
This really doesnt save us any time or placeholder variables. If we could go:
Run connector>set what variables each output should be set to (all in the connector)
Basically, I’m just looking for the opposite of the POST call, with the outputs as something that can be set all within the connector function, like the inputs of a post.
Great suggestion @Peter.Hartnett, I just learned how to use the HTTP connectors, and hopefully, when I start getting more familiar using them I can change the creation of records to one POST action like you did.
I agree that it will be great to have the same functionality on the GET requests also.
We are re-reviewing this request and have a followup question for you:
In most cases, when loading records, it’s simplest to just “load record” and then instead of saving those values to App variables, access that information directly from the record placeholder. Would that kind of approach work for you? Or is there a reason that this information can’t be accessed with the load record trigger, or is there a reason that you need the data in a variable rather than a record placeholder?
Youre right, in the case of data we are just reading from tables, there is no issue with this approach. The issue comes when trying to add or adjust a value in a table. In that case we often need inputs, which can only be tied to app variables. So yes, we could just use the table record for order quantity in most cases, but when we want to add an override we need an app variable. A vast majority of the values stored to that table we want the operator to be able to manually adjust. In the other 30% of cases, we wouldn’t need duplicate values. Because of this we have mirrored app and table variables.
So technically, yes, in some usecases this would do what we need, but our current app architecture expects a matching app and table variable for any data we will ever want between completions, and just app variables for values we dont care to log.
I have another open issue addressing how inputs cant be tied to table fields, this would enable us to completely avoid app variables.
Having said that, I do think the original idea is a valuable one. We use connectors to simplify trigger logic, if we could load and assign a ton of values to variables in one step, that would be significantly more convenient than forcing the connector to return an array that we then have to parse.
Consider the example I gave. If every time you wanted to call a post connector, you had to first combine all the data into a placeholder array before passing it into the connector. its just a big pain.
It’s helpful to know that the ability to tie input widgets to a record placeholder is related to this request.
Going back to the ability for connectors to return multiple outputs, would you expect all Connector Functions to change their trigger menus to include every output? So if there are 2 Function outputs, then they would be broken into two different drop downs in the trigger editor as opposed to being two properties of a single object?
Where “outputX” would be replaced by the name of the output in the Connector Function:
I’m not sure this is something that we are able to do or that fits in with the future of the product, I’m just trying to understand if this is what you are trying to do.
Hi, from my point of view, the problem is more that some widgets don’t support object arrays but only simple array. Workaround is now to use MAP_TO function.
Hadn’t thought about the implications where the return is a list of results, I had only considered the implications of requests that return a consistent amount of results.
Like I said, I think the root cause of this issue is the lack of support to use exclusivly table variables. that would be our preference in most cases, but it really isnt possible with the limitations of the input widgets.
@youri.regnaud can you give an example of how the mapto function could be used to map a set of variables. say I want to map [x,y,z] to variables x,y and z. How would that work with mapto?
