I do something similar while developing new BPMs. I have a security group
called Development and only IT people and testers are in it. Whenever I
work on that BPM, I make sure to add "the user is member of" rule until I
put it into production.
Mark W.
On Wed, Apr 10, 2013 at 12:04 PM, Ken Williams <
kwilliams@...> wrote:
called Development and only IT people and testers are in it. Whenever I
work on that BPM, I make sure to add "the user is member of" rule until I
put it into production.
Mark W.
On Wed, Apr 10, 2013 at 12:04 PM, Ken Williams <
kwilliams@...> wrote:
> **[Non-text portions of this message have been removed]
>
>
> I came up with a simple way to disable BPMs for particular users that I
> thought may be of use to others.
>
> 1. Create security group "BPM Exceptions"
>
> 2. For every BPM add "user is not a member of BPM Exceptions" condition as
> the first condition
>
> 3. Add whichever user you need to the BPM Exceptions group and all BPMs
> are now effectively disabled for that user
>
> For helping rule out issues, this will be a great time saver for me. I can
> leave BPMs running for all users, but put myself (or another user) in the
> exceptions group to run clean.
>
> It did take a while to update our BPMs (about half a day yesterday), we've
> got about 150 at this point - but moving forward we'll just make sure this
> is the first condition and be good moving forward.
>
> Hope this helps,
> Ken
>
> [Non-text portions of this message have been removed]
>
>
>