Signups¶
Platform-admin only: review beta access requests from the landing page, and approve them into live organizations.
Everything on this page requires the platform_admin role, a PulseTech-level role that sits above every individual organization. Ordinary org admins do not see any of it. Controls live under Platform → Signups in the sidebar, alongside Organizations.
Where requests come from¶
Anyone can fill in the beta interest form on the PulseLMS homepage without an account. Each submission records the applicant's name and email address, the organization, what kind of group it is, roughly how many people they need to train, the submitter's role, and any notes they left.
Everything except the notes is required; the form will not submit without it, and neither will the endpoint behind it. A request that arrived as an email address and nothing else could not be triaged without writing back to ask who sent it.
There is no self-service signup. A request is exactly that, a request, and nothing is provisioned until a person approves it.
Submitters get an acknowledgement email straight away so they are not left wondering whether the form worked.
One request per email address
If someone submits the form twice, the second submission updates their existing request rather than creating a duplicate. Someone who was previously waitlisted or declined and applies again returns to Pending so you see them afresh. An already-approved organization is left completely alone.
The queue¶
The Signups page opens on Pending, because the page exists to be emptied. The filter buttons across the top switch between Pending, Approved, Waitlisted, Declined, and All, each showing its count.
A number badge appears next to Signups in the sidebar whenever anything is waiting for a decision, so you do not have to remember to check.
Each request shows the organization, the applicant's name and email, when they applied, what they told you, and their notes. Requests made before the form asked for a name show the address alone. A red not on list tag means the mailing-list signup failed for that address and you will need to add it by hand.
Approving a request¶
Approving is the whole onboarding flow in one step. It creates the Keycloak organization, provisions its tenant at the edition you choose, and invites the applicant as its administrator.
Click Approve and confirm:
| Field | Notes |
|---|---|
| Organization name | Pre-filled with what the applicant typed. Edit it; people put all sorts of things in that box. |
| Alias | A permanent slug used in public URLs, auto-filled from the name. |
| First administrator | Defaults to the address that applied. They become org admin on first sign-in. |
| Edition | Enterprise or Community; seeds the organization's default feature set. |
| Internal note | For your records. Never shown or emailed to the applicant. |
Then click Approve & provision.
Check the alias before approving
It appears in public URLs. It can be changed afterwards from Organizations (old links keep working) but it is quicker to get right here, and the alias is the main reason approval is a confirmation dialog rather than a single click.
Two emails, on purpose¶
An approved applicant receives two separate emails:
- From PulseLMS: "you're in", explaining that their organization is set up and that a second email is coming.
- From PulseTech SSO: the actual invitation, carrying the link that lets them set a password.
The second one is the one that gets them in. The first exists so that the invitation does not arrive out of nowhere, which is exactly the kind of email people report as phishing.
If the welcome email fails to send, the confirmation says so explicitly; the organization is still provisioned, and you should tell the applicant directly.
If approval fails¶
If the alias is already taken, or Keycloak cannot be reached, the request stays Pending so you can fix the problem and try again. It is never left marked approved with no organization behind it.
Approving a request that has already been approved does nothing and re-sends nothing.
Waitlisting¶
Use Waitlist for a good fit at the wrong time. The request moves to Waitlisted and the applicant is emailed to say they are on the list for the next round. They stay on the mailing list.
Declining¶
Use Decline for requests you are not proceeding with. The request moves to Declined and no email is sent; a canned rejection reads worse than silence. Any note you add is internal.
If a declined applicant submits the form again later, they return to Pending.
Audit¶
Every approve, waitlist, and decline is recorded in your own audit log with the applicant's address and what was created. See Compliance → Audit log.