WLM FAQ - Review this FAQ to learn general concepts about WLM.

General

What does the WLM capability help me do?

Workload Management (WLM) enables you to efficiently manage and distribute high volumes of work items across multiple devices. It ensures tasks are prioritized, processed efficiently, and meet defined service-level agreements (SLAs).

What are work items?

Work Items are individual units of work (for example, a single invoice, one customer record, one loan application) that reside in a workload queue and are processed by the automation. Each work item contains the data necessary for the automation to complete its task.

How do I ensure data security in WLM?

• Implement role-based access control (RBAC) by assigning appropriate permissions to users and roles (for example, only WLM administrator can manage queues, only specific roles can consume items).

  For more details, see WLM: User roles and permissions.

• Work item data stored by WLM is encrypted at rest using AES-256 encryption. When a work item structure contains sensitive information, you can configure the applicable fields as hidden so that their values are not displayed in the Control Room.
• Use Credential Vault for secure storage and access of sensitive credentials used by automations.

  For more details, see Credentials and lockers in the Credential Vault.

Can I integrate WLM with external systems such as BPM and ERP?

Yes, WLM can be integrated using Automation Anywhere public APIs. External systems can then do the following:

• Insert work items into queues.
• Query queue status and work item details.
• Retrieve processed results.

This integration facilitates end-to-end process orchestration across different platforms. For more details, see Control Room APIs.

Workload queues

What are workload queues?

Workload queues are central repositories in the Control Room where work items are stored. They enable prioritization, load balancing, retry mechanisms, and real-time status tracking of work items.

How do I create a workload queue?

In the Control Room, follow these steps:

1. Navigate to Manage > Queues.
2. Click Create queue.
3. Define the queue name, and specify the columns or structure for your work items.

You can also define prioritization rules and retry settings here. For more information, see Create standard queues.

What types of files can I upload to populate a workload queue?

You can typically upload CSV (.csv) files directly to populate queues. The headers of these files can automatically define your queue columns. You can also use Workload package Insert work item action or APIs to insert work items from various other sources.

For more details, see Using Insert work item action.

Can I set priorities for different tasks or work items in WLM?

Yes, you can configure prioritization rules for each queue. You can sort work items based on the values in any of the defined columns (for example, sort by Due date ascending, Priority level descending). It ensures high-priority tasks are processed first.

For more details, see Actions allowed on view queue page.

What happens if a work item fails during processing?

If an automation encounters an error, the work item is marked as Failed. Based on the queue's configuration, the work item can be automatically retried after a specified delay for a defined number of attempts. If maximum retries are reached, it remains Failed for human review.

For more details, see WLM work item lifecycle and Work item status and actions.

How do I reprocess failed work items?

• Automatic retry: If auto-retry is configured, WLM will automatically re-process the Failed work items.
• Manual retry: A queue owner can manually select Failed work items in the Control Room and change their status back to New to trigger a re-processing by an automation, often after a human review has investigated and resolved the underlying issue.

Devices and device pools

What are device pools?

Device pools are logical groupings of devices. When an automation is deployed to a device pool, WLM automatically distributes work items to any available device within that pool, ensuring optimal resource utilization and scalability.

What is the role of devices in WLM?

Devices are the execution agents. They are the machines (physical or virtual) where the automations actually run to process the work items assigned by the WLM setup.

Can I use the same device pool for multiple queues?

Yes, you can use the same device pool for multiple queues. This is a common and efficient practice, as it enables your shared device pool to pull work from any of the associated queues based on overall priority and availability.

How does WLM decide which task or automation executes first if multiple queues share a device pool?

The WLM setup considers the priority settings within each queue and then the overall priority configuration across all queues sharing the device pool. It aims to pull the highest-priority work item from any of the associated queues for the next available device.

How do I scale my WLM setup to handle increased workload?

You can scale by adding more devices to the device pool associated with your queues. The WLM setup will automatically detect the new capacity and distribute work items across all the available devices.

Can the same device pool be used for both WLM and non-WLM automations?

Yes. A single device pool can be shared between Workload Management (WLM) automations and regular scheduled automations. Device pools in Automation 360 are designed to optimize device utilization across multiple automation workloads. WLM queues and non-WLM schedules can both consume devices from the same pool, provided the pool has sufficient runner capacity and appropriate scheduling controls are configured. However, when both workload types share the same device pool, Automation Anywhere recommends careful capacity planning and prioritization to avoid resource contention. For details, see Capacity and performance planning.

