System and User Management
License Management — Multi-CC Manager portal
16 min
audience people who sign in with multi cc manager credentials sample entry url https //\<host> \<port>/app/ license management screen https //\<host> \<port>/app/#customtab1 demo urls are examples; production hosts will differ ) what this screen is for license management is where a central administrator sees the overall license pool purchased for the platform and splits (“allocates”) that pool across separate contact centers (environments) such as eg cc1, cc2, cc3, cc4, cc5 rows = individual license items (features, limits, role caps) available license= what the whole system is entitled to (the master contract) columns for each environment = how much of that entitlement you assign to that contact center so one global budget, many child contact centers, each getting a slice where the product allows splitting how to open it 1\ log in to the multi cc manager web app (e g /app/) 2\ in the top bar, open license management (the label is defined in the product as license management) how to read the table area meaning license key internal name (e g , adminconfigurableusers, allowdialuser) support and engineering use this in logs and config license name friendly label (e g , "admin configurable users", "allow dial user") available license global limit or status a number, true/false, or na depending on the license type environment columns (defaultcc, setup, demo, cc1,cc2 etc ) per–contact center allocation for that row types of licenses you will see a on/off (boolean) licenses available may show as true or false , or na if not applicable in that form \ environment cells often use checkboxes checked = that feature is enabled for that contact center , unchecked = off for that cc example from ui `allowdialuser` — “allow dial user” with checkboxes per environment b numeric / quota licenses available is a total cap for the whole deployment (e g 50 admin configurable users, 300 executive logins) \ you enter numbers per environment those numbers are how much capacity each cc consumes from the global pool important (product behaviour) for many numeric, multi tenant items, the system expects the sum across all contact centers to not exceed the available (global) value if you allocate too much in total, save/update should fail validation (with an error about numeric sum / license validation) c role based login limits (`allowedusertypemaxlogin`) \ you see one row per role (administrator, analyst, customer manager, executive, …) available is often a global maximum for concurrent or allowed logins for that role (exact enforcement is per product rules) \ cells can combine numbers with client/channel tags (e g `java webaccess client`) because limits can differ by how users connect (web access vs other clients) the reference image's tags and “+5” style indicators are the ui expressing per client type slices inside that cc how to use it 1 start from “available license” treat it as the ceiling you cannot exceed across ccs (for pooled numeric keys) 2 decide each environment’s need example defaultcc is production heavy; demo is light—give demo smaller numbers 3 edit cells booleans toggle checkboxes per cc numbers type or select values per cc; use any client type controls if shown (they refine which clients consume that slice) 4 apply if the total across ccs is too high, expect validation errors —reduce one column or increase the master license, not something you can invent in the grid alone 5 use search and pagination title like license(80) means 80 rows ; pagination ( rows per page , next/prev) moves through the full list use search to find a key or name quickly nuances two levels of license system / global license (what you bought — “available”) per–contact center store (`getmultitenantlicensestore` in code) — what you set in the grid runtime checks use the cc specific value for users and operations in that cc not every key is “splittable” only licenses marked multi tenant in the product can be managed this way; others may be rejected if someone tries to treat them as per cc splits multi cc manager login uses a different login path than normal cc users; session level license checks still apply advantages one pane to see global entitlement and who gets what per cc supports multi tenant operations many ccs (defaultcc, setup, demo, …) under one commercial license feature toggles per cc (boolean rows) without touching each cc’s admin screens for every flag role and client granularity where the product defines it (e g executive + web access) validation helps prevent over allocation vs the purchased pool (sum and upper limit rules) disadvantages easy to misallocate raising one cc without lowering others can break sum validation or starve another cc technical keys operators need training to map license name ↔ real impact (e g `adminconfigurableusers` caps admin created users in that cc) master license changes usually require vendor / deployment steps; the ui distributes entitlement, it does not replace a new license file if you need more available total wide tables (many cc columns) are hard to scan; pagination across many rows makes it easy to miss a row mistakes affect production behaviour immediately after save logins blocked, user creation failing, features disabled—always test on non production ccs first when possible who should use this screen central/platform admins with multi cc manager access not typical supervisor or agent users \ changes should follow change control document old vs new numbers per cc quick glossary term simple meaning contact center (cc) / environment a tenant slice (e g , defaultcc, demo) with its own users and configuration available license global entitlement derived from the system license allocation the specific number or checkbox status set within a cc column multi tenant license a license the product allows to be split per cc; enforced and validated in the backend
Have a question?
Our knowledgeable support team and an awesome community will get you an answer in a flash.
To ask a question or participate in discussions, you'll need to authenticate first.
