Self-Serve Sign-up & Billing

How customers sign up, pay and manage Starter and Pro plans themselves, the usage limits and lock, and what operators watch and switch on.

How Self-Serve Sign-up Works

Self-serve sign-up lets somebody arrive at the site, design an app, create an account, confirm their e-mail address and start a paid subscription, all without talking to anybody. Each sign-up becomes its own tenant with its own plan, and the person who signed up manages the subscription from the Admin Panel. This article explains the pieces and who does what; the rest of this section covers each one in detail.

Where to find it

Admin Panel → Account:

Billing & Plan — the account owner's plan, trial, usage, AI credit and payment actions

Admin Panel → AI:

AI Credit — the plan's included AI credit and top-ups
AI Builder — change the app by describing it

Architect Panel → Subscriptions:

Tenant Plans — one row per tenant: plan, status, trial and period dates, sign-up state

Architect Panel → Activity:

Usage Limit Notices — every usage warning sent to an account
API Calls per Day — each tenant's API calls counted against its daily allowance

Who it is for

Self-serve sign-up is how ActiveManage sells its own Starter and Pro plans. The plans, their limits and the payment set-up are part of the platform, not something you configure per installation or per tenant: there is no screen for creating your own plans or prices, and a tenant cannot offer self-serve sign-up to its own customers. Enterprise is arranged and invoiced directly and is never self-served.

So there are two audiences for this section. If you are the account owner of an app you signed up for, the articles on the sign-up journey, plans and limits, Billing & Plan, and payment problems are for you. If you run the installation, the articles on switching it on and on Tenant Plans and the sweep are for you.

The pieces

The sign-up wizard at the site's /onboarding/ address: seven questions that design the app, a plan choice, then account creation.
Registration and e-mail confirmation: the visitor creates a local account, with a reCAPTCHA check, and confirms their address from a one-time link before anything is built.
Checkout: a card is taken through Stripe, with a 14-day free trial for a first subscription. The first payment is taken when the trial ends.
The tenant: built from the design, with the sign-up's account as its first administrator, and opened as soon as Checkout completes.
Billing & Plan: where the owner changes plan, updates the card, cancels, resumes and buys AI credit.
Usage limits: editors, datastores, records, file storage and API calls, enforced as things are created.
The lock: an app whose subscription has ended or is unpaid is closed to everybody except the people who can fix it.
The sweep: a daily task that reminds, then removes, sign-ups that were built and never paid for.

The billing owner

The billing owner is the account that signed up. Only the billing owner can start Checkout, manage payment details, buy AI credit, resume a paused subscription or discard an unfinished sign-up. Other administrators of the app see "Ask the person who manages this account's subscription." ActiveManage staff see the billing screens read-only. Each billing owner gets one free trial in total, however many apps they create.

How it fits together

A visitor designs an app in the wizard and chooses Starter or Pro.
They create an account and confirm their e-mail address.
The app is built as a new tenant, recorded on Tenant Plans with sign-up state "building", then "built".
They pay through Stripe Checkout and return straight into the new app's Site Administration, already signed in.
Stripe keeps the plan's status up to date: trialing, active, past due, cancelled. Tenant Plans mirrors it, and access follows it.

Worked example

A volunteer co-ordinator finds the site, describes a volunteer rota app in the wizard and picks Starter. They register, click the link in the confirmation e-mail, and enter a card at Checkout. They land in their new app's Site Administration with a 14-day trial. Two months later their charity adds four more administrators; Starter includes one editor, so they upgrade to Pro from Manage billing on Billing & Plan, and the new administrators can be added.

Recommendations

Owners: keep the signing-up account; only it can manage billing.
Owners: read Plans and Usage Limits before inviting colleagues as administrators.
Operators: start in test mode and walk through a full sign-up before taking real payments.
Operators: enable the sweep once you have checked its preview.

Switching On Self-Serve Sign-up

