Understanding tenants

What a tenant is, in plain English

In Booknetic SaaS, a tenant is a single business that uses your SaaS platform. Each tenant runs its own booking operation inside Booknetic, with its own customers, appointments, services, staff, and locations — all kept separate from every other tenant on your platform.

If you sell Booknetic SaaS to salons, clinics, trainers, or agencies, each business that signs up onto your platform becomes one tenant. From the moment a tenant is created, they get:

• their own login (one tenant, one primary admin account);
• their own booking URL that they share with their customers — for example, your-platform.com/aurora-wellness/;
• their own booking workspace — a Booknetic admin panel that looks and behaves like a standalone Booknetic install, scoped to their business only;
• their own subscription — one plan and one billing state per tenant.

This page explains the data model behind that mental picture: what data each tenant owns, what stays at the platform-owner level, and how to think about modeling your target customers when you set up your platform. For the day-to-day account-management view — creating a tenant, editing one, or deleting one — see How tenant management works in Booknetic SaaS.

How tenants are identified

Every tenant on your platform has three pieces of identity that, together, make them unique:

1. A URL slug — the short name used in the booking URL. For Aurora Wellness, the slug might be aurora-wellness, giving them the booking URL your-platform.com/aurora-wellness/. Each slug must be unique on your platform. For the full setup details — including directory-mode versus subdomain-mode routing — see Tenant URLs and routing modes in Booknetic SaaS.

2. A primary admin — the WordPress user account that signs in to manage the tenant. One tenant has one primary admin; you don't reuse the same WordPress user across multiple tenants. (If a tenant needs extra people on their team — front desk staff, an office manager — you add them through the Role Manager addon as additional users within that tenant's workspace.)

3. A subscription state — one plan the tenant is currently on, an expiry date, and a verified-vs-not-yet-verified flag. The subscription state tells you whether the tenant has a paid plan, is in a trial, is past their expiry date, or is brand-new and hasn't verified their signup email yet. For details on subscription states and billing history, see Subscription states and billing history.

Slug rules in practice

When a tenant signs up through your public signup page, Booknetic asks them to pick their booking URL slug. We recommend a slug that:

• is 3 to 35 characters long;
• uses only letters, numbers, hyphen (-), or underscore (_) — no spaces or punctuation;
• doesn't clash with one of your existing WordPress pages (a slug like about or pricing would collide with a public page on your main site).

These rules keep tenant URLs short, copy-pasteable, and unambiguous. For a deeper walkthrough of the signup form and how slugs are picked, see Tenant signup walkthrough.

What belongs to a tenant

Each tenant owns its own slice of Booknetic — its own customers, its own appointments, and its own everything-else needed to run a booking business. None of this is shared with other tenants on your platform.

When a tenant signs in to their Booknetic admin panel, every list they see (Customers, Appointments, Services, Staff, Locations, Workflows, and so on) shows only their own records. No matter how many other tenants are on your platform, the tenant sees their own data only. For the security framing of how this separation is enforced — and what to do if a tenant ever reports seeing another tenant's data — see Data isolation and permission boundaries.

What does not belong to a tenant

A few things live at the platform-owner level — that is, with you, the SaaS owner — and are not owned by any single tenant:

This is the boundary that defines a healthy multi-tenant setup: tenants own their booking business, you own the platform, and the two don't mix.

A tenant with one location vs many locations

One of the most useful things to understand when modeling your target customers is that a single tenant can have one location or many locations — both are valid and supported within one tenant record.

• One location — a solo professional working from one address, a single salon, a one-clinic dental practice. Most tenants fall here.
• Many locations — a chain or franchise operating from multiple addresses under the same business operator. Booknetic supports adding several locations under one tenant, each with its own staff, hours, and service assignments.

Important framing: a franchise or chain is one tenant with several locations, not several tenants. The franchise operator signs up once, holds one subscription, and manages all their locations from one tenant admin panel. You'd only use multiple tenants if the franchise locations were truly independent businesses with separate billing.

Each location inside one tenant can have:

• its own staff — different team members at different locations;
• its own business hours — for example, downtown branch opens earlier than the uptown branch;
• its own service assignment — the downtown branch might offer more service categories than a satellite location;
• the same customer list, workflows, and brand — because everything else is shared at the tenant level.

You'll need at least one location for a tenant to take bookings. Booknetic appointments are always assigned to a location, so a tenant without any locations can't have a working booking page. When a tenant signs up through your public signup flow, they'll typically configure their first location as part of initial setup.

Three tenant archetypes you'll see on your platform

When you're planning your SaaS platform — pricing, plan tiers, onboarding flow, support resources — it helps to picture the kinds of tenants you'll actually serve. Three archetypes cover the vast majority of Booknetic SaaS tenants. Each archetype is one tenant, shaped differently depending on the business behind it.

Archetype 1 — Solo professional tenant

A freelance trainer, a solo barber, a personal stylist, an independent dental hygienist. They run their business on their own.

Shape: 1 location · 1 staff (the owner themselves) · 1 or 2 service categories · a small customer list (tens to low hundreds).

What they need from your platform: a simple booking page on their own URL slug, a calendar, reminders, basic payment integration. They typically don't need workflows, reports, or multiple-location features in their first months. They'll often choose your cheapest paid plan or a trial.

Modeling tip: a Free or Starter plan with very small limits (1 staff, 1 location, low monthly appointment cap) covers this archetype well. Many solo professionals will stay on this tier for the long term.

Archetype 2 — Small business tenant

A 3-stylist salon, a 5-chair dental practice, a yoga studio with a couple of instructors, a small massage clinic.

Shape: 1 location (sometimes 2) · 5–10 staff · multiple service categories (haircut + treatment + product) · hundreds of customers.

What they need from your platform: the booking essentials plus workflow automation (reminders, follow-ups), basic reports, calendar integration with Google or Outlook, a tidy booking panel they can brand with their own logo and colors. They'll typically pick your mid-tier plan.

Modeling tip: this is your sweet-spot customer for paid plans. Plan limits in the dozens of staff and thousands-of-appointments range fit comfortably. Workflows and Reports capabilities are usually expected at this tier.

Archetype 3 — Franchise or chain tenant

A regional fitness chain, a multi-clinic dental group, a franchise of barbershops under one operator, a co-working brand with several rooms across cities.

Shape: multiple locations (sometimes dozens) · dozens of staff across locations · a standardized service catalog applied across locations · thousands of customers and appointments per month.

What they need from your platform: all the small-business features plus the multi-location management we described above, role-based access for branch managers (via the Role Manager addon), and predictable performance at scale. They'll typically pick your highest published plan, or a hidden enterprise plan you assign manually.

Modeling tip: this archetype is one tenant with many locations under it — not many tenants. They expect high or unlimited limits, all addons available, and a clear path to grow into more locations without re-platforming. A "Scale" or "Enterprise" plan with unlimited (-1) limits across the board is the typical fit. For enterprise pricing, use a hidden plan and assign it manually from Tenants → Edit.

These three archetypes are starting points, not boxes every tenant must fit in. They're useful for planning your plan grid, your trial defaults, your onboarding emails, and your support content. For the plan-grid examples that match these archetypes, see the three example grids in Plans and plan capabilities.

Tenant and WordPress — how they connect

Every tenant on your platform is connected to one WordPress user account — the user who signs in to manage that tenant's Booknetic panel.

• When a tenant signs up through your public signup page, Booknetic creates a new WordPress user for them automatically with a SaaS-specific role.
• When you create a tenant manually from the SaaS admin, you can either create a new WordPress user or link an existing one.

The tenant's WordPress user has access to the Booknetic admin panel only — they don't see other parts of the WordPress dashboard. This is the right default for a SaaS platform: your tenants should manage their booking business, not your WordPress site.

Don't reuse the same WordPress user across multiple tenants, and don't use your own WordPress administrator account as a tenant account. Keep your platform-owner account separate from every tenant account. For the security reasoning, see Data isolation and permission boundaries.

If a tenant needs additional people on their team (front desk staff, an office manager, branch managers) with sub-administrator access to their workspace, those people are added through the Role Manager addon as sub-users inside the tenant's boundary. They don't replace the primary admin; they extend access within the same tenant.

