Next Available Extension, Picked Right the First Time
Create a user, pick a department, and the extension number fills itself in from the department's own range, checked against every DN on the PBX. The 3CX console itself does not go that far.
The wrong number, suggested confidently
On a single-company PBX, "next available extension" is easy, and the 3CX console gets it right: it asks the PBX for the first free number and moves on. On the systems MSPs actually run, hosted instances and multi-tenant layouts where each department or tenant owns a number range, that same suggestion is a trap. The console does not read the range. It will cheerfully offer a number from another tenant's block, and the mistake only surfaces when callers start reaching the wrong company.
Sikurd reads the range. When the new user belongs to a department with a configured number range, the suggestion comes from inside it, first gap, reusing retired numbers, exactly the way a careful senior tech would do it by hand with the peers list open in a second tab.
Pick the department, get the right number: the extension suggestion comes from the department's own range. Demo data shown.
Why the full DN list matters
A number is not free just because no extension uses it. Queues, ring groups, and digital receptionists all occupy numbers, and on dense systems they often live inside the user ranges. Sikurd resolves the suggestion against the PBX's complete peer list, every DN type, so the number it offers is genuinely dialable-into-existence. If two techs race for the same number, the create flow re-validates on submit and quietly takes the next one.
Nothing to configure
The ranges are the ones already on the PBX. Sikurd reads the department's own settings, so the behavior lights up on any instance that has ranges configured and degrades to the standard PBX-wide suggestion everywhere else. Level-one techs get the right number by default, without knowing the numbering plan exists.
Frequently asked questions
How does the 3CX console pick the next extension number?
It calls the PBX's first-available-extension function, which returns the lowest free number system-wide, reusing deleted numbers. That is correct on a simple single-company PBX. It ignores department number ranges entirely, so on a multi-tenant or hosted system it happily suggests a number that belongs to a different tenant's range.
What does Sikurd do differently?
When the new user is assigned to a department that carries a number range, Sikurd walks that range first-gap against the PBX's full DN list, every extension, queue, ring group, and receptionist, and suggests the first genuinely free number inside the range. Departments without a range fall back to the same PBX-wide function the console uses, so simple systems behave exactly as before.
Why check queues and ring groups, not just extensions?
Because any DN type can occupy a number. A queue at 150 inside a user range means 150 is taken, even though no extension uses it. Checking only extensions is how you get the 'number already in use' error at submit time. Sikurd checks the full peer list so the suggestion is right the first time, and the create flow still re-validates on submit as a belt-and-suspenders measure.
Do I have to configure anything?
No. The ranges come from the department settings already on the PBX (the same UserNumberFrom and UserNumberTo the hosted platform provisions). Pick a department on the new-user form and the suggested extension updates to match its range automatically.
Stop hunting for free extension numbers.
Open the live demo, create a user on any instance, and watch the extension number resolve itself from the department's range. No signup required.
