Skip to main content

Access and Onboarding

REQQA is invite-only. There is no public sign-up button, no self-service registration discoverable from the site, and no "create your account" call to action. This is a deliberate design choice, not an oversight, and it shapes the entire journey a new person takes from first hearing about REQQA to working inside an application.

This page explains how people get into REQQA, why the front door is shaped the way it is, and what each step does to the underlying data. If you simply want to invite a colleague who is already approved, see the how-to: Inviting your team.

Why invite-only​

REQQA is multi-tenant: every organisation's requirements, missions, stories, glossary, and analyses are scoped to that organisation, and members only ever see their own. The unit of tenancy — and, in time, of billing — is the organisation.

Uncontrolled registration would undermine this. Anyone could create an account that belonged to no organisation, see nothing useful, and leave behind an orphaned login with no membership. Worse, in a system designed around tenant isolation, an open front door is a standing invitation to abuse. Keeping registration invite-only means every account that exists is an account that was meant to exist, attached to an organisation that someone deliberately provisioned.

note

Access and credentials are separate concepts in REQQA. Creating a login (an auth_user row) grants nothing on its own. Access comes from organisation membership, recorded in the orgmembers table, and membership is only ever conferred by accepting an invitation. A login with no membership can see nothing.

For the trial period, onboarding stays manual: a person requests access, an administrator reviews the request, and approval provisions an organisation and sends an invitation. Billing is deliberately deferred — there is no payment engine yet. The approve step is the designed seam where billing will one day drop in, so the request-and-approve machinery is built to stay unchanged when that happens.

The four ways in​

There are four distinct paths, each serving a different kind of person:

PathWho it servesWhere it starts
Request accessA cold prospect with no contact inside REQQAThe public /requestAccess form
Admin-created organisationA new customer an administrator sets up directlyadminOrgCreate (system admin only)
Team inviteA colleague of someone already in an organisationteamInvite (any org member)
OAuth / SSO sign-inAn already-invited user signing in with Google, GitHub, or LinkedInThe login page provider buttons

The first three all converge on the same mechanism — an invitation that the recipient accepts to create their credentials and join an organisation. OAuth is an alternative way to authenticate an already-invited person, not a separate way to get in.

Path 1 — Requesting access (the public front door)​

A cold visitor who has no contact inside REQQA uses the public access-request form. The marketing calls to action on the site — the navbar and the landing page — all point at Request Access rather than any sign-up link.

The form lives at /requestAccess and asks for four things: Name, Email, Organisation, and a free-text Reason ("why you would like access"). It needs no account and no login; an already-authenticated user who lands there is quietly sent back to their application hub instead.

On submission, REQQA validates the fields (all four are required; the email must be a valid address; each field has a length limit) and, if they pass, writes a row to the info_requests table with a status of new. It then emails the REQQA host(s) so a human knows a request is waiting, and shows the requester a static confirmation page. That confirmation page deliberately shows none of the submitted data, so there is no information leak if the URL is shared.

note

The request record captures the submission for triage; it does not create any account or grant any access by itself. Nothing happens for the requester until an administrator acts on it.

Triage — what administrators do with requests​

System administrators review incoming requests on the Access Request List (accessRequestList). Requests are global rather than org-scoped, so this list is gated on the system-admin role — only the hardcoded administrator accounts can see it. The list shows every request newest-first, with counts per status and a status filter.

An administrator triages each request to one of four statuses:

  • new — the initial state, awaiting review.
  • approved — accepted; this transition provisions access (see below).
  • declined — not accepted.
  • spam — junk submission.

Every triage action stamps who handled it and when, and administrators can attach internal notes to a request.

What approval does​

Approving a request is the moment access is actually created. On the transition into approved, REQQA:

  1. Creates a new organisation for the requester (titled from the organisation they gave, with sensible AI defaults — the owner adds their own AI key later in AI Settings).
  2. Creates a first application in that organisation, seeding its mission from the standard mission guideline.
  3. Creates an invitation addressed to the requester and emails it to them.

The requester becomes the sole member — the de-facto owner — of that organisation when they accept the invitation. A new organisation is created per approval by design: to join an existing organisation, a person is invited by a colleague already in it (Path 3), not through the access-request path. The provisioning step is idempotent — if the requester already has a pending invite, no duplicate organisation is created.

tip

The status set is intentionally extensible. Future billing states (such as invited, subscribed, or lapsed) can be added without changing the request-capture form, the table, or the notification email — they slot in at the approve step.

Path 2 — Administrator-created organisations​

A system administrator can also set up a new customer directly, without waiting for a request. The Create Organisation form (adminOrgCreate) asks for the organisation name, a contact email, and a contact first name, plus optional AI configuration (an API key and a model). On submit it:

  • creates the organisation (encrypting the API key if one was supplied),
  • creates a first application with a seeded mission,
  • creates and emails an invitation to the contact.

Administrators manage all outstanding invitations across every organisation on the Manage Invitations page (adminInvites), where they can filter by status, resend a pending invitation's email, or revoke an invitation that should no longer be honoured.

Path 3 — Inviting a colleague​

Any member of an organisation can invite a colleague into that same organisation through Invite a Colleague (teamInvite). They supply the colleague's email and first name; REQQA refuses to invite someone who is already a member of the organisation, and caps pending invitations at 20 per organisation to keep things tidy.

A successful invite creates an invitation row, emails it (naming the inviter so the recipient recognises who asked them), and lists it among the organisation's pending invites — where the inviter can later resend or revoke it.

For the step-by-step version, see Inviting your team.

Accepting an invitation​

All three invitation paths end the same way. The recipient receives an email with a link to Accept Invite (acceptInvite/<token>), a public page that needs no prior login. REQQA validates the token and checks it has not expired — invitations are valid for 30 days from creation. A valid invitation shows the organisation name, who invited them (where known), and when the invitation expires.

From there the recipient creates credentials (or signs in, if they already have a login) and the invitation is matched to their profile, making them a member of the organisation.

note

/auth/register still exists — it is the only path that actually creates login credentials, used by new invitees from the accept-invite page — but every self-service route to it has been removed. Registration is access-less: making an auth_user grants nothing until an invitation binds it to an organisation.

OAuth and single sign-on​

REQQA supports signing in with Google, GitHub, and LinkedIn as an alternative to an email-and-password login. SSO is convenience for authentication, not a back door: the invite-only stance is enforced at the front of the OAuth flow. An uninvited person who signs in with a provider is rejected before any account is created — there is never even a brief orphan login for someone who was not invited. Account linking happens automatically by email match, so an invited user can sign in with a provider whose email matches their invitation without any extra linking step.

The principle throughout is the same one that shapes the public front door: email is the binding key, rejection is explicit rather than silent, and no domain is blanket-allowed.

Organisation members and roles​

Membership is recorded in the orgmembers table, which links a user to an organisation. Within an organisation, members share the same view of its requirements, missions, stories, glossary, and analyses, and any member can invite further colleagues into that organisation.

A separate, higher privilege exists: the system administrator. System admins are a small, fixed set of accounts (a hardcoded ID list in settings) — not a per-organisation role. They are the only people who can see the global access-request queue, create organisations directly, and manage invitations across all organisations. There is no self-service way to become a system administrator.

Where onboarding is heading​

Today, onboarding is a human reviewing requests and clicking approve. That keeps the front door discoverable for cold leads while preserving the invite-only stance, and it suits a trial with a small number of customers. The architecture is built so that when billing arrives — most likely a payment provider wired in at the approve step — approve becomes "create customer, start trial or subscription, send checkout, then invite." The form, the info_requests table, and the host notification will not need to change.