How a tenant comes into existence, lives, and is removed

The tenant goes through three stages on your platform:

1. Created. A tenant is created either by self-signup (the tenant fills out your public signup form) or by you manually adding them from Booknetic SaaS → Tenants → Add Tenant. At creation, Booknetic sets up the tenant's basic record, links the WordPress user, assigns the starting plan (your default plan for self-signup, or whichever plan you pick for manual create), sets the expiry date, and copies in a default weekly business-hours schedule. See Tenant signup walkthrough for the full self-signup flow and Tenant management for the manual-create path.

2. Updated over time. Once a tenant exists, two parties update them:

   • The tenant themselves — through their own Booknetic admin panel, they manage their customers, appointments, services, staff, locations, workflows, settings, and payment integrations. See Tenant admin panel reference for the full tenant-side surface.
   • You, the platform owner — through Booknetic SaaS → Tenants → Edit on the tenant row, you can change account-level fields (plan, expiry, slug, email, full name) and view payment history. Moving a tenant between plans does not delete any of their data — see the next section.

3. Cancelled or deleted. A tenant can stop paying (cancel subscription, keep account and data) or be permanently removed (delete tenant — account and tenant booking data are removed). These are very different actions; mixing them up is the most common SaaS-owner mistake. See How to cancel or delete a tenant in Booknetic SaaS for the full safe-order and the data-removal caveats.

What happens when a tenant moves between plans

When you move a tenant from one plan to another — whether they upgrade themselves through Billing, you change their plan in Tenants → Edit, or their plan expires and they fall onto the Expired plan — no tenant data is deleted.

• The tenant's customers, appointments, services, staff, and locations stay in place.
• If the new plan has tighter limits, any over-limit staff, services, locations, or service extras are paused (deactivated), not deleted. The oldest entries stay active; the newest ones are paused first.
• When the tenant upgrades back, the paused entries come back automatically, oldest first.

Use the phrase "paused, not deleted" when you explain this to customers. No tenant ever loses booking data because of a plan change. For the full explanation of capabilities, limits, and what happens on each plan transition, see Plans and plan capabilities and Expired plan behaviour.

What gets removed when a tenant is deleted

Tenant deletion is a destructive action. When you delete a tenant from Booknetic SaaS → Tenants → Delete, Booknetic removes the tenant's booking data — appointments, customers, services, staff, locations, workflows and workflow logs, payment records, custom signup answers, business hours and holidays, appearance and settings — and removes the tenant's WordPress user account if that user belongs only to the tenant role.

Two important caveats stay with deletion:

• Some uploaded files may remain on the server. A tenant's profile picture, logo, or files uploaded through custom forms may stay in the WordPress uploads folder even after the tenant record is deleted. For privacy or GDPR-style data-removal requests, plan to review the uploads folder and hosting backups separately. The full caveat is documented in How to cancel or delete a tenant.
• Deletion is permanent. Once a tenant is deleted, you can't restore them from inside Booknetic. The only recovery path is a hosting backup you took before the deletion.

Tenant data and your developer access (REST API)

If you're integrating your SaaS platform with other systems — a CRM, an analytics warehouse, your own onboarding flow — you can access tenant data programmatically through the Booknetic REST API. Every API call is scoped to one tenant: a request to list customers returns the customers of one tenant only, not everyone on your platform.

For the full API reference, authentication, and per-tenant scoping rules, see REST API per-tenant scoping.

Common questions

"Can a tenant have multiple primary admins?" No — one tenant has one primary admin (the WordPress user account linked to the tenant). If a tenant needs additional people on their team with admin-style access, install the Role Manager addon and add them as sub-users inside the tenant's workspace.

"Can the same person be a customer of more than one tenant on my platform?" Yes — and each tenant only sees their own copy. Each tenant has its own independent customer list. If the same human being books with Aurora Wellness and separately with Metro Dental, both businesses will have a customer record for that person, but neither tenant can see the other's record. From each tenant's point of view, the customer belongs only to them. (For the security framing behind this, see Data isolation and permission boundaries.)

