Overview
An organization has a pool of outbound call concurrency to share across its main account and any sub-accounts. Bolna divides that pool using two settings on each account:Guaranteed minimum
Concurrency reserved for an account — it can always run at least this many calls, even when the rest of the organization is busy.
Maximum cap
The ceiling an account can reach. Leave it unset to make the account elastic — free to burst into the organization’s unused capacity.
The organization envelope
Your organization’s envelope is provisioned by Bolna:- Organization maximum — the hard ceiling on total simultaneous outbound calls across the main account and every sub-account combined. The organization never exceeds this.
- Organization guaranteed minimum — the capacity Bolna guarantees your organization as a whole, even when the wider platform is under load.
min_concurrency (its guaranteed floor) and an optional max_concurrency (its cap).
Per-account settings
| Setting | Meaning | Notes |
|---|---|---|
min_concurrency | Guaranteed floor for the account | 0 means no guarantee — the account only runs calls when spare capacity is available |
max_concurrency | Hard cap for the account | Omit (or null) for elastic — the account can burst up to the organization maximum. 0 pauses the account |
How calls are allocated
Each scheduling cycle, Bolna decides how many new calls to start per account:Guarantees first
Every account is brought up to its guaranteed minimum before any spare capacity is handed out. Calls already in progress are never dropped to make room.
Spare capacity is shared fairly
Whatever is left in the organization pool is shared among the accounts that still have calls waiting, in proportion to their guarantees — so an account with a larger floor also gets a larger share of the surplus.
Bursting up to the cap
A capped account bursts up to its
max_concurrency; an elastic account (no max) can keep climbing until the organization pool is full.When a telephony provider is saturated platform-wide, Bolna temporarily rations each organization toward its guaranteed minimum: floors are still honored, but bursting pauses until the provider frees up.
Configuration rules
When you set or change limits, Bolna validates the whole account set so guarantees and caps stay consistent with the organization envelope:- The sum of all account minimums must not exceed the organization’s guaranteed minimum.
- The sum of all capped account maximums must not exceed the organization maximum. Elastic accounts (no max) are not counted toward this sum.
- For any account,
min_concurrencymust not exceedmax_concurrency.
400 explaining which sum was exceeded, for example:
Worked example
An organization with a maximum of 100 concurrent calls, distributed across three accounts:| Account | min_concurrency | max_concurrency | Behavior |
|---|---|---|---|
| Main | 20 | (elastic) | Always has 20; can burst toward 100 when capacity is free |
| Sales (sub) | 30 | 50 | Always has 30; bursts up to 50 |
| Support (sub) | 10 | 30 | Always has 10; bursts up to 30 |
- Only Sales is busy: Sales runs up to its cap of 50; the remaining capacity stays available for the other accounts.
- All three busy, demand over 100: each account first gets its guarantee (20 + 30 + 10 = 60), then the remaining 40 is shared in proportion to those guarantees, up to each account’s cap. Anything that still doesn’t fit queues and dials as calls finish.
- Provider saturated: the organization is rationed toward its guaranteed minimum; the guarantees above are preserved while bursting pauses.
Who can manage it
Only organization admins can set or change account concurrency, from the dashboard or the API. Sub-account members cannot.Setting concurrency
Create a sub-account
Set
min_concurrency and max_concurrency when creating a sub-account.Update a sub-account
Change an existing sub-account’s guarantee or cap.