Getting started as an administrator
This page follows the path an administrator takes from having no account to having a working project, and then says where the rest of the administration screens are.
Step 1 — Sign up
Signup is at /signup. The form asks for a first and last name, an email address, a password typed
twice, and your organization's name. Depending on the deployment it also asks for an invite key.
Whether the key is demanded is a deployment decision, not a per-account one. The signup page checks before it renders the form — GET /users/signup-config returns
{ accessKeyRequired }, backed by the SIGNUP_ACCESS_KEY_REQUIRED setting, which defaults to
required. So on a default deployment you cannot create the first account for your company entirely
unaided: you need a key from whoever operates the deployment.
The keys come in two kinds, and the difference matters:
- A platform-scope key is minted for one email address, is single-use, and expires after a day. Redeeming it creates a new organization.
- An organization-scope key is reusable and never expires. If it is already bound to an organization, redeeming it joins that organization — and only if the email has also been invited (see members and invitations). If it is not yet bound to one, the first redemption creates an organization and binds the key to it permanently, so every later redemption joins rather than creating another.
Signup is one database transaction, so a key cannot be spent twice by two concurrent signups. Email verification is deliberately skipped: the account is created already active and the response carries login tokens, so you are signed in immediately.
Step 2 — Your organization already exists
There is no separate "create an organization" step, and no screen that offers one. The organization is created for you as part of creating your account, named from the organization name you typed, and you are recorded as its owner. See organizations for what this means for the rest of the set-up.
Step 3 — First department and first project
A new account lands on /onboarding, which renders outside the main shell — no navigation, no
project switcher — until it is finished. It has two steps, in order:
- Create your first department. Skippable.
- Create your first project. Skippable.
Each step can be skipped on its own, and skipping is not the same as doing nothing:
- Skip the department, create the project: you get the project you named, with no department.
- Create the department, skip the project: a project called
Defaultis created inside it. - Skip both: a department called
Generalis created, renameable later, with aDefaultproject inside it.
A project must exist before the gate lifts, so the second step always resolves to a project one way or another. Whatever you create yourself is kept — the automatic provisioning only fills the gaps a skip left behind. The screen does not reappear on a later sign-in: the check is server-side and asks whether you own a project, not whether you clicked through the screen once.
Step 4 — The administration screens
Everything after the first run lives under Settings in the main application. The screens that exist, and the pages here that describe them:
Settings → Organization. Name, primary domain, deployment posture and the organization's reusable join key.
Settings → Departments and Settings → Projects. Mirror your company's structure, and decide which boundary each team belongs on.
Settings → Users. Invite colleagues, resend or copy an invitation link, change what someone administers, and suspend an account.
Settings → Roles. The four roles that ship, what each can and cannot reach, and custom roles.
The API keys screen. Issue, list and revoke the keys that programs use to call Wexa.
What you should do first
Once a project exists, the set-up worth doing before anyone else arrives is short:
- Decide your structure. Departments group projects and people; a project is the unit of isolation. Getting this wrong is expensive to undo, so read departments and projects before you create the second one.
- Decide who administers what. Wexa distinguishes an organization-wide administrator from one scoped to a department or a single project. See roles and permissions.
- Invite people with their role and scope set in the invitation, not afterwards — the invitation carries the role and the department or project, and the access it implies is materialized the moment they accept.
- Issue credentials last, and only for the projects that need programmatic access. A key can do nothing the person who minted it could not already do.
Where the boundaries are explained
The administration screens sit on top of concepts explained elsewhere, and those pages are the ones to read if a screen's vocabulary is unfamiliar: organizations, departments and projects, what a project owns, Simple and Advanced project mode, and the governance pages on policy and approvals and lifecycle and audit.