Self-serve sign-up is switched on for a whole installation, and almost everything it needs is set in the server configuration and in Stripe rather than on a screen. This article is for whoever runs the installation: what has to be in place, the safety checks that refuse sign-ups when something is wrong, and how to test the whole journey before taking real money.

Where to find it

Architect Panel → Layout & Pages:

E-mail Templates — Self-serve: verify your e-mail and Self-serve: your app is waiting

Architect Panel → Integration & Connections:

E-mail Accounts — the account the confirmation and reminder e-mails are sent from

Architect Panel → Subscriptions:

Tenant Plans — check each test sign-up's plan row

Architect Panel → Activity:

Error Log — why a sign-up was refused, when the reason is a configuration problem

What the hosting administrator sets

The self-serve switch. Turning it on also forces open registration and requires the reCAPTCHA check on the registration form.
reCAPTCHA keys (version 2, a site key and a secret key). With the check required and either key missing, registration is refused rather than left unprotected.
The address of a load balancer, if there is one, as a trusted proxy range. Otherwise every visitor appears to come from the balancer and the per-address sign-up limits become one shared limit.
The Stripe mode (test or live), the secret key, the webhook signing secret and the Stripe account ID the key belongs to. With self-serve on and the account ID empty, every Checkout, top-up and Manage billing request answers that payments are not set up, so a key from the wrong Stripe account can never take money.
The Stripe catalogue and Customer Portal. In test mode a bootstrap script creates the Starter and Pro prices, the AI top-up packs and a Customer Portal configuration that allows card updates, invoice history, cancellation at period end and switching between Starter and Pro only. In live mode they are created by hand to match. The Portal configuration's ID must then be set; without it Manage billing cannot open.
The webhook endpoint in the Stripe dashboard: https://your-site/ajax/subscription-webhook.php?tenantID=0, with these events: checkout.session.completed, checkout.session.async_payment_succeeded, customer.subscription.created, .updated, .deleted, .paused and .resumed, invoice.paid, invoice.payment_failed, charge.refunded, and charge.dispute.created, .updated, .funds_withdrawn and .closed.
The sending e-mail account for confirmation e-mails, if it should differ from the password reset account.

Safety checks that refuse registration

A self-registered account must start with no administration rights anywhere. Registration is therefore refused, with "Registration isn't available right now. Please try again later." shown to the visitor and the reason in the Error Log, when:

any group new registrations are placed in by default has admin access;
new users are set to be linked to a tenant automatically;
reCAPTCHA is required and a key is missing;
the platform's rate-limit table is missing.

Registration from one address is also limited to 10 accounts an hour, and confirmation e-mails to 5 an hour per account.

Testing the whole journey

With Stripe in test mode, open the site's /onboarding/ address in a private browser window and complete the wizard.
Register a new account, open the confirmation e-mail and confirm.
Create the app and pay with one of Stripe's test cards.
Check you land in the new app's Site Administration, and that Billing & Plan shows the trial and its end date.
Open Tenant Plans and confirm the new row: Self-serve on, Status trialing, Sign-up state done.
In the Stripe dashboard, check the webhook deliveries succeeded.
Try Manage billing, switch plan in the Portal, and confirm the change reaches Billing & Plan.

What goes wrong

"Self-service sign-up is not enabled on this site." in the wizard: the switch is off.
"Registration isn't available right now.": one of the safety checks above. The Error Log names it.
"Payments are not set up yet." at Checkout: the Stripe account ID or key is missing.
"Payments aren't set up correctly on this site. Please contact support.": the Stripe key belongs to a different account from the account ID set.
"Billing management is not set up yet." when the owner clicks Manage billing: the Customer Portal configuration ID is not set.
Plans never change from incomplete: webhooks are not arriving. Check the endpoint address ends in ?tenantID=0; self-serve events are ignored on any other endpoint.

Worked example

An operator sets the switch, the reCAPTCHA keys and Stripe test credentials, runs the bootstrap and registers the webhook. The first test registration is refused. The Error Log shows the default registration group has admin access, a leftover from an older set-up. Once that group's admin access is removed, a full test sign-up succeeds, Tenant Plans shows the row as trialing, and the operator repeats the checks before switching Stripe to live.