What is the recommended best practice for device pools with WLM?

Automation Anywhere recommends the following best practices:

Scenario	Recommendation
Mixed business-critical and non\u0002critical workloads	Use separate device pools to isolate high-priority WLM processes
Moderate workload with flexible SLAs	Shared device pools can be used effectively
High-volume transaction processing	Allocate dedicated devices or pools for WLM
License optimization object	Use shared pools with queue prioritization and schedule planning

Does WLM automatically reserve devices from a shared pool?

No. WLM does not automatically reserve or lock devices within a shared device pool. Runner allocation is determined by:

• Device availability
• Queue priority
• Bot execution timing
• Scheduling concurrency
• Runtime availability of the pool

If guaranteed execution capacity is required for critical queues, customers should configure:

• Dedicated device pools
• Dedicated runner allocations
• Controlled scheduling windows
• Capacity buffers for peak transaction periods

What are the practical considerations for sharing a device pool across WLM and non-WLM automations?

• License consumption is the same regardless of deployment type.

  Concurrent bot deployments include runs from any deployment model — schedules, Run bot now, WLM, triggers, Automation Co-Pilot, or API. Each active run on a device consumes an unattended device license. Sharing a pool does not reduce license consumption per run; it helps ensure no device sits idle. For more details, see Capacity and performance planning.

• WLM and scheduled bots compete for the same devices.

  If all devices in the pool are occupied by scheduled bots when a WLM queue is ready to dispatch work items, those items will remain in New status until a device becomes available. Conversely, a WLM-heavy period can delay scheduled bot execution.

• WLM guidelines recommend caution with local schedules on device in a device pool.

  If a device is part of a device pool, avoid creating local schedules on that device so that it runs only WLM work items. This guideline applies to local (machine-level) schedules; Control Room– managed scheduled deployments targeting the device pool are a separate consideration and are supported. For details, see WLM recommended practices.

• You cannot target a subset of devices within a pool.

  A user cannot select specific devices from a device pool to run an automation via a queue. When bots are deployed using a device pool, all devices in the pool are utilized. If you need to reserve certain devices exclusively for WLM or exclusively for scheduled runs, create separate device pools for each purpose.

Is sharing a device pool the right approach for license optimization?

Sharing a single device pool across WLM and scheduled automations is a valid license optimization strategy because it reduces idle device time. However, the benefit depends on workload patterns:

• If WLM queues and scheduled runs have non-overlapping peak times, sharing a pool is efficient and reduces the number of licensed devices you need to maintain.
• If both workload types are concurrently active and time-sensitive, a shared pool creates contention. In that scenario, consider dedicated pools per automation type, or add more devices to the shared pool to cover peak combined demand.

For high-availability behavior: Device pools provide built-in high availability for devices when an unattended license is free to use. If a device is unavailable, the scheduled automation automatically runs on the next available device in the pool.

For more information about device pool, see About device pools.

Monitoring and troubleshooting

How do I monitor the performance of workload queues?

The Control Room provides a real-time Automation Command Center (ACC) dashboard (Home > Monitoring). You can view automation run count (New, In Progress, Completed, Failed) and export data to CSV file.

My work item is stuck in the New status and not being processed. What should I do?

Review the following common causes and take the appropriate action based on the cause:

• There is no available device in the associated device pool.
• The automation is not deployed to the correct device pool.
• The Run as user for the device does not have the permissions to consume work items from the queue.
• The queue is paused.
• Devices are offline or the Bot Agent service is stopped.
• There might be network connectivity issues between the device and Control Room.
• There are no active schedules or triggers for the automation (though WLM often handles this implicitly when deployed to a device pool).

Why are my work items going directly to the Failed status without being retried?

• Check the queue configuration in the Control Room. The maximum retries value might be set to 0.
• The automation might be explicitly marking the item as Failed, without allowing retries based on its internal logic.

Can I prevent an automation from processing work items during a specific downtime (for example, system maintenance)?

• You can pause a queue from the Control Room during the downtime. An automation will stop pulling new items. When maintenance is completed, you can resume the queue.
• Alternatively, the automation logic can include a check for the current time and pause its own processing or defer work items if it falls within a known downtime window.

Other resources