Agent Desktop

Get Involved. Join the Conversation.


    Jens Lundell
    Soup up Workspace load! - Optimize your Workspace Rules
    Topic posted April 9, 2019 by Jens LundellSilver Crown: 22,500+ Points, last edited November 18, 2019, tagged Browser UI, Service Console 
    176 Views, 2 Comments
    Soup up Workspace load! - Optimize your Workspace Rules

    This is Part Three of the Soup up Workspace load! series. For the Introduction go here.


    Workspace rules is a great feature that can make static workspaces come to life – to allow you to support your custom business processes, enforce data consistency, and automate tasks to make your agents more efficient. Its power comes from the ability to let you combine a vast number of triggers, conditions, and actions in almost any way you want. But, as they say, With Great Power Comes Great Responsibility. That is, if you’re not careful you can easily create workspaces that are hard to maintain, workspaces that cause data corruption, or slow loading workspaces.

    I’ve often been asked, “How much do workspace rules slow down your workspace?” and “Is there a limit to how many rules a workspace should have?” Well, the answer depends entirely on the triggers, conditions, and actions your rules have. This article tries to shed some light on what type of rules are fast, which ones are slow, and how to best organize your rules.

    For the purpose of optimizing the initial load of workspaces, you should primarily look at the rules that run based on the Editor Loads trigger (although see the discussion on named events and cascading rules below). Review these rules and make sure they are all actually needed. Also make sure that you don’t have multiple rules doing the same thing, or multiple rules affecting the same object property. For example, if several rules show or hide the same tab, flickering and delay will occur. In such cases, try to consolidate the rules so you don’t have duplicated actions executed at the same time.

    Workspace Rules vs. Business Rules

    There’s a lot of overlap between Workspace Rules and Business Rules, and either can be used to implement certain business processes. In terms of performance, but also for maintainability and consistency, we most often recommend that you use Business Rules. For example, let’s say you have a workspace rule that sets a field when a record is opened. That rule will then have to run every time someone opens a record. You may also have to replicate that rule in multiple workspaces, and if you run reports on the records you will not see the value agents will see, you will see the unchanged value. To avoid this, make sure the records are saved with the correct field values to begin with, by utilizing Business Rules. Also, I also often see workspace rules that set fields that agents don’t care about, or that may not even be on the workspace, for example, Mailbox, Interface, or Queue. Those can often be set using Business Rules instead. In general, workspace rules should only be used to set fields that the agent needs to see before they save a record.

    Set control state to the most common state

    For fields and certain controls, you can change the visibility, required settings, and read-only settings using workspace rules. You can also set the default state of these properties statically in the workspace designer. It is recommended that you set the default state to match the most common cases, and then use rules to handle the uncommon cases by dynamically showing/hiding/changing required or read-only settings using rules. For example, if you have a Tab that is most often hidden then make it hidden by default and have a rule to show it when required, instead of having it visible by default and hide it when the workspace loads. 

    Related to this, when hiding or displaying many fields on a workspace, consider placing them in a tab or panel and then hide/display the tab or panel rather than each field individually.

    Performance of Triggers

    Triggers are what cause your rules to run in the first place, and they don’t have any performance impact on the rule execution itself. Rules that are not using the Editor Loads trigger do not affect the initial workspace load, although see the discussion on named events and cascading rules below.

    Performance implications of Conditions

    Conditions, in general, execute very fast, even if you have many of them combined in a logical expression. The one exception would be the add-in condition if your implementation of the add-in condition method takes a long time to execute.

    Slow and Fast Actions

    The Set Fields actions for integer, string, and date fields execute pretty quickly. Menus are also fast in the Service Console (.NET) but are a little slower in the Browser User Interface. Search fields (e.g. the Contact field on an Incident workspace) are slow in both consoles, as they need to retrieve the new record from the server.

    If the Focus a tab action executes when the workspace loads, the workspace will first show the controls and fields of the first tab, and then the controls and fields of tab the action focuses. This will increase load time since there will be more content that the UI needs to render. If you need to execute this action when the workspace loads, try to define conditions so it only executes for a minority of your records. For the majority of your records, the default tab would then be shown.

    Similarly, the action to Run a script can slow down workspace load since the workspace first needs to load and render the original script, then load and render the script the rule action runs.

    The actions to Execute an editor command can be very slow, especially the actions to execute Save and Refresh. For performance reasons avoid calling these on workspace load at all cost.

    The actions that load Guides and the Best Answer dialog are understandably rather slow since they need to load some heavy UI controls.

    Finally, executing named events is in themselves very fast, but these events may of course cause other slow rules to execute, so be sure you understand the implications of executing named events on workspace load.

    Be careful when using cascading rules

    The execution of a rule action can cause a trigger on another rule to fire. For example, if you have a rule that changes the Status field it will cause rules with the “WHEN Status Changes” trigger to fire. This can in some rare cases be useful, but overall I recommend you arrange your rules to avoid this. Such cascading rules make it very hard to follow the flow of the rules, and it often has unintended consequences such as firing the wrong rules or causing performance problems because unnecessary rules get executed.

    General Rules Bookkeeping tips

    These items don’t really affect the performance of rules - consider them “bonus tips” for making it easier to maintain your workspaces.

    Name and organize your rules

    Make sure to have logical names for your rules and group related rules together, possibly by using the same name prefix. The UI that shows the rules has a lot of information, so this can sometimes be challenging and you may have to use some clever abbreviations.

    Remove disabled rules

    Disabling rules can be useful if you temporarily don’t need them, or if you want to try out different behaviors. However, avoid the trap of forgetting why you disabled a rule. Also, after a while, it becomes hard to grasp what your rules are doing if many of them are disabled. Lastly, if someone else looks at the rules they will likely be confused by many disabled rules. If you do disable a rule, describe your reasoning in the rule’s notes and set a reminder to yourself to clean it up at a later date.

    Combine rules with the same trigger and conditions

    Sometimes you end up with many rules that have the same trigger and conditions, but different actions. It might make sense to keep these separate if they support different types of processes, but it is often better to combine them into the same rule. You will have fewer rules, making the workspace easier to understand and maintain.

    This concludes the third article in the Soup up Workspace load! series. In the next article, we’ll look at how to optimize your Desktop Workflows.

    Please share feedback, questions, and ideas in the comment section below.

    Jens Lundell
    Oracle Service Cloud