Recommendations

Complete a full test sign-up in Stripe test mode before going live.
Never let default registration groups carry admin access.
Set the trusted proxy range behind a load balancer.
Watch the webhook deliveries in Stripe for the first days after launch.
Check the two e-mail templates read well for your audience.

The Sign-up Journey

This article follows a new customer from the first page of the sign-up wizard to their first sign-in to the app they designed, with every message they may meet on the way. Use it to support people who get stuck, and to know what each step leaves behind on the installation.

Where to find it

The journey starts at the site's /onboarding/ address. Adding ?plan=starter or ?plan=pro preselects a plan.

Architect Panel → Subscriptions:

Tenant Plans — the sign-up's plan row, its Sign-up state and Sign-up started date

Architect Panel → Activity:

E-mail Log — whether the confirmation e-mail was sent

Admin Panel → Account:

Billing & Plan — where the new owner lands after paying

1. Designing the app

The wizard opens with "Let's build your first app." and asks seven quick questions: what they want to build, the data it holds, how people will sign in, who does what, a few automations, and a name, company name, accent colour and logo. The last step is Choose your plan, with Starter and Pro cards showing the editors and monthly AI credit each includes and a note that the 14-day free trial needs a card, with the first payment on day 15. A review page then offers Create my app and start trial (or Create my app and subscribe if this person has already had a trial).

2. Creating the account

Somebody not signed in is taken to the sign-in page, and their design is kept in the browser. Entering an address the site does not know shows a registration form: "Looks like you're new here - welcome!" They complete it, tick the reCAPTCHA box and click Create Account. They are signed in at once and returned to the wizard. Self-serve sign-up needs an e-mail-and-password account: "Please sign up with an e-mail address and password to create an app."

3. Confirming the e-mail address

A one-time link is e-mailed from the Self-serve: verify your e-mail template. The wizard shows "Confirm your e-mail address." with I've confirmed it and Send the link again. The link:

opens a page with a Confirm my e-mail address button; opening the link alone changes nothing, so mail scanners cannot use it up;
works once, for 24 hours, and a resent link replaces the earlier one;
can be resent up to 5 times an hour.

Confirming shows "E-mail confirmed" and a Continue button back to the wizard. A confirmation applies to the current address; changing the address needs a new one.

4. Building and paying

The app is built as a new tenant, with the person as its first administrator. The wizard then says "Taking you to secure payment..." and hands over to Stripe Checkout, where a card is taken. Nothing is charged until day 15 of a trial. On success the person lands in the new app's Site Administration, already signed in. If Checkout is cancelled, they return to the wizard and nothing is charged.

If they leave and come back before paying, the wizard shows "Waiting for payment" with Continue to payment and Start again. Start again discards the unfinished app ("Clearing it away...").

Messages people may meet

"Too many accounts have been created from your network recently. Please try again later.": more than 10 registrations an hour from one address.
"Please tick "I'm not a robot" before creating your account." or "The "I'm not a robot" check could not be verified.": the reCAPTCHA step.
"You're already signed in. Sign out first to create a different account."
"Registration isn't available right now. Please try again later.": a configuration problem on the installation; see Switching On Self-Serve Sign-up.
"This link has expired. Sign in and ask for a new one." or "This link has already been used." on the confirmation page.
"Please confirm your e-mail address first - we sent you a link." at Create my app.
"You have created several apps already today. Please try again tomorrow, or finish one you have started.": five a day per person.
"Your app is already being built. Give it a minute, then reload this page."

Supporting someone who is stuck

Ask which message they see, and match it to the list above.
For a confirmation e-mail that never arrived, check the E-mail Log, then ask them to use Send the link again and check their junk folder.
For a payment question, find their tenant on Tenant Plans: Sign-up state shows building, built, failed, done or discarded, and Status shows Stripe's view.
If they paid but see a page titled "Payment received" or "Nearly there" instead of their app, check Tenant Plans. Once Status reads trialing or active, signing in again takes them into the app.

