Set up your account & team

The first things an administrator does: get into the portal, know which environment you’re in, and bring your team in with the right roles. (Admin)

Sign in

Open the Provision Portal and sign in with the account you created during onboarding. After sign-in you land on the first page your role can see — for an administrator that’s the Dashboard.

If your operator has turned it on, the sign-in page also offers Sign in with Google, GitHub, or Microsoft. These work only for people who are already invited: the provider account’s email must match an existing, approved user on your environment, and the first successful sign-in links that account to the user. An unrecognized email is turned away with a note to ask your administrator to invite you first — social sign-in never creates a new account on its own.

Know your environment

Under Settings → Environments you’ll see every environment under your account — your production environment and any non-production ones you’ve added. Each row shows its identifier, name, URL and creation date. Switch environments by opening the environment’s URL and signing in there.

Use a non-production environment to model the catalog and rehearse a flow without touching production. Two types are available, and you can have more than one of each:

• Sandbox — development and CI.
• Staging — pre-release rehearsal.

Adding and removing environments is done from your production environment. Sign in there, then choose Add environment above the table, pick the type, and optionally give it a display name. The dialog shows the address it will be created at before you confirm. From a sandbox or staging environment the table is read-only and points you back to production.

Addresses are derived from your production environment’s endpoint name. The first sandbox becomes your-name-sandbox; the next ones are numbered — your-name-sandbox-2, your-name-sandbox-3 — so every environment keeps a stable, readable address. Give each a display name to tell them apart in the table.

Depends on your plan

Non-production environments are included from the Professional plan upward — on a lower plan the page says so instead of offering the action — and how many you can have in total depends on your plan. See Oclavex Plans.

A new environment has its own sign-in. Your production password does not work there. An invite email follows creation, sent to the same address you sign in to production with: set a password from it, then sign in at the new environment’s URL. If that email doesn’t reach you, open the new environment’s URL, choose Forgot password, and enter the same address for a fresh link. Only your own administrator account is created — invite the rest of your team the same way you did in production.

To remove one, sign in to your production environment and use the delete action on its row. The action is offered there and nowhere else — production itself cannot be deleted, and from a non-production environment no row has it. You’ll be asked to type the environment’s identifier to confirm. Deleting removes that environment’s catalog and settings and cannot be undone; your production environment is unaffected. It stops counting against your plan immediately, and its address is free again — so a fresh environment of the same type takes the address you just released.

Start a non-production environment over

A sandbox fills up — half-built products, expired trials, months of test usage. Reset empties one back to how it arrived, without deleting it. The environment keeps its identifier, its address, and your subscription, and administrators keep their sign-in, so there is no re-invite and nothing to point integrations at again.

Use the reset action on the environment’s row. You can reset from production, or from the non-production environment itself — unlike add and remove, a sandbox is allowed to reset itself, because a reset doesn’t change which environments you have. You’ll be asked to type the environment’s identifier to confirm.

Production can never be reset.

Everything the environment accumulated is destroyed and cannot be recovered:

• the catalog — products, features, suites, plans and offers
• entitlements, licenses and activations
• usage and metering history
• webhook subscriptions and their delivery history
• organizations, customer records and mail history
• every portal user without the Admin role — a Sales or Viewer user goes with the rest — and any invitations still outstanding
• every registered API client and machine credential

That last one is the one to plan for: integrations have to be registered again after a reset. Nothing carries over from the old ones.

The wipe runs in the background across the platform, so give it a few moments before you start rebuilding. When it finishes the environment is ready for a new product straight away.

Invite your team

People are managed under Customers → Users.

1. Open Users and create a user — give them an email and name.
2. On the new user’s Platform roles tab, open the User Roles card and switch on the role they need (see below).
3. Save. The person is invited and signs in with their own credentials.

You can later deactivate or approve/block an account from the same page. To find disabled accounts, filter the list to inactive users. Passwords and MFA are handled by the sign-in identity provider’s own recovery flow, not from the portal.

Assign roles

The portal has a fixed set of four roles — pick the least-privileged one that lets the person do their job.

Role	Give it to	They can
Administrator	Owners and operators	Everything, including Settings and Compliance
Sales	Account execs	Create and publish entitlements, manage customers, issue codes
Support	Support agents	Renew, top up credits, oversee activations, approve/unblock users
Viewer	Stakeholders	Read-only dashboards, reports and record browsing

A few rules to know:

• Role changes take effect at next sign-in — the role card says so.
• The vocabulary is fixed. The role card is a set of switches, not a text box; there’s no custom-role builder.
• No role means consumer. Users created without any role default to the consumer role — they can use the end-user portal but have no admin access.

Depends on your plan

Administrator and Sales are administrator seats and count against your plan’s portal-user cap. The Sales, Support and Viewer roles require the role-based permissions feature — if your plan doesn’t include it, those switches are disabled with an upgrade hint and Administrator is the only role you can assign. See what depends on your plan.

What you can’t change

You can’t invent new roles or hand-edit individual scopes per user beyond the four personas. If Administrator alone is too broad, the answer is a plan that includes the granular roles — there are no custom roles. See Administer access & settings for API clients and the rest of Settings.