Copying Actions and Conditions

The update that allowed the copying and pasting of triggers was very helpful. Unfortunately since the platform doesn’t support for loops (without a cumbersome work-around) this means that a lot of actions have to be hardcoded over and over again.

Yes you could in theory create more triggers. The problem with that solution is the way triggers are processed is not sequentially. Since this is the current state of the editor what would be most helpful would be one of the following options:

  1. Allow For loops
  2. Create a copy and paste feature for actions and conditions in triggers.
1 Like

Hey Joey, thanks for sharing this. I think we will solve this in the future via for loops. There are three cases that I can think of:

  1. Arrays with a single data type ie integers
  2. Arrays of Table Records (coming soon)
  3. Arrays as output of connector functions

Are you using any of those 3 scenarios?

Thanks for the response.

Yes all 3 of those situations. A big part as well is the return values.

We essentially have to limit the number of items and create a variable for each return.

For instance. We have a report that we print out for a packing slip. Every item on that packing slip has to have it’s own variable with the current situation.

The code looks like this:

  1. Load table record [0]
  2. Store table record in var1
  3. Load table record [1]
  4. Store table record in var2
    etc…

You obviously can see the issue with this. Not only the time it takes to code and the lack of reusability. We also have a lot of processes with variable numbers of things that need to happen and currently we have to hardcode for every possible scenario to an extent (with some exceptions of course).

The same thing could be done in a For loop with relative ease.

for(i=0;i<rowsintable;i++){
arr[i] = row[i].columnselected
}

Heaven forbid you have to do a nested for loop.

Agreed. Yeah we still need to formalize the type of variable that would store the output from this action.

Obviously, when it is a single data type, output can be stored in an array of a single type. But, when it is table records or objects, we need to think of one way to store those. We could call it “array of objects” but that is very technical, does not fit the no-code approach.

I see your point. What about “Data List”, or “Output List”, or “Data Array”, or “Output Array”? Sorry if it’s not that helpful.

Definitely. I have considered “Record List” as well and just rename object to “Record” throughout the platform.

Anyways, will update here when we start work on this feature.

1 Like