Consider the following policies, all for ModifyUserEvent in the Modify User admin task:
Policy |
Rule |
Evaluation |
---|---|---|
Policy1 |
User where (User ID = Smith01) |
Always |
Policy2 |
User where (Title = Manager) |
When the Title attribute changes |
Policy3 |
User where (Salary >= 80000) |
When the Salary attribute changes |
Policy1 is evaluated every time administrator invokes the Modify User task for user Smith01, regardless of which attribute changes.
Policy2 is evaluated when the administrator invokes the Modify User task to change the Title attribute for any user object. Policy2 is true if Title changes to Manager.
Policy3 is evaluated when the administrator invokes the Modify User task to change the Salary attribute for any user object. Policy3 is true if salary changes to 80000 or more.
In this example, if an administrator uses the Modify User task to change the Title attribute to Manager for user Smith01, then both Policy1 and Policy2 evaluate to true, and their respective workflow processes are started. In this case, the standard ordering priority applies.
Conditional rule evaluation allows an approver of one work item to change an attribute that affects another work item for the same event while the event is still pending. This is only possible for approval policies that have an evaluation type of Always. In the preceding example, if an administrator changes an attribute for user Smith01, then Policy1 is true and generates a work item. While approving the work item generated by Policy1, that approver may, on the same approval screen, change the Salary attribute for Smith01. In this case, the new Salary value for Smith01 determines whether or not Policy3 generates a work item for the same instance of ModifyUserEvent. If the approver changes the salary to 90000, then Policy3 generates a new work item which must be approved before the event itself is approved. Standard ordering priority applies.
Copyright © 2013 CA.
All rights reserved.
|
|