Worked example

A customer emails to say they never received the confirmation link. The administrator finds the send in the E-mail Log, delivered two hours earlier, and suggests the junk folder. They find it there but the link has since been replaced because they clicked Send the link again twice; the newest e-mail's link works and they continue to payment.

Recommendations

Tell people to use the newest e-mail; each resend replaces the earlier link.
Use Tenant Plans' Sign-up state to see where somebody stopped.
Use the plan links (?plan=pro) from your pricing pages.
Do not create accounts for customers; the account that signs up is the billing owner.

Plans and Usage Limits

Every self-serve app is on Starter or Pro, and each plan sets how big the app may grow: how many editors, datastores, records, how much file storage and how many API calls a day. Limits are checked when something new is created, never by deleting what is already there. This article lists them, explains what counts, and says what people see when a limit is reached.

Where to find it

Admin Panel → Account:

Billing & Plan — editors in use, and the Usage card with records, files and API calls against the plan

Architect Panel → Activity:

Usage Limit Notices — every 80% and 100% warning sent
API Calls per Day — calls counted per tenant per day

Architect Panel → Subscriptions:

Tenant Plans — the last counted records and storage for each tenant

The limits

Starter: 1 editor, 40 datastores, 50,000 records, 5 GB of file storage, 10,000 API calls a day.
Pro: 10 editors, 200 datastores, 1,000,000 records, 50 GB of file storage, 100,000 API calls a day.
Enterprise: no limits; arranged directly.

Each plan also includes a monthly AI credit; see AI Builder & Large Uploads for AI in self-serve apps.

What counts

An editor is a distinct person who is linked to the app as a tenant user, or who is in one of the app's groups with admin access. People in groups without admin access are free, however many there are. ActiveManage staff never count.
A datastore is one you have created; the platform's own built-in datastores do not count.
Records are counted across the app. Only adding new records is refused at the limit; existing records can still be viewed, edited and deleted.
File storage counts the files uploaded. At the limit new uploads are refused; existing files can still be opened and deleted. A single file bigger than the space left is refused on its own.
API calls count REST, MCP and A2A requests on the UK calendar day. Over the allowance, further calls are refused until midnight UK time.

What people see at a limit

Adding an editor: "Your Starter plan includes 1 editor and 1 is in use. Upgrade, or remove administrator access from someone first."
Creating a datastore: "Your Starter plan allows 40 datastores and this app already has 40. Upgrade to Pro, or delete a datastore you no longer need." The new datastore is not kept.
Adding a record or uploading a file at the limit: a message saying what is full, that existing items can still be used, and how to make room.
An API call over the allowance: a refusal saying when the allowance resets.

Warnings before the limit

For records and file storage, the app's administrators get an e-mail at 80% ("You've used 80% of your records") and at 100% ("Your app has reached its records limit"), and ActiveManage is told too. Each warning is sent once and re-arms when usage falls back below 75%. From 80%, Billing & Plan also shows a sentence under that line of the Usage card. Editors, datastores and API calls have no advance warning e-mail.

After a downgrade

A downgrade from Pro to Starter takes effect at the end of the paid period. An app that is still bigger than Starter at that point keeps everything, but:

the editors beyond the plan's allowance, newest first and never the billing owner, lose Site Administration (they can still use the app);
no new datastores, records or uploads can be added.

Billing & Plan explains this in a banner ending "Nothing has been deleted." It lifts as soon as the owner upgrades again or trims the app to fit. Starting a subscription on a plan smaller than the app is refused, with a message listing what is over the limit and "Choose Pro, or remove some first."

Freeing room

Open Billing & Plan and read which limit is reached.
For editors, remove admin access from somebody who does not need it, or move them to a group without admin access.
For records or storage, delete what is no longer needed, or upgrade with Manage billing.
Reload Billing & Plan and check the figures.

Worked example

