(waiting for AlanM to show up)…
When there are several different Actions to take on a client, you are not guaranteed that they will execute in order. For that reason you can get unintended results when you set the effective date to {now}. In general what you’d probably want is to use on {parameter "action issue date" of action}. This evaluates to the date/time the action was issued by the console operator.
Example:
On 12/10, you take “action 1” targetting a group of computers with
setting "myvalue"="1" on "{now}" for client
On 12/11, you decide that’s a bad value, so we take “action 2”
setting "myvalue"="2" on "{now}" for client
On 12/12, you install a new computer in the group and it tries to catch up with the open actions. But they don’t execute in order - action 2 runs first, then action 1 runs after. You end up with the incorrect value of “1”.
There are several ways to handle it - you could ensure your older actions are stopped, for example. But the easiest way, and the method used in the fixlets in the BES Support site, is to use the action issue date. In that same example, you could have used
setting "myvalue"="1" on "{parameter "action issue date" of action}" for client
and
setting "myvalue"="2" on "{parameter "action issue date" of action}" for client
…in that case, when action 2 executes first, it resolves as
setting "myvalue"="2" on "Mon, 12/12/2016 10:05:32 -0500" for client
…and the setting gets a value of “2”. Then, when action 1 runs, it evaluates as
setting "myvalue"="1" on "Sun, 12/11/2016 17:05:02 -0500" for client
Since “myvalue” already has an effective date later than what was specified in action 1, the value is not changed again and remains set to “2”