Refreshing a Grid from two different scenarios

In such multi-update scenarios, I just create a local counter variable which I increment when I want the data to refresh. Then make my local refresh depending on that counter.

How would I make the record action increment the record counter?   The other scenario I can do (the edit that does a call to an integration I can do easily enough) the record action doesn't have a way for me to increment that variable?

In rarer cases like this, I've found it useful to use a local timetamp.

local!lastUpdateTime: a!refreshVariable(value: now(), refreshAfter: "RECORD_ACTION"),

this value will be updated to a new timestamp any time a record action is observed.  This variable cand then be added to the refresh variable "on var change" watchers for any relevant local variable(s) that need to be updated after the record action.

There is already a refresh for record actions. So there is no need to try to use that counter approach for record actions.

TY - so my test is would then be?   Currently looking for 

 local!isCommentUpdated: a!refreshVariable(
    value: local!editCompleted,
    refreshOnReferencedVarChange: local!editCompleted
  ),
  local!isCommentAdded: a!refreshVariable(
    value: now(),
    refreshAfter: "RECORD_ACTION"
  ),
  local!isRefreshNeeded: if(
    or(
      local!isCommentUpdated,
      local!isCommentAdded
    ),
    true,
    false
  ),

There is a refresh for record actions, but I need to test two scenarios :  when a record action happens OR when a seemingly non related integration call is made from the interface

More like so

a!localVariables(
  local!refreshCounter: 1,
  local!data: a!refreshVariable(
    value: /* YOUR QUERY */
    refreshAfter: "RECORD_ACTION",
    refreshOnVarChange: local!refreshCounter
  )
)

You can then increment that counter using a!save() inside any saveInto.

Stefan Helzle said:

You can then increment that counter using a!save() inside any saveInto.

This is a favorite technique of mine too.

nancyb0004 said:

There is a refresh for record actions, but I need to test two scenarios :  when a record action happens OR when a seemingly non related integration call is made from the interface

Time for a quick sanity check here - why are you bending over backwards to combine the refresh conditions into other local variables instead of just adding multiple refresh conditions to the original query's local variable?  Stefan's most recent example shows how you can easily make a single variable observe both a refresh counter as well as the "RECORD_ACTION", and you can add other condition(s) as needed there too.

nancyb0004 said:

There is a refresh for record actions, but I need to test two scenarios :  when a record action happens OR when a seemingly non related integration call is made from the interface

Time for a quick sanity check here - why are you bending over backwards to combine the refresh conditions into other local variables instead of just adding multiple refresh conditions to the original query's local variable?  Stefan's most recent example shows how you can easily make a single variable observe both a refresh counter as well as the "RECORD_ACTION", and you can add other condition(s) as needed there too.