Using the scripts\commands discussed in this thread we have identified a possible 'chase' condition.
It looks as if, if someone approves a request, there is a short window where the review is not marked as pending anymore, but the subsequent actions have not yet been completed. If the second task that detects 'denied' reviews is running at the same time it is possible that it can incorrectly trigger.
The 'follow on' actions in the original approval task (in our case anyway) overwrite the attribute changes that the 'denied approval detection' task make within seconds, although (again in our case) an email is sent to the manager saying the user has been marked for removal.
We thought this *may* be possible but was unlikely - but as luck would have it, it happened on one of our dry runs! In order to fix it we've tweaked the 'detection' task so that it actually has to fail twice, as below:-
This means the first time the check fails the user is marked (we use a timestamp as we've still got 5 free and don't want to 'waste' a Boolean\Text attribute!), and only if it triggers a second time does the actual 'meat' of the task trigger. The original approval task now also has a final action to clear the timestamp attribute also, so any 'half failed' accounts are cleared.
One general question that does come out of this (as we have halved the time repeat schedule so that a deletion is still detected within the same time window etc), do you have any advice on how regularily tasks such as this should run? This task is parsing through every user account, and every request etc, so would you recommend that we don't run these type of jobs *too* regularily?
It's not a problem, but good background so that we make sure we don't start stressing the processing engine by assuming we can just throw tasks at it etc.