Agent Desktop

Get Involved. Join the Conversation.

Topic

    Jens Lundell
    Soup up Workspace load! - Optimize your Workflows
    Topic posted August 5, 2019 by Jens LundellSilver Crown: 22,500+ Points, last edited November 18, 2019, tagged Browser UI, Service Console 
    344 Views, 1 Comment
    Title:
    Soup up Workspace load! - Optimize your Workflows
    Content:

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

    Summary

    With Workspace Rules you can define your own business logic within your workspaces. With Desktop Workflow you get even more power because you can decide when to show which workspace and configure when to create and change records. It’s like a programming language, where instead of writing lines of code you visually connect elements and set properties. Just as with regular programming, there are often different ways to build your desired functionality, and the performance of the different approaches may be very different.

    As discussed before, make sure you only use features that are actually needed for your business process. Review your workflows with a critical eye, and remove unused elements and connectors. Click on the Validation button, and fix all the warnings and errors shown. Make sure the workflow doesn’t have silly things such as a Decision element’s Yes and No connectors going to the same element. See my Managing Complex Workflows Dynamic Agent Desktop Cookbook recipe for tips on how to clean up your workflows.

    Fastest Workflow? EP -> Workspace

    In this article series, we have focused on optimizing the time it takes to load a workspace and show relevant data to the agent. If the workspace (or script) is in a workflow, you should try to avoid having unnecessary elements execute before the first workspace/script element is reached. Ideally, you should have the Entry Point element connected directly to a Workspace/Script element. This is especially true in the Agent Browser User Interface (BUI) as BUI is then able to start creating the workspace UI elements in the background as the record data is being requested and returned from the server.

    One big Workspace or many smaller Workspaces?

    Workflows are often used to break up big complex workspaces into several smaller, less complex, workspaces. This can result in improved agent usability as the different workspaces can be tailor-made for specific processes. Less complexity can also help with maintenance, since the chances of breaking processes will be lower. Finally, it often allows you to establish multiple workspace owners, who can independently make changes without stepping on each other. Certain modifications can, however, be more difficult to do with more workspaces. For example, if you need to add a new mandatory field to the incidents object, you may find that you need to add that field to multiple workspaces.

    Smaller workspaces may load faster than a big one, but they may require you to add additional elements in the workflow, typically one or more Decision elements. As mentioned above, that can increase load time, since the path from the Entry Point to the first Workspace element will be longer. In essence, there’s no hard-and-fast rule on which approach will perform the best. I strongly recommend you thoroughly test the performance of the different approaches before making production changes. Keep in mind that each workspace, script, and nested workflow in the workflow is cached individually, so the first time you run down a certain path, the load time for that path will be a little slower.

    Avoid using the Save element

    The Save element can be useful in certain scenarios, but avoid using it before the initial load of a workspace or a script. A Save element needs to send data to the server and then receive the updated data back, which will slow down the workflow execution time. Such a workflow will not have good performance.

    Avoid using the Load element

    Depending on the settings, the Load element will either prompt the agent to select a record, or it will load a record directly from the server. Neither will be particularly fast so we strongly recommend you don’t use a Load element before the initial load of a workspace or a script.

    Set Fields element vs. Business Rules

    The same considerations discussed in the previous article’s Workspace Rules vs. Business Rules section apply to the Set Field element. That is, instead of having Set Field element(s) execute when a record loads, have those fields set upon saving through Business Rules instead. The workflow then won’t have to execute the elements every time you open a record.

    Performance characteristic of elements

    Overall, the Set Fields element performs similar to its equivalent set field workspace rule actions, see the previous article. In summary, most data types are fast but be careful with setting menu fields and search fields.

    The Change element is essentially the same as a Set Fields element that sets a search field. Hence, it isn’t particularly fast and you should avoid using it when a record loads.

    The remaining elements not already discussed should all execute relatively fast, but as mentioned try to use as few of them as possible when a record loads.

    Use the Return element instead of recursion

    In a few cases I’ve seen customers use complex nested workflows where the first workflow invokes a second nested workflow, which then, in turn, invokes the first workflow again, hence creating a second instance of the first workflow. This creates a recursive behavior that is error-prone and utilizes more memory. Instead, use the Return element to return from the second workflow back into the original first workflow instance. See my Managing Complex Workflows Dynamic Agent Desktop Cookbook recipe for how to do this.

     

    This concludes the fourth article in the Soup up Workspace load! series. In the next article, we’ll look at how to optimize your Service Console .NET Add-Ins.

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

    Jens Lundell
    Oracle Service Cloud

    Comment