Review and follow these recommended practices to ensure your WLM implementation is stable, efficient, and scalable.

Recommended practices

Ensure redundant queue ownership
  • Recommendation: Ensure that the queue has at least 2 owners so that there is no deadlock if an owner is deleted or disabled.
  • Reason: This is a critical business continuity and administrative best practice. If a queue owner leaves the organization or their account is disabled, the secondary owner can still manage the queue (for example, pause, reconfigure, or manage the work items) without administrative bottlenecks, and thus prevent a deadlock.
Maximize work item visibility in Control Room
  • Recommendation: You can display up to 10 work item columns in the Control Room. Use this feature to get maximum visibility into your work item data.
  • Reason: When you define the structure of your work queue, you specify columns. Displaying relevant columns in the Control Room work items view enables operators and business users to quickly understand the context of each work item, identify specific items, and troubleshoot without needing to download the data. Choose the most important fields that distinguish one work item from another.
Optimize work item data and result values
  • Recommendation: Optimally use work item values that can accept up to 1000 characters, especially for result values of the work item.
  • Reason: The Result field of a work item is critical for providing granular feedback on the processing outcome (for example, Invoice Posted Successfully, ID: INV12345, Customer Record Created, Account: CUST987, or Failed - Invalid Email Format). Use the 1000-character limit to ensure comprehensive and actionable messages, reducing the need to check external logs for simple outcomes.
Prioritize work items effectively
  • Recommendation: To prioritize certain work items, ensure that you sort the work item data when you create queues.
  • Reason: While you can set a default priority for the entire queue and individual work items, the order in which you insert items can also influence initial processing of items of the same priority. So using a sorting criteria within the queue (done when creating the queue) ensures that items which meet specific business value or urgency will always be at the top of the queue for the devices to choose.
Insert bulk work item using API
  • Recommendation: To insert work items in bulk, use the workitems API because this API accepts a list of work items in JSON format.
  • Reason: Sending an API request to insert each single work item within a loop creates significant network and API overhead for thousands of items. So optimize performance by using the work items API, which enables you to construct a JSON array containing multiple work item objects (a batch) and sends it in a single API call. This drastically reduces the number of calls, making the device faster and more efficient when populating large queues.
Ensure cluster clock is synchronized
  • Recommendation: Ensure that the time (clocks) in all the nodes (devices) in a cluster is synchronized. This is important for the Apache Ignite cache server to function properly.
  • Reason: The Control Room uses Apache Ignite for its distributed caching. If the system clocks across different nodes in the cluster are not in sync, it can lead to data inconsistencies, cache misses, and other unpredictable errors, which might impact WLM performance and reliability. You need to configure Network Time Protocol (NTP) services.
Ensure continuous database connectivity
  • Recommendation: Ensure the database connectivity is persistent and continuous as this is critical for workload automation. Ensure that you perform periodic network scans or use tools that can detect or avoid network issues.
  • Reason: Continuous database connectivity is essential for uninterrupted workload automation. Any disruption in connectivity can cause task failures, delays in processing, data inconsistencies, and missed SLAs. Maintaining stable connectivity ensures reliability, smooth execution, and optimal system performance.
Ensure efficient work item retrieval through API
  • Recommendation: Apply the pagination filter to the API to retrieve work items in manageable chunks.
  • Reason: When you work items are retrieved programmatically from a queue through the Workload Management API, a default limit (often 200) is applied. This prevents the system is not overloaded with large responses. For scenarios where you need to retrieve a large list of items from a queue, use pagination (such as the offset and length parameters) to fetch them in manageable chunks.

Practices to avoid

Do not use individual API calls in a loop for bulk inserts
  • Recommendation: To ensure the WLM capability works efficiently, avoid using the workitems API in a loop to insert work items in bulk.
  • Reason: Setting up a separate API call for each work item in a large batch is inefficient and can create significant network and server load. Instead, batch insert work items using the list-accepting workitems API.
Do not create local schedules on devices in a device pool
  • Recommendation: If the device belongs to a device pool, avoid creating local schedules on it. This ensures the device is used exclusively for running work items.
  • Reason: Devices in a pool are managed by the Control Room for WLM. Local schedules can override this management, causing the device to run scheduled tasks instead of WLM tasks. This might result in resource conflicts, unpredictable behavior, and missed SLAs. Devices in a pool should remain fully available for Control Room- distributed work items.
Do not remove Run bot permission from active queue users
  • Recommendation: If a user has a queue in use, do not remove the Run bot permission from that user (role).
  • Reason: If a user's role (or the specific user account associated with a running process or schedule) is linked to a queue's processing, removing their Run bot permission will cause associated automations to fail. This in turn disrupts the WLM process. Always verify permissions before making changes, especially for accounts actively involved in automation execution.
Do not shut down devices during processing
  • Recommendation: If a work item is in progress, do not shut down a device. If a device has to be taken offline for maintenance, ensure that you pause the queue and verify that no work item is in progress on the device.
  • Reason: If a device is shut down abruptly while processing a work item, it can lead to the work item getting stuck (for example, in a PUSHED state indefinitely) or the progress can be lost. So ensure that any associated queue is paused first, allow currently processing items to complete, and then verify the device is idle before the device is taken offline. This ensures graceful handling and prevents data loss or orphaned work items.
Do not stop Control Room service during processing
  • Recommendation: If a work item queue is being processed, do not stop or restart the Automation Anywhere Control Room Service. Instead, pause the queue automation, and then restart the service.
  • Reason: The Control Room Service is a critical part of the Control Room, including WLM. Stopping it while queues are active will halt all processing, potentially leaving work items in an inconsistent state or causing errors in automations trying to update statuses. Always pause the queues (which stops automations from choosing new items) before performing maintenance on the Control Room Service, and then restart the service.

Understanding automation priority

The priority decides the processing order of the automations. You can set the automation priorities at the various levels:
  • Bot: When you schedule a bot (High, Medium, or Low). For more information, see Set automation priority for your bots.
  • Queue (at device pool level): Define the order in which your automations run in the queues (Round robin or Priority as shown in table). For more information, see Ordem da fila de automação.
  • Work Item (at Queue level): Set the priority for Work Item column value. For example, First Name column ascending order and Email column descending order.

To understand how the automation priority works, let’s see the following scenario:

Consider you have Q1 with 1st priority at the device pool level and Q2 with 2nd priority. Q1 has work items such as InvoiceAmount and Total with the following work item level priority:
  • Q1 workitem level priority -> InvoiceAmount column ascending order
  • Q2 workitem level priority -> Total column ascending order
When you add multiple workitems to Q1 and Q2 at the same time, Q1 workitem which has the lowest InvoiceAmount will run first.

In such scenario, queue priority at device pool level has precedence over the work item priority.

Consider another scenario where you have a WLM setup as shown in the following table:
Bot and Queue name Device Pool Users
Process 1 1 1 Bot1
Process 2 Bot2
Process 3 Bot3
Process 4 Bot4
In the above WLM setup, if you have deployed all four automations parallelly, than it will first complete the workitems from the first deployed automation process. Then the one you have deployed second will start and the order continues. However, all the four automations will not run parallelly. Therefore, if you want to run multiple automations, create a setup as shown in the following table:
Bot and Queue name Device Device pool Users
Process 1 Device 1 Pool 1 Bot1
Bot2
Bot3
Bot4
Process 2 Device 2 Pool 2 Bot5
Bot6
Bot7
Bot8
Process 3 Device 3 Pool 3 Bot9
Bot10
Bot11
Bot12
Process 4 Device 4 Pool 4 Bot13
Bot14
Bot15
Bot16