When you take action on the upload task, you should do it something like this:
It is actually important to use the while relevant, waiting
instead of whenever it becomes relevant again
I would also recommend having it: on failure, retry
with wait until the computer has rebooted
.
The reason for this is a bit odd.
If you use whenever it becomes relevant again
then it will ONLY reapply if the relevance becomes true, it runs, then it becomes false, then after a while it becomes true again.
If you use while relevant, waiting
then this guarantees that it will reapply.
It might seem that both options would guarantee it will reapply, but that is not the case if something wonky happens to cause the relevance not to go to false for some reason. It could be due to a failure, or a locked file, or something else.
If you did not take the action on the upload task this way, then I would bet this is the cause. If you did do it this way, then it could be lack of retry on failure, and if not that… then it is a bit more of a mystery to me and I would investigate the client more closely.
I do believe that with session relevance you can get the info you are looking for about how many times an action has run. You should also be able to determine when the last time the action ran. The session relevance could be used in the console, or WebReports, or through the REST API or other options.
I am also curious, why the SUA scans are initiated with a one off basis rather than run continuously on an interval for the machines that are being tracked?