Unexpected [_THISROW] value

[dbaum]

I was vexed by an automation where I couldn't figure out why adding a row was being processed by an unintended branch of the automation instead of the branch intended for new rows. To troubleshoot, I inserted a step in the automation to email a list of all the column values referenced in the preceding 'branch on a condition' step. All values appeared as expected except a standalone [_THISROW], which returned a value that I don't know where it even came from.

From @Steve's explanation in  Solved: Re: About [_thisrow] - Google Cloud Community  I interpreted that using [_THISROW] in an expression is equivalent to using an explicit reference to the row's key column. However, in my branching condition expression, [_THISROW] was getting processed as a value that doesn't even exist in my table; it looks like a UUID, which I don't use anywhere. My key column is simply the typical UNIQUEID().

Can someone help me better understand [_THISROW] -- e.g., maybe there are particulars to using it in an automation, especially when adding a new row?

Excerpt from branching condition expression

ISBLANK(SELECT(Users[User ID], AND([Email] = [_THISROW].[Email], [Active])) - LIST([_THISROW]))

Excerpt from email documenting branching condition values, including explicit key column, [User ID]

ISBLANK(SELECT(Users[User ID], [Email] = [_THISROW].[Email]) - LIST([_THISROW]))
): N

COUNT(SELECT(Users[User ID], [Email] = [_THISROW].[Email])): 1

[_THISROW]: 4e1d0c1c-ba5b-4f79-8598-7bdc30abf0c9

[User ID]: f68d1690

[_THISROW].[User ID]: f68d1690

[MultiTech · Accepted solution]

Yeah there's definitely a peculiarity that you're running into here.

Are you aware that you can de-reference values from previous automation steps?

Because we have this functionality, when you use the formula bit for [_thisrow] inside of an automation, what you're actually calling is the task itself.

________________________________

The solution is an adjustment to your standard method of getting the key value for the record you're dealing with.

Instead of using [_thisrow], just use the key column itself [UserID].

Whenever you need to use the key value for a record, simply insert the column that you've marked as the key.

[_thisrow] should really only be reserved for instances where you're executing a formula that has two tables in context; [_thisrow] is the formula bit that you used to tell the system to pull values from the row your currently processing, not to pull values from the table in which you're trying to select values from.

Hope that made sense! 🙂

[dbaum]

---

@MultiTech wrote:

Because we have this functionality, when you use the formula bit for [_thisrow] inside of an automation, what you're actually calling is the task itself.

---

Got it. Thanks a lot for the explanation. That's helpful to keep in mind.

---

@MultiTech wrote:

Instead of using [_thisrow], just use the key column itself [UserID].

---

Right. That's my next step, and is how I normally would have written the expression to begin with. I only stumbled into this scenario as a result of copying an expression from elsewhere where [_THISROW] made sense and functioned as I expected.

---

@MultiTech wrote:

Are you aware that you can de-reference values from previous automation steps?

---

I've seen references to those schemas in places like the app definition, and wondered how they might be used. Do you know of a practical example available somewhere to look at?

[MultiTech]

Found this in the documentation:

But it doesn't mention anything about [_thisrow] and how it would interfere with the "regular" functioning of that formula-bit.

How's this for some comedy:

• The sample app that's supposed to show how automation works.... doesn't have a single bot inside it (only tasks)

🤣