Skip to main content

How to invite your team and handle access requests

When you'd do this: when you want a colleague to work alongside you in your organisation, or when someone outside your organisation has asked to use REQQA and you need to let them in.

REQQA is invite-only. There is no open sign-up page: creating a login on its own grants nothing, because access in REQQA comes from membership of an organisation, and only an invitation confers that. This keeps each organisation's requirements, releases, and analyses cleanly separated from everyone else's.

That gives you two ways to bring people in, depending on who they are:

  1. You invite a colleague into your own organisation — they join the org you already work in and see the same applications and requirements.
  2. A prospective user requests access through the public Request Access form, and an administrator decides whether to let them in.

This page walks through both.

note

Invitations and access requests are about who can sign in and which organisation they belong to. They do not, by themselves, decide what each person can change inside that organisation — see Access and onboarding for the wider model.

Path 1 — Invite a colleague into your organisation​

Use this when the person should join the same organisation as you, working on the same applications.

Send the invitation​

  1. Open the Invite Team page (teamInvite).
  2. Enter the colleague's email and first name.
  3. Click to send.

REQQA creates a pending invitation, generates a unique secure token, and emails your colleague a personalised invite — the message names you as the inviter and the organisation they're being invited to. The link in the email points at REQQA's Accept Invite page.

A few rules apply as you do this:

  • You can't invite someone who is already a member of your organisation — REQQA tells you if they are.
  • You can't create a second pending invitation for the same email address in the same organisation while the first is still outstanding.
  • An organisation may hold at most 20 pending invitations at once. If you hit the limit, revoke some old ones before sending more.

Manage what you've sent​

The same Invite Team page lists your organisation's pending invitations, newest first. From there you can:

  • Resend an invitation — useful if the email went astray. You can't resend one that has already expired.
  • Revoke an invitation — cancels it so the link no longer works.

Invitations expire after 30 days. An expired or revoked link can't be used to join.

tip

If a colleague says the link doesn't work, check the pending list first. An expired invite needs a fresh one (it can't be resent); a revoked one needs re-creating.

What your colleague does​

When your colleague opens the Accept Invite link (acceptInvite/<token>):

  • REQQA validates the token. If it's invalid, already used, or expired, they see a clear message rather than a dead end — for an expired link, they're told to ask you for a new one.
  • For a valid invite, the page greets them, naming the organisation and who invited them.
  • If they're new to REQQA, they create their account and verify their email; on first sign-in REQQA matches the stored invite and connects them to your organisation automatically.
  • If they already have a REQQA account, they simply log in and are connected to the organisation — no extra steps.

The end result is the same: an orgmembers link binds their user to your organisation, and the invitation is marked accepted.

Path 2 — Handle a request from someone outside your organisation​

People who don't yet have an invite reach REQQA through the public Request Access form. This is the front door for cold leads and trial prospects, and it's the path the marketing site's calls-to-action point at.

What the requester sees​

On the public Request Access page (requestAccess) — no account or login needed — they provide:

  • Name
  • Email address
  • Organisation
  • Reason / use case — why they'd like access

REQQA validates the submission (required fields, a valid email format, sensible length limits), stores it, and shows a neutral confirmation page. An email notification goes to the REQQA host so someone knows a request is waiting. The requester is told nothing about their request's eventual fate from the confirmation page — that's by design, so a shared confirmation URL leaks no detail.

note

Already-signed-in users who land on the request form are sent straight to their application hub — there's no reason for an existing member to request access.

Triage requests as an administrator​

Requests are reviewed by a system administrator on the Access Request List (accessRequestList):

  • Requests are listed newest first, with counts per status so you can see the backlog at a glance.
  • You can filter by status to focus on what's outstanding.

Every request moves through a simple status model:

StatusMeaning
newJust submitted, awaiting triage
approvedAccepted — access is being provisioned
declinedNot accepted
spamJunk submission

For each request you can record admin notes and apply a status. REQQA stamps who handled it and when, so there's an audit trail.

What "approve" does​

Approving a request is the moment access is granted. When you move a request from new to approved, REQQA:

  1. Creates a new organisation for the requester — named from the organisation they gave (or a sensible fallback).
  2. Seeds that organisation's first application with the standard mission guideline, ready to edit.
  3. Emails the requester an invitation to that new organisation. On acceptance they become its first member — effectively its owner.

This deliberately gives each approved requester their own organisation. To join an existing organisation, a person should be invited by a colleague already in it (Path 1 above), not routed through access requests.

The approve step is idempotent: if the requester already has a pending invitation, REQQA skips creating a duplicate organisation. If the invitation email can't be sent, the organisation is still created and you're told to resend the invite from the invitations list.

caution

A brand-new organisation starts with no AI key configured. The new owner adds their own key in AI Settings before running any analysis. See AI models and cost.

A note on sign-in options​

However someone arrives, they sign in to REQQA with an email-and-password account they verify by email. REQQA also supports single sign-on via OAuth providers (such as Google and GitHub) where configured — but the invite-only rule still holds: an SSO sign-in only works for someone who has been invited or approved. Signing in with a provider never creates access on its own. See Why invite-only? for the reasoning.

Result​

  • Colleagues you invite land in your organisation and can start working on the same applications immediately.
  • Outside requests collect on the Access Request List, where approving one spins up a fresh organisation and invites the requester into it.
  • Every invitation can be tracked, resent, or revoked, and every access request carries a record of who triaged it and when.