Considerations for Avoiding Workspace Rule Conflicts
You should understand the sequence in which rules are performed in order to avoid rule conflicts.
Because processes for workspace rules, script rules, script branching rules, and workflows are often running at the same time, care must be taken to ensure that their actions do not conflict. For instance, when a script is added to a workspace, the script rules will be running even when the script does not have focus on the workspace. If a script rule and a workspace rule are configured to update the same field, an agent may find that the field does not update to the value they might expect. For this reason, it is helpful to understand the sequence in which rules are performed. Currently, rules are processed in the following order:
- Workspace rules
- Script current page rules
- Script current page branching logic
If additional scripts appear on the same workspace, processing continues as follows:
- Script 2 current page rules
- Script 2 current page branching logic
- Script 3 current page rules
- Script 3 current page branching logic
While a large number of rules may be difficult to track, remember that you can avoid most common types of conflicts by limiting the number of rules you create and avoiding overlap in triggers. For example, if a workspace rule and script rule are both triggered by a change to the Category field, you will want to make sure that these rules do not act on the same field or control (such as trying to set two different values for the Product field). If they must do so, add appropriate conditions to the rules to narrow their focus and impact.
Since most trigger events are common to workspace rules, script rules, and workflow connectors, it is important to try to minimize or reserve certain types of triggers for certain functions. For example, it is generally best to avoid or minimize the number of data changed triggers (such as “A field changes”) in your scripts. This is especially true for the first page of scripts, as this page will load when the workspace does and is therefore more likely to run into a conflict.
Finally, work performed in the agent desktop is augmented by another feature that is usually thought of as separate and distinct—the server-side business rules. Don’t forget to consider your existing business rules when designing your agent desktop, especially those functions most commonly performed by rules, such as changing incident assignment. And be sure to consider your agent desktop designs when adding new business rules. Tracking functional overlaps between business rules and your agent desktop is just as important as preventing conflicts within the desktop to ensure expected results.