"Can a tenant have zero locations?" Practically, no — tenants need at least one location to take bookings, because every appointment is assigned to a location. When a tenant signs up, they'll typically configure their first location as part of initial setup. If a tenant is in mid-setup and hasn't added a location yet, their booking page won't accept appointments until they do.

"Can a tenant be moved from one plan to another without losing data?" Yes. Plan changes preserve all tenant data. If the new plan has tighter limits, over-limit staff/services/locations are paused (not deleted), and they come back automatically when the tenant upgrades again. See Plans and plan capabilities for the full plan-change behaviour and the "paused, not deleted" framing.

"If I delete a tenant, what exactly is removed?" The tenant record, all of the tenant's booking data (appointments, customers, services, staff, locations, business hours, workflows, workflow logs, payment records), custom signup answers, appearance and settings, and the linked WordPress user if it only had the tenant role. Some uploaded files (profile pictures, custom-form file uploads) may remain on the server as orphaned files — see How to cancel or delete a tenant for the privacy/GDPR caveat.

"Is a franchise with many branches one tenant or many tenants?" One tenant with multiple locations, in almost every case. The franchise operator signs up once, holds one subscription with you, and manages all branches from one tenant admin panel. Use multiple tenants only if the franchise locations are truly independent businesses with separate billing relationships with you.

"Can I bulk-export a tenant's data?" A per-tenant data export exists inside the tenant's own Settings, when the relevant capability is enabled on their plan. The tenant initiates the export from their own panel. For migration or compliance workflows that need to go further than the in-panel export, talk to your hosting/backup setup.

Gotchas to know

A few subtle points worth being aware of when you operate the platform:

• Each tenant's customer list is fully independent. If you have 500 tenants and the same person is a customer of 10 of them, you'll have 10 separate customer records — one per tenant. There is no cross-tenant customer registry. This is by design: each tenant's customer relationships are theirs.
• Custom signup answers are tied to the tenant record. When a tenant signs up and fills out your custom signup fields (industry, VAT ID, uploaded business license), those answers are stored against that tenant. When the tenant is deleted, their custom answers are removed along with the rest of the tenant data. The exception is uploaded files in custom-form fields — these may stay on the server. See How to cancel or delete a tenant for the orphaned-files caveat.
• Multi-location is a tenant-level shape, not a separate product. There's no "multi-location mode" toggle to flip on. Any tenant can add a second location from their Locations page (subject to their plan's locations limit). A "franchise tenant" is just a tenant with many locations.
• Staff and services are tenant-scoped, not location-scoped. Staff belong to a tenant; a single staff member can work at one or more locations of the same tenant. Services belong to a tenant; the same service can be offered across multiple locations. The relationship between staff, services, and locations is set up by the tenant inside their own panel.
• Plan changes don't move tenant data; they only change capabilities and limits. Moving a tenant from Free to Pro doesn't move their data anywhere; it just changes which features and limits apply on their next page load. Same in the other direction — downgrading doesn't delete; it pauses over-limit rows.

Related documentation

• How tenant management works in Booknetic SaaS — owner-side CRUD, plan assignment, lifecycle.
• Plans and plan capabilities in Booknetic SaaS — the plan side of the tenant ↔ plan relationship.
• Tenant admin panel reference — what tenants see and do inside their own panel.
• Data isolation and permission boundaries in Booknetic SaaS — how tenant data stays separated, what each role can see, and what to do if cross-tenant visibility is ever reported.
• Tenant URLs and routing modes in Booknetic SaaS — slug + URL identity, directory mode vs subdomain mode.
• Tenant signup walkthrough — how new tenants come into existence through self-signup.
• Tenant signin and forgot password — how tenants sign in.
• How to cancel or delete a tenant in Booknetic SaaS — the deletion side and the orphaned-uploads caveat.
• REST API per-tenant scoping — programmatic access scoped to one tenant at a time.
• Subscription states and billing history — subscription state component of tenant identity.
• Expired plan behaviour — what happens to a tenant when their plan expires.
• Custom signup fields — owner-defined fields stored as part of each tenant's record.