Vantage / resources
Knowledge access: subscription, seats, and sign-in
Understand the separate checks behind a usable workspace.
Teams planning OPS_SRC KB access or additional users.
1. Identify which offering you are discussing
OPS_SRC KB appears as a public product and as an addon. The names are related, but the records are not interchangeable. Begin by confirming which packaging is relevant and, for an addon, which parent service it would attach to.
Avoid assuming that a catalog selection creates a workspace immediately. Commercial eligibility, service status, and the access path each need their own confirmation.
2. Ask what the quantity actually measures
A billed service quantity, an addon quantity, a portal-user allowance, and a workspace seat limit may describe different things. Ask which measure controls the access you are trying to provide and how it is calculated.
Extra 25 Portal Users is a named catalog pack. It does not by itself state the effective OPS_SRC workspace allowance or prove that twenty-five additional people are ready to sign in.
3. Separate workspace readiness from user readiness
A usable launch path depends on more than subscription status. The workspace must be active and provisioned, and the person attempting access must have the appropriate enabled user and sign-in context.
Ask how those prerequisites will be confirmed during onboarding. If a launch fails, distinguish a workspace still being provisioned from a user who lacks access; they call for different follow-up.
4. Know which knowledge experience is intended
Native portal guides and knowledge features are separate from OPS_SRC workspace access. An article visible in a portal concept is not proof of a completed migration into another workspace.
List the material people need, who maintains it, and where it should be accessed. That helps define the right conversation without promising a shared permission model or automatic content transfer.
5. Request help without exposing access material
Use the agreed support channel for an existing account. Describe the stage where access stops, the broad user role, and whether the issue affects one person or several. Never send a password, a one-time code, or a live sign-in link.
Ask for the entitlement, workspace, and user checks to be reviewed separately. A clear request helps narrow the issue without assuming that buying more capacity will resolve it.
- Confirm product versus addon packaging.
- Identify the parent service where applicable.
- Confirm the effective workspace entitlement.
- Verify workspace and user readiness separately.
- Keep credentials and sign-in links out of inquiries.