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

Optimize your data model

While it is important to optimize your workspaces and workflows, you also need to make sure the system’s data model isn’t overly bloated, so clients request too much data when you open records. Let’s take a look under the hood to better understand what happens when you open a record, an incident in this case. Say you’re looking at a report showing incidents (for example a My Inbox report) and then you select to open one of the incidents. The Agent Desktop then makes a network request to the cloud to get the incident data, which includes incident fields and child objects, such as threads. In addition, there will be requests to get record data for the incident’s standard parents (for example the incident’s contact and organization) and also custom parents you have defined in the Object Designer. It is worth noting that all the workspace exposed fields from these records are always requested, even if they are not present on the workspace. Thus, workspace rules and add-ins can query and modify non-visible fields. More requested data equates to slower loading of a workspace, which leads to a few concrete recommendations for optimizing performance:

Make sure your incident object has as few fields (custom fields and system attributes) as possible.

Limit the amount of data stored in the fields that you need, specifically review your usages of Text Area custom fields and Long Text system attributes.

Reduce the amount of thread data that incidents have. Encourage or enforce that big thread content, such as logging data, are stored as file attachments instead. When you open an incident, the Agent Desktop only requests the overview data for the file attachments, not the actual file contents.

Limit the number of parents that the incident object has by reviewing the incident’s relationships in the Object Designer. Also, as in #1 and #2, limit the fields and field data from those parents.

If you don’t need to record transactions and user transactions, uncheck the corresponding checkboxes

If you don’t use the Custom Object as a menu in other objects, don’t check the Object Generates Menu checkbox. If checked the system will create a menu containing one item for each row of the object, which can potentially use up a lot of memory in the Agent Desktop

This is more related to the performance of saving records, but we recommend you also review your Business Rules and Custom Processes (CPMs), and remove those that are not needed.

As you can see, these recommendations all consist of reviewing and removing unused features and options. You can almost compare maintaining an Oracle Service Cloud installation to gardening. You constantly have to revisit your garden layout, get rid of unwanted plants, trim bushes and trees, plant new flowers, and in some cases you will have to start over. Just continuously adding more plants will quickly result in a jungle.

Incorporate agent feedback

Most of the material in this community post series will be fairly technical, with specific recommendations on how to best use the various features of Oracle Service Cloud. While the technical recommendations are important to understand, we recommend you also periodically spend time watching your agents and asking them for feedback. Go through the full lifecycle of working on incidents with agents and take detailed notes. This will help you find bottlenecks and inefficiencies that may not be technical in nature but could be caused by inefficient processes or lack of training. We highly recommend you take a look at the How do contact center agents influence how you administer Service Cloud? Hero Hub challenge and read about other Oracle Service Cloud users’ experiences.

Measure performance and establish a baseline

Diagnosing performance problems can unfortunately be very difficult, mainly because there are so many variables at play, some of which you have very little control over. The trick is to start by eliminating as many environmental factors as possible and establish a performance baseline. We recommend you do that by following these steps:

Make sure you are on a wired internet connection and, if possible, not on a VPN

Close as many applications on your PC as possible, ideally reboot and then close applications not needed for the test

Login to the Agent Desktop

Open an incident that you want to establish the baseline for a few times, to make sure the cache is primed

Open the incident from Recent Items, or from a report, several times (e.g. 10), and measure the time it takes for the workspace to fully load. Record all the times and calculate the average. Use a stopwatch to measure the time as that will give you a good representation of the wait time as experienced by agents.

The baseline can now be used to see how proposed changes affect performance. You make a change and then retest, and you can be reasonably sure about the impact of the change. You can also use the baseline to compare results between different environments and scenarios. If for example a group of agents experience significantly worse performance than the baseline you know there must be something specific to their environment. Check their network settings, their PC settings, applications running on their PCs, extensions and rules specific to their profiles, etc. For network testing we recommend you learn how to use tools such as Fiddler, Wireshark, and the speedtest.net site. For the Agent Browser User Interface learn how to use the browser’s development tools’ network tab.

In addition to establishing a baseline for your customized workspaces/workflows you may also want to establish a baseline for the standard workspace. This can be useful to see if any of your customizations and integrations is causing problems.

This concludes the first installment of the Soup up Workspace load! series. In the next post we’ll investigate how to tweak workspace designs to make workspaces load as fast as possible.