Our team is running codebeamer ALM 23 and we’re experiencing significant workflow delays with automation triggers on large backlogs (500+ items). We have automation rules that trigger on status changes to update related requirements, send notifications, and calculate priority scores.
The problem: when multiple items change status simultaneously (like after sprint planning), the automation queue gets backed up and triggers timeout after 5-10 minutes. Some items process fine while others fail with timeout errors. We’ve tried adjusting individual trigger timeouts but that doesn’t address the underlying throughput issue.
I’m curious how others handle automation at scale. Should we be batching trigger executions? Is there server-side heap tuning needed? How do you balance real-time automation with system performance when dealing with hundreds of backlog items?
These are great suggestions. The priority-based queuing approach makes a lot of sense - we’re currently treating all triggers equally. I’m particularly interested in the batching strategy. How do you implement trigger batching in practice? Do you use custom scripts or is there built-in functionality in cb-23 for batch processing automation rules? Also, what’s a reasonable batch size for priority score calculations across related items?
One aspect people often overlook is the complexity of priority scoring algorithms themselves. If your automation is calculating scores by traversing deep relationship trees or running complex queries, that’s your bottleneck regardless of batching. We optimized our scoring logic to use pre-calculated aggregates stored in custom fields rather than computing everything on-the-fly. This reduced individual calculation time from 2-3 seconds to under 500ms. Combined with proper batching, our 600-item backlog processes completely in under 10 minutes now.
Heap tuning definitely matters for large-scale automation. We increased our application server heap from default 2GB to 6GB specifically for automation processing. Also check your database connection pool settings - automation triggers can exhaust connections quickly when processing batches. Set wt.automation.maxConcurrent=10 and wt.automation.queueSize=500 in your site.properties to control concurrent execution and prevent memory overflow.
For batch processing, we use a hybrid approach. Event triggers collect item IDs that need processing and add them to a custom queue table. Then a scheduled trigger (runs every 15 minutes) processes the queue in batches of 50 items. This prevents the thundering herd problem when 200 items change status at once. The batch size of 50 is a sweet spot - small enough to complete within timeout limits but large enough to be efficient. You’ll need some custom scripting to implement the queue mechanism, but it’s worth the investment for large backlogs.
Have you considered splitting your automation logic? Instead of one complex trigger doing everything, create separate lightweight triggers for different actions. One for notifications (fast), one for field updates (medium), and one for priority calculations (slow, can be batched). This way, critical operations complete quickly while heavy processing happens in background. We also schedule non-urgent automation to run during off-peak hours using time-based triggers rather than event-based ones.