A Starter app's owner invites a colleague as a second administrator and is refused with the editor message. They put the colleague in a group without admin access instead, which does not count as an editor, so the colleague can use the app but not Site Administration. Six months later records reach 80% and both administrators get the warning e-mail; they upgrade to Pro before the limit is reached.

Recommendations

Give admin access sparingly; ordinary users do not count as editors.
Act on the 80% e-mail rather than waiting for the limit.
Trim before downgrading, so nobody loses Site Administration.
Watch API calls if an integration polls the app frequently.

Billing & Plan

Billing & Plan is the account owner's screen for a self-serve app. It shows the plan, the trial or renewal date, how many editors are in use, usage against the plan's limits and the AI credit, and it holds the buttons that change the subscription. It stays open even when the app is locked, so the owner can always put things right.

Where to find it

Admin Panel → Account:

Billing & Plan — plan, dates, editors, usage, AI credit and payment actions

Admin Panel → AI:

AI Credit — what has used the AI credit, and top-ups

What the screen shows

The plan card: Plan, Status, Trial ends, Period Ends and Cancels at period end, then a line such as "Trial ends 16 October 2026" with the first payment date, "Renews on" a date, or "Cancels on" a date. Below that, "Editors: 1 of 1", or a warning if the app has more editors than the plan includes.
Usage: "Records", "Files" and "API calls today", each as used against the limit. A sentence appears under any line at 80% or more.
AI credit: how much of this period's credit is used and when it resets, the top-up balance, and any weekly figure.
Banners at the top when something needs attention: the subscription is not active, the last payment failed, the app is bigger than its plan, or a trial ended early because the card had already had a trial.

The buttons, for the billing owner

Manage billing opens the Stripe Customer Portal, where the owner changes between Starter and Pro, updates the card, sees invoices and cancels. It reads Update payment details when a payment has failed.
Buy credit buttons, one per AI top-up pack, take a one-off card payment through Stripe. The credit is added when the payment clears, and the screen confirms it: "Thank you - your AI credit top-up has been added."
When the app is locked, the buttons change to whatever will reopen it: Start your 14-day trial, Complete checkout, Complete payment, Resubscribe to Starter or Pro, Update payment details, or Resume subscription. See Locked Apps and Payment Problems.
With nothing to do, it says "There is nothing to change here right now."

Other administrators see the same figures with "Ask the person who manages this account's subscription." in place of the buttons. ActiveManage staff see "Staff view: billing actions belong to the account's owner."

Changing plan

Open Billing & Plan and click Manage billing.
In the Stripe Customer Portal, choose the other plan and confirm.
An upgrade is charged straight away, prorated, and its limits apply at once.
A downgrade takes effect at the end of the paid period. Before then, trim the app to fit the smaller plan; see Plans and Usage Limits.
Return to Billing & Plan and check the plan card.

Cancelling

Cancel in the Customer Portal from Manage billing. Cancellation takes effect at the end of the paid period; until then the plan card shows "Cancels on" that date and the app works normally. After it, the app locks and the owner can resubscribe at any time from Billing & Plan.

What goes wrong

"Only the person who manages this account's subscription can do that.": you are not the billing owner. Ask them, or ActiveManage if they have left.
"This account already has a subscription. Change it with Manage billing.": use the Portal to change plan rather than starting a new subscription.
"Checkout isn't finished yet. If you have just paid, it can take a minute to show here.": wait a minute and reload.
"Your top-up payment is being confirmed.": the credit appears when the payment clears.

Worked example

An owner on Starter needs three more administrators. On Billing & Plan the plan card shows "Editors: 1 of 1". They click Manage billing, switch to Pro in the Portal and return. The card now reads Pro with "Editors: 1 of 10", the prorated charge appears in their invoices, and their colleagues can be given admin access.

Recommendations

Check the plan card's dates before a trial ends.
Keep the card in the Portal up to date; a failed renewal locks the app.
Plan downgrades ahead by trimming editors and data first.
Tell colleagues who the billing owner is, so they know whom to ask.

Locked Apps and Payment Problems

