Based on the research, I can answer your specific scenario: Yes, a flow in the "important" queue (priority 2) CAN run even while the "critical" queue (priority 1) is at its concurrency limit of 3 running flows. Here's how it works: 1. Each work queue maintains its own independent concurrency limit 2. The "critical" queue having 3 running flows means it's at its limit (3) 3. The "important" queue can still run up to 5 concurrent flows, regardless of the state of the "critical" queue Priority only affects the order in which flows are picked up when they're first submitted. It doesn't create a blocking relationship between queues. Think of it this way: - Priority determines "who gets picked first" when flows are waiting - Concurrency determines "how many can run at once" for each queue So in your case: - Critical queue: Priority 1, currently running 3/3 flows (at limit) - Important queue: Priority 2, can still run up to 5 flows regardless of critical queue's state This design allows for efficient resource utilization while still maintaining preferential treatment for higher-priority workloads when they're first submitted. You can find more details about this behavior in the documentation: - Work Pools and Queues Concepts - Global Concurrency Limits Guide

Key Points to Remember: 1. Priority only affects the initial pickup of flows when they're ready to run 2. A higher priority queue doesn't block a lower priority queue from running flows 3. Each queue maintains its own independent concurrency limit 4. If both queues have capacity, higher priority flows will always be picked up first 5. If the higher priority queue is full, lower priority flows will still run (up to their concurrency limit) This setup allows you to ensure your critical workflows get priority attention while still maintaining good throughput for your important but less time-sensitive workflows.