Returning values from a process in automation -did anyone get it to work?

I am trying to get my head around the new automation function. Most of it seems fine but I can’t figure out how to access values return by a process.

I have tried both

[name of process that generated the value].[name of variable]
[name of process that called the process].[name of variable]

When putting a formula is, the system also suggest a syntax which treats the name of the process as a table so

name of process[name of variable]

Does anyone know the right syntax and also what the scope of the variables is?

Hi @Erik_Ferm. The syntax is [Name of call process step].[Name of variable].

So if you have a step called “Get manager approval” that calls another process:

You can reference the results by writing [Get manager approval].[Results].

1 Like


Thanks for your quick reply. Sorry if I am missing something obvious but this is what I am testing:

  1. I have a process with a step called “calingStep”
  2. The step callingStep calls another process called “returningProcess”
  3. the process returningProcess has a step called “returningStep” which sets a variable called “tesVariable” to the value “variable text”
  4. The process step after callingStep is called “recallData” and it calls another process (that doesn’t do anything.)
    Adopter app deve (3)
  5. Before calling the dummy process, recallData sets the value of a column called scratch1 to a string which contains the variable from callingStep. This is done specifying the string as a process input.
  6. The syntax is accepted and the editor is happy with the reference to the variable.
  7. The column’s value is updated as expected but the variable from callingStep seems to be empty so it only enters the first part of the string.
    adopterData - Go

Sorry if I am slow but what am I missing here?

Can you show the details of what you’re doing in step 5?

Right now you can only use return values in if/else steps, call process steps, and return steps. It’s not currently possible to use the output of a process “inside” of an action (though it is on our todo list). @Dan_Bahir fyi.

Step 5 is calling a process and it is (trying to) use the variable as part of the process input, i.e. the columns that are updated before running the process.

So it is still in the process, not inside an action.

Adopter app deve (4)

So the columns scratch1 for the row specified by id is set to

"This is the returned data: "&[callingStep].[testVariable]

Before running the process. As mentioned, the correct cell is updated but only with the text "This is the returned data: ".

Ah, that makes sense. Thanks @Erik_Ferm . You should be able to pass in that data, so it’s possible that this is a bug. I will share with the team to investigate.

Hi @Erik_Ferm,

I tried reproducing this scenario but I am not able to, I am getting the desired behavior.

Would you mind sending a request to asking to route the request to me. That would allow to to further investigate the app that you built and provide a solution for you.

No problem, I just sent the email.

What about



callingStep OUTPUT[testVariable]

They seem to be valid in the editor but I haven’t tested them out yet.

NOTE: Those both return lists so If a single value is being returned then wrap the above statements in an ANY() expression.

referring to your screenshot in step two, I notice your Step callingStep is calling returningProcess as a lookup but has no process inputs. I understand this (perhaps incorrectly) as a parameter needed for a lookup.

FYI, I also noticed that passing a primary key input to a lookup process, if that record cant be found, instead creates a new record using the ‘looked for’ ID. Seems pretty much the same as the Add option for calling processes, so I’m not sure I understand this stuff.

When attempting to use a return value, I cannot seem to get the editor to accept the syntax of

[Name of call process step].[Name of variable]

I can get the editor to accept (but it doesnt seem to work)

Name of call process step OUTPUT[Name of variable]

Main Process with calling step (uses SELECT to get id of row to lookup):

Called Process

NOTE: I’m setting this up for testing purposes only, so the logic behind this might not make sense (because I can grab svc ID with a SELECT statement and have no need to use a lookup)

I’ve determined this is due to the step that needs to referenced being inside a branching condition step. Syntax of:

[Branching Step Name].[Calling Step Name].[Result Name]

Does not seem to work.

In short, I can successfully reference a step’s returned values as long as the step IS NOT a part of a Branching step.

Support ticket in progress.

Here, this is definitely not confusing:

Thanks for sharing your findings.

I tested this a bit yesterday and also today. This is what I found so far:

  1. In my original app, all variables were returned as empty, regardless of how I referenced them.
  2. I then created a new test app with only one table, one bot etc and I got it to work
  3. I them made a copy of the app where the variables came back empty and, in the new copy, the variables were returned correctly without any change to the app
  4. In the app that I copied and where the copy worked correctly, the calling step and the retrieving step were both inside a branch condition
  5. This morning, sync times are really long and the bot stops after the calling step in all apps. This is true even if I don’t assign any value to any variables and don’t try to reference them
  6. In the diagnostics view, the event (just an update to a row) has the status “error” and the calling step does not show as having been triggered even though it has put data into a table. This is only this morning. Yesterday it was working

As for referencing the variables, yesterday I got the syntax

calling step Output[variable]

to work as well as

[calling step].[variable]

The editor will also accept

returningstep Output[variable]

but that returns an empty value.

1 Like

I can still get what is supposed to work (aside from steps inside conditional steps) to work,

BUT I too am noticing that

AUTOMATION is UNUSABLY SLOW right now. Waiting over 5 minutes now for a saved record to trigger a single new record creation on a set of 3 records, a process that took just a few seconds yesterday.

This issue seems to be solved now :slightly_smiling_face:

Seems like an isolated issue, can you please let us know if you are still encountering the same issue?

Automation is no longer slow.


Return values from called processes still cannot be referenced if calling step is inside a conditional branching step.