A self-serve app is open while its subscription is in its trial or paid up, and locked when it is not. A locked app keeps all its data; it simply cannot be used until the billing owner puts the subscription right. This article explains which statuses lock an app, what each kind of person sees, and how the owner reopens it.

Where to find it

Admin Panel → Account:

Billing & Plan — the reason for the lock and the button that fixes it; reachable even while locked

Architect Panel → Subscriptions:

Tenant Plans — Status, Past due since, Trial ends and Last synced for the tenant

Which statuses keep an app open

Status is Stripe's own subscription status, mirrored on Tenant Plans.

trialing and active: open. If an expected renewal or trial-end message from Stripe is late, the app stays open for up to 72 hours past the date while the platform rechecks with Stripe, at most every 15 minutes.
past_due: locked straight away as shipped. Your hosting administrator can allow a grace period of some days instead.
incomplete, incomplete_expired, unpaid, canceled and paused: locked.

While locked, the app cannot use AI. ActiveManage staff are never locked out.

What each person sees

The app's users see "This app is temporarily unavailable." and "Please contact its administrator.", with a Log off button.
Administrators opening any Site Administration screen are taken to Billing & Plan, with a red banner "This account's subscription is not active." and the reason. Only the billing owner gets buttons; others are told to ask them.

The reasons, and how the owner fixes each

"Your app is ready. Start your subscription to open it.": Checkout was never finished. Click Start your 14-day trial (or Complete checkout if a trial has already been used).
"The first payment hasn't completed yet.": click Complete payment.
"The last payment didn't go through. Update the payment details to open the app again.": click Update payment details and change the card in the Portal. Stripe retries the payment and the app reopens when it succeeds.
"The subscription has ended. Resubscribe to open the app again." or "Checkout wasn't completed in time.": click Resubscribe for Starter or Pro.
"The subscription is paused.": click Resume subscription.
"We couldn't confirm this subscription with our payment provider.": a date has passed and Stripe could not be reached to confirm. Check payment details, or try again in a few minutes.

Trials and the card rule

Each billing owner gets one free trial, and so does each card. If a new subscription is started with a card that has already had a free trial on another account, the trial ends at once and the first month is charged that day. The page after Checkout and Billing & Plan both explain this, starting "This card has already been used for a free trial on another ActiveManage account". If that first payment fails, the app locks with the payment-failed reason above. Tenant Plans records it in Trial ended early because and Trial ended early on.

Refunds and disputes

A refunded or disputed AI top-up removes that credit. Credit already spent becomes an amount owed, taken off the next period's AI allowance, and Billing & Plan says so.

What goes wrong

The owner has fixed the card but the app is still locked. Stripe retries the payment on its own schedule; the app opens when the payment succeeds. Last synced on Tenant Plans shows when the platform last heard from Stripe.
The owner has left the organisation. Only the billing owner can act. Contact ActiveManage to transfer ownership.
"Only the person who manages this account's subscription can do that.": somebody other than the billing owner pressed a button.

Worked example

A charity's card expires and the renewal fails. Staff using the app see "This app is temporarily unavailable." The treasurer, who signed up, opens Site Administration and lands on Billing & Plan with "The last payment didn't go through." They click Update payment details, enter the new card in the Portal, and once Stripe's retry succeeds the app reopens with nothing lost.

Recommendations

Owners: keep card details current; a failed payment locks the app immediately as shipped.
Owners: tell your users who to contact if they ever see the unavailable page.
Operators: decide on a past-due grace period deliberately with your hosting administrator.
Use Tenant Plans to confirm what Stripe last reported before advising a customer.

Tenant Plans and the Sign-up Sweep

Three screens let whoever runs the installation see what self-serve customers are doing: Tenant Plans shows each tenant's subscription, Usage Limit Notices shows every usage warning sent, and API Calls per Day shows each tenant's API use. A daily task, the sign-up sweep, reminds and then removes apps that were built and never paid for. This article is for operators, not account owners.

Where to find it

Architect Panel → Subscriptions:

Tenant Plans — one row per tenant; changes are audited, so it doubles as subscription history

