Run a waitlist

Collect interest before you open sign-up, then let people in when you are ready: one at a time, everyone still waiting at once, or by opening sign-up and telling the list. The queue is under Waitlist in the Directory group of your tenant's dashboard; the matching management API operations are listed at the end for reference. Reading the queue needs the View users permission. Acting on it from the Waitlist page, including emailing the list, needs Manage users. Changing the sign-up mode, and emailing the list from the settings form, needs Manage tenant settings. Admin and Owner carry both; Support carries neither.

This guide concerns users of your application. To invite someone to administer the identity dashboard, use team access.

Choose a sign-up mode

In Settings → General → Self-serve sign-up, choose the admission policy for new accounts and select Save settings.

Existing users can still sign in under any mode. Your enabled sign-in methods remain a separate decision: an invitation does not enable a disabled password method or configure a social provider.

Start collecting

1. Open Settings → General → Self-serve sign-up, choose Waitlisted, and choose Save settings.

2. Send people to https://{tenantId}.udibo.com/waitlist, the join page on your tenant's own host.

While the tenant is waitlisted, the sign-up page refuses new accounts as a closed tenant does, and existing users sign in as usual. The join form asks for an email address and your sign-up fields. With bot protection on, it shows the challenge. A person can also join with a connected social provider, when the provider asserts their email as verified; see how an account is matched.

Joining sends a confirmation email. The page answers the same way whether the address is new, already on the list, or already has an account, so it reveals nothing about who has signed up. Joining again with the same address updates any answers given and sends no second email.

People take themselves off the list from the same page. They enter their address, receive a removal link valid for 24 hours, and confirm. Confirming erases the entry the same way Remove does.

Read the queue

Each row shows the Email, the Source (Form, or the social provider they joined with), the Status, the date they Joined, and their Answers: choose View to read what they submitted. Rows load 20 at a time as you scroll. Filter by Status:

Each decision is recorded in the audit log.

Approve and re-invite

Approve emails the person an invitation bound to their address. It works once and lasts 14 days. The link opens your tenant's create-account page with the address filled in and locked. Creating the account uses up the invitation and marks the address verified, because receiving the link proved the person reads that mailbox. They can accept with a social provider button instead, when the provider asserts a verified email equal to the invited address. Your sign-in method settings still apply: with password sign-up turned off, only the provider buttons appear. Invitations work only while sign-up is waitlisted or closed; see limits today for what a link does while sign-up is open.

An organization invitation offers membership, not admission to sign-up. For a new person under Closed or Waitlisted registration, admit them through the waitlist first.

Re-invite sends a fresh link to an invited or expired entry, and the previous link stops working. Approve and re-invite share a budget of five invitations per entry per hour.

Approve all pending (N), at the top of the page, queues invitations for pending entries after you confirm the count. It skips an entry that changed state or reached its hourly invitation limit. Review the reported approval count before assuming every pending entry was invited. Each invited person gets their own email, and a sent email cannot be unsent; deny an entry to make its link stop working.

The page reports an invitation as queued, because sending happens after the page answers. A send the email provider rejects is recorded in the audit log as email.delivery_failed.

Deny or remove

Deny withdraws a request silently. The person is not told, and any invitation they hold stops working. A denied entry no longer counts as pending, so Approve all pending passes over it. Choosing Approve on a denied entry clears the denial and sends an invitation; it does not return the entry to pending. An accepted entry cannot be denied.

Remove erases the entry. You confirm by retyping the address. The address and answers are cleared rather than archived, so the person must join again to come back. Removing an invited entry also stops its invitation from working. Removing a denied entry lifts the denial, so the person can join again as a new pending entry; leave the entry denied to keep them out. Removing an accepted entry does not affect the account they created: to stop them signing in, suspend the account from their user page.

Open sign-up and tell the list

When you are ready to let everyone in, change Self-serve sign-up from Waitlisted to Open. While pending people who have never been told are on the list, the settings form offers Email the N people still waiting that sign-up is open. Select it, then choose Save settings. The email links to your create-account page, where no invitation is needed.

If you opened without selecting it, the Waitlist page offers the same broadcast as Email the N still waiting. It appears while sign-up is open and someone pending has not been told.

The broadcast selects each entry once. It goes only to entries that are pending and have never been selected for this notice, so invited, expired, denied, accepted and removed entries get nothing. Saving again or switching modes later does not select an entry again, even if its earlier email failed. It is refused unless sign-up is open. Whenever sign-up is not waitlisted, the Waitlist page shows how many entries were told and when, and how the last broadcast's delivery went; reload the page to see delivery settle.

Changing the mode keeps the list

Changing the sign-up mode never clears the list. Open stops the gate and keeps every entry, but invitation links stop admitting anyone as invited; see limits today. Choosing Waitlisted again resumes where you left off. Closed turns the join form off, but outstanding invitations still work, and Approve and Re-invite still send them; deny an entry to withdraw its invitation. In every mode, people can still ask to be removed.

Waitlist email

The confirmation, removal, invitation and "now open" emails name the display name from your branding, and their buttons use its accent color. They go out through your own sender when you have one, or Udibo's otherwise. They count toward your email usage and stop at an email hard limit set on the Billing page. Addresses that bounced or reported your mail are skipped. See sending email from your domain.

How long entries are kept

An entry is deleted 90 days after the most recent of these that has happened to it: it was accepted, it was denied, or it was told sign-up is open. An active invitation keeps the entry until the later of that 90-day deadline or the invitation’s expiry. Sending an invitation does not restart the 90-day clock. An entry none of those events has happened to stays until you or the person removes it. Cleanup runs daily, deleting entries whose deadline has passed.

Check the journey before inviting users

1. Join your tenant's waitlist with a test address while registration is Waitlisted, and confirm its Pending row and collected answers.

2. Approve it, receive the email, and create the account using its link. Confirm that the row becomes Accepted and that another use of the link cannot admit a second account.

3. On a different test entry, re-invite and check that only the latest link works. Deny it and check that its outstanding link no longer admits anyone.

4. Test the sign-in methods and MFA policy you intend to offer; waitlist admission does not replace those controls.

Continue with the production checklist before opening access.

Management API reference

These operations are dashboard-only today; see choose the right API. Paths are under https://www.udibo.com/api/identity/{tenantId}:

The list takes status with the values pending, invited, expired, accepted and denied; an unknown value is refused with a 400. invite-all returns {"invited": n} and notify-open returns {"notified": n}. notify-open answers 409 unless sign-up is open, and an action the entry's status does not allow, such as approving an invited entry, answers 409 too. Denying an entry that is already denied succeeds and changes nothing. The invitation budget answers 429. The invitation link travels only in the email; no response carries it. The full reference is in the API reference.

Limits today

• Answers given on the join form stay on the waitlist entry. They are not copied to the account an invitation creates, and an invited person is not asked your sign-up fields again.

• Invitations last 14 days, and the period cannot be changed. Waitlist email content cannot be customized, and a denied person is never told.

• The join form accepts 20 submissions per network address per hour. Removal requests are limited to 10 per network address per hour, and one address receives at most three removal links an hour.

• The page reports invitations as queued, not delivered. Failed deliveries appear in the audit log; only the "now open" broadcast reports a delivered count on the page.

• While sign-up is open, an invitation link opens the ordinary create-account page: the address is not filled in, and the entry is not marked accepted when the person signs up.

• An entry that was told sign-up is open is eligible for deletion 90 days later, or when its active invitation expires, whichever is later.

• Someone with View users but not Manage users still sees the action buttons; their actions are refused.

Next: manage users, choose sign-in methods, or watch your email usage.

Last verified 2026-10-03.