I think I see what’s going on now. All of your approvals are being included in the same approval activity. That’s not what this utility handles. This is for different approvals that are added later in an approval workflow. In your situation the workflow activity should handle this for you (or you need to code in logic in the workflow activity to make sure the same person isn’t added twice. I think the reason ServiceNow has left it this way is that you could argue (particularly for a group approval activity) that each user should need to approve on behalf of each group they are a member of.

With or without the Business Rules … same is happening.
Approval mail generated twice. After approving one of the approval tasks .. the 2nd approval is still open to be approved (for the same user).

No idea what is going wrong … any idea on that?

Unfortunately it is not working anyhow. Need to further investigate. Have 2 approvals sent to to different groups … meaning double mails in case one person is in both groups.

I’m not sure what else you can try then. I can enter that condition without issue into the standard ‘Condition’ field on the business rule in my Helsinki instance. You’re correct that the condition builder is removed, but the standard field should still work. You may try typing it in manually or testing with a completely different condition to see if anything works at all for you.

Might be a copy/paste issue. You might try typing it in directly and see if that helps. You could also use the condition builder widget on the business rule to provide the condition.

Thanks Marks for the reply. Unfortunately conditions are somehow not possible to be used when set to async even there is a condition field on top of the script … but entering the condition – current.state == ‘not_required’ .. the error occurs: “JavaScript parse error at line (1) column (18) problem = illegal character (; line 1)” …
any idea?

I think you’re probably right about the ‘changesTo’ in the Async script above. You should be safe to change the condition to current.state == ‘not_required’ and it should work fine though. Normally I wouldn’t recommend running a business rule every time a state equals that value just because it’s going to be running way more than is necessary, but in this case an approval really wouldn’t be updated very often (if at all) once it reaches a ‘not required’ state. I’ve updated the article above reflecting this change.

… so I’m wondering how the 2nd Business Rule mentioned above will be fired without the condition set. Sorry I’m not the scripting guy ;-)