Architect Panel → Activity:

Usage Limit Notices — 80% and 100% warnings, who they went to and whether they were sent
API Calls per Day — calls counted per tenant per UK day

Architect Panel → Automation:

Tasks — Self-serve - Abandoned Sign-up Sweep, with its Preview, Task Log and Force Run row actions

Reading Tenant Plans

Plan: starter, pro or enterprise. A code the platform does not recognise is treated as Starter, so a typo here quietly downgrades a customer.
Status: Stripe's subscription status. For self-serve tenants only trialing, active, and past_due within any grace period give access.
Self-serve: on for tenants created by sign-up. Bespoke tenants are off and are never locked by these rules.
Sign-up state: building, built, failed, done or discarded, and purged once the sweep has removed it. Sign-up started is when the build began.
Trial ends, Period starts, Period Ends, Cancels at period end, Past due since and Last synced: the dates behind the lock and the plan card.
Trial used, Trial ended early because and Trial ended early on: the trial rules.
Records (last count), Storage at last count (bytes) and Usage counted: the latest usage figures.
AI credit per period (pence) and AI weekly cap (pence): per-tenant overrides of the plan's AI allowance.
Reminder sent, Deleted and Sweep note: what the sweep has done.

Stripe identifiers and the billing owner's identity are kept on the row but hidden. Change plans through Stripe, not by editing the row; the next message from Stripe would overwrite a hand edit.

The abandoned sign-up sweep

The sweep only touches sign-ups that were never paid: no subscription, no trial used, and no paid history. Ages count from Sign-up started.

Day 7: one reminder e-mail to the person who signed up, from the Self-serve: your app is waiting template, recorded in Reminder sent. Discarded sign-ups get no reminder.
Day 30, and never sooner than 7 days after the reminder: the tenant and its own datastores and files are deleted. Any open Stripe Checkout is closed first; one that turns out to have been paid is applied instead. The Tenant Plans row and the audit trail are kept, with Sign-up state purged. The person's account is not touched.
Anything that fails a safety check is held for a person rather than deleted, and noted in Sweep note and the Error Log.

At most 5 deletions and 50 reminders happen in one run. The day counts and these caps are set by your hosting administrator; deletion can never be set sooner than 14 days.

Switching the sweep on

Open Tasks and find Self-serve - Abandoned Sign-up Sweep. It ships disabled and in preview mode, and runs daily once enabled.
Use Preview. The summary lists how many reminders are due, how many tenants would be deleted, how many are waiting and how many are held for a person.
Check the reminder template in E-mail Templates.
Enable the task. While preview mode is still on, each run's Task Log entry begins "PREVIEW MODE - nothing was changed", so you can watch a few runs safely.
Switch preview mode off to let it act.

Usage Limit Notices and API Calls per Day

Each row on Usage Limit Notices records when a warning was sent, which limit and threshold, the usage and limit at the time, the plan, who it went to and whether it was sent. Use it to answer "did we warn them?" before a customer hits a limit. API Calls per Day shows each tenant's count for each UK day and when its last call arrived, which explains a customer's report that their integration stopped working mid-afternoon.

What goes wrong

Unpaid sign-ups are piling up. The sweep is still disabled or in preview mode.
A tenant is "held for a person". Read Sweep note and the Error Log, then decide by hand.
A customer was not warned. Check Usage Limit Notices; editors, datastores and API calls have no warning e-mail.

Worked example

An operator notices 40 tenants on Tenant Plans with Sign-up state built and Status incomplete, some months old. A Preview of the sweep shows 12 reminders due and 28 to delete. After checking the reminder template, the operator enables the task in preview mode for a week, reads the Task Log, then switches preview off. Within six runs the backlog is cleared, five at a time, with each removal recorded as purged.

Recommendations

Read the Preview before enabling the sweep.
Change plans in Stripe, not on Tenant Plans.
Check Usage Limit Notices before answering a limit complaint.
Look at held tenants promptly; the sweep will not decide them for you.