> Source: https://wexa.ai/docs/administration/getting-started

# 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](/docs/administration/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](/docs/administration/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:

1. **Create your first department.** Skippable.
2. **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 `Default` is created inside it.
- Skip both: a department called `General` is created, renameable later, with a `Default` project
  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:

  <Card title="Organization" href="/docs/administration/organizations">
    Settings → Organization. Name, primary domain, deployment posture and the organization's
    reusable join key.
  </Card>
  <Card title="Departments and projects" href="/docs/administration/departments-and-projects">
    Settings → Departments and Settings → Projects. Mirror your company's structure, and decide
    which boundary each team belongs on.
  </Card>
  <Card title="People" href="/docs/administration/members-and-invitations">
    Settings → Users. Invite colleagues, resend or copy an invitation link, change what someone
    administers, and suspend an account.
  </Card>
  <Card title="Roles" href="/docs/administration/roles-and-permissions">
    Settings → Roles. The four roles that ship, what each can and cannot reach, and custom roles.
  </Card>
  <Card title="Credentials" href="/docs/administration/credential-management">
    The API keys screen. Issue, list and revoke the keys that programs use to call Wexa.
  </Card>

## What you should do first

Once a project exists, the set-up worth doing before anyone else arrives is short:

1. **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](/docs/administration/departments-and-projects) before you create the
   second one.
2. **Decide who administers what.** Wexa distinguishes an organization-wide administrator from
   one scoped to a department or a single project. See
   [roles and permissions](/docs/administration/roles-and-permissions).
3. **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.
4. **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](/docs/concepts/tenancy),
[what a project owns](/docs/concepts/projects),
[Simple and Advanced project mode](/docs/concepts/project-mode), and the governance pages on
[policy and approvals](/docs/concepts/policy-and-approvals) and
[lifecycle and audit](/docs/concepts/lifecycle-and-audit).