I have a hypothesis, but let me know if this is true:

The difference between the scenarios is that the Mass Action’s action sequence doesn’t have or cannot check the context for the field to do the comparison while the field in the row and the button both do have a context.

How does context work with mass actions in terms of a comparison check or a field update?

Thanks!

Hey @nkovash and welcome !

Have you tried modifying the following to:
{{Balance__c}} != "0"

Cheers,

Hey @QuinnRyan! That was a very clever suggestion that I did not think of, I appreciate it. Sadly it didn’t work.

I think I am going to just leave out branching logic from my Mass Actions.

Thanks for the help!

No problem @nkovash!

So to answer your initial question:

How does context work with mass actions in terms of a comparison check or a field update?

Field updates will update all fields in context. Comparison checks would only function on the first row in context, so with that being said:

I have a hypothesis, but let me know if this is true:

The difference between the scenarios is that the Mass Action’s action sequence doesn’t have or cannot check the context for the field to make the comparison while the field in the row and the button both do have a context.

I think it’s both true and false since it checks the context but only for the first row. There is probably a way to do this, but it may be a little more advanced and may require some JS.

If it’s important to the project you’re working on, you could look into doing this check with a combination of adopting the rows in context into a UI model and this aggregation functions.

I hope that helps!

Cheers,

Context in Mass Actions. That is a really good question. Generally the action sequence will be run recursively on each of the rows that have been selected by the user. And the context available for use in your actions via merge syntax will be the active row.

That is interrupted if a new row is created in your action sequence. At that point Context is transffered to the new row - and it stays there even when the iteration goes to the new selected row. There has been a long standing argument internally about this scenario and we don’t have a good sense for how we will ultimately correct it.

For the time being - if you are going to do much sophisticated action processing on some or all rows in your model - we recommend using a code snippet. In Javascript you can be much more explicit about what you what data is being interacted with (on a row by row basis) and what actions you are enabling.

Another few thoughts.

A good debugging technique here would be to put a message / block ui action right before your branch - and have it display the value of {{balance__c}}. This will show you what value is being held in context when the branch runs (if any…)

Are you familiar with the action debugging api? IN the browser console type skuid.debug.actions.loggingOn() Then in the console you will see a more detailed inventory of all actions as they occur. (Including the row context).