Data isolation and permission boundaries

Trust summary

Trust: Booknetic SaaS isolates tenant data at the database query layer. This page explains what is separated, who can see what, and the edge cases you should know about when running a SaaS platform.

Booknetic SaaS is built for a multi-tenant setup: one SaaS platform can host many tenant businesses, and each tenant works inside its own Booknetic workspace.

In normal tenant-side screens, Booknetic scopes records to the current tenant before reading or writing data. That means Tenant A should not see Tenant B's customers, appointments, services, staff, locations, workflows, payments, or tenant settings from the tenant admin panel.

At the same time, you — the SaaS platform owner — need owner-level tools to manage your platform. Booknetic SaaS therefore has a separate owner-side admin area where trusted platform administrators can manage tenants, plans, billing, SaaS settings, and owner-level workflow activity.

This page is written in practical terms: what each role can see, what each role can do, and which security hygiene rules help keep the boundary clean.

What data isolation means in Booknetic SaaS

Each tenant has its own Booknetic data scope. Tenant-owned records are stored as part of the shared SaaS platform, but tenant-side actions run in the context of one tenant.

In practice, this means a tenant admin normally sees only their own tenant's:

• customers;
• appointments;
• services and service categories;
• staff members;
• locations;
• availability, holidays, special days, and timesheets;
• workflows and workflow history connected to that tenant;
• payment and billing information connected to that tenant;
• tenant settings and appearance settings.

Booknetic SaaS enforces this by applying tenant context checks before tenant-side screens read or write Booknetic data. The same general boundary applies across normal tenant admin actions and customer-facing booking actions.

The platform owner is different. The SaaS owner is expected to administer the SaaS platform and can see tenant accounts and platform-level tenant information from the SaaS admin area. This is intentional: you need those tools to support tenants, manage plans, and keep billing accurate.

Roles and permission boundaries

Booknetic SaaS has several user roles or access levels. The names can sound similar, so it helps to separate them clearly.

Role	Who this usually is	Main access
WordPress Super Admin / WordPress Administrator	You or your trusted site administrator	Has broad WordPress-level control over the site. Treat this as the highest-trust account.
SaaS Owner / platform admin	The person managing Booknetic SaaS from the owner panel	Manages tenants, plans, SaaS payments, SaaS settings, custom fields, owner-side workflows, and owner-side workflow logs.
Tenant Admin	The business owner using one tenant account	Manages that tenant's own Booknetic panel: services, staff, customers, appointments, workflows, profile, and billing.
Tenant sub-user / staff user	A staff member inside a tenant business	Works inside the same tenant boundary, with access narrowed by the tenant's staff role and plan capabilities.
Customer / booking user	A tenant's end customer booking an appointment	Uses the public booking flow or customer-facing screens. No SaaS admin access.

A tenant admin may be an "administrator" inside their own Booknetic workspace, but that does not make them a SaaS owner. Tenant admins do not receive the owner-side SaaS menu for platform tools such as Tenants, Plans, SaaS Settings, or owner-level payment management.

What the SaaS owner can see and do

The SaaS owner manages the platform from the owner-side Booknetic SaaS area.

From the SaaS admin area, the owner can manage platform-level items such as:

• the full tenant list;
• tenant profiles and tenant account details;
• tenant plan assignment and subscription state;
• tenant payment and billing history available in the SaaS owner screens;
• SaaS plans and plan capabilities;
• SaaS settings;
• owner-side workflows and workflow logs, where enabled.

The owner can also delete tenants when the account should be permanently removed. Because delete is destructive and has privacy implications, review the deletion workflow before using it: see How to cancel or delete a tenant in Booknetic SaaS.

What the owner can change depends on the specific owner-side screen. For example, the SaaS owner area is designed for tenant/account/platform administration — tenants, plans, settings, payments, and owner workflows. It should not be described as an unrestricted "act as any tenant" workspace unless your installation has a separately confirmed impersonation feature.

Booknetic SaaS should not be described as having an unrestricted "log in as tenant" feature unless that feature is separately confirmed in your installation. If your team relies on an impersonation or login-as workflow, confirm the supported path and restrict it to trusted administrators only.

Important WordPress note

Booknetic SaaS permission boundaries control Booknetic SaaS and Booknetic tenant data. They do not turn WordPress administrator accounts into ordinary tenant users.

A WordPress administrator may have broader access to the WordPress site outside Booknetic, depending on your WordPress roles, plugins, and hosting setup. Do not give WordPress administrator access to tenant admins unless you intentionally want them to have high-trust site access.

What a tenant admin can see and do

A tenant admin manages one tenant's Booknetic workspace.

A tenant admin can normally manage their own tenant's:

• appointments;
• customers;
• services;
• staff;
• locations;
• availability and schedules;
• workflows and notifications;
• appearance and tenant settings;
• billing and plan information shown inside the tenant panel.

Tenant access can also be limited by the tenant's plan. For example, a plan may hide or limit certain modules, features, or counts. For more detail, see Plans and plan capabilities in Booknetic SaaS.

A tenant admin should not see:

• other tenants in the SaaS owner's tenant list;
• other tenants' customers, appointments, services, staff, locations, workflows, or payments;
• the owner-side plan editor;
• SaaS platform settings;
• owner-level workflow logs or owner-side payment management;
• another tenant's workflow setup or customer records.

If a tenant reports that they can see another tenant's data, treat it as urgent and contact Booknetic support immediately.

How isolation is enforced at a high level

Booknetic SaaS uses tenant context checks across the product. The goal is that every normal tenant-side action runs in one tenant's context before Booknetic reads or writes tenant data.

At a high level:

• Tenant-side database actions are scoped to the current tenant. When a tenant admin opens customers, appointments, staff, services, locations, workflows, or payments, Booknetic reads records for that tenant context.
• Tenant admin requests check the current user's tenant context. A tenant admin session is tied to the tenant account it belongs to.
• Public booking pages load in a tenant context. A tenant's booking URL identifies which tenant's services, staff, locations, and availability should appear.
• Workflow activity runs with tenant context. Tenant workflows and workflow logs are connected to the tenant whose event triggered them. If you need to check whether a workflow action fired, see Workflow Logs in Booknetic SaaS.
• Plan capabilities are checked at runtime. A tenant can use only the features and limits allowed by the assigned plan.
• Some child records inherit their tenant boundary from a parent record. For example, appointment-related child details are protected through the appointment they belong to. Customers do not need to configure this, but it is useful to know that not every related record has to appear as a separate top-level tenant object to remain inside the tenant boundary.

This section is intentionally high-level. The public documentation should explain the behavior without exposing low-level implementation details that could help someone probe the system.

Edge cases to understand

Shared WordPress user accounts

Do not casually reuse the same WordPress user across multiple tenants.

If the same WordPress user is intentionally connected to more than one tenant or role, that user may be able to access more than one workspace depending on how the account is configured. Keep each tenant's admin account separate unless you have a clear operational reason and you understand the access impact.

Best practice: create a separate tenant admin user for each tenant business, and keep your own WordPress administrator account separate from every tenant account.

WordPress dashboard access

Booknetic SaaS can restrict tenant users away from normal WordPress admin pages and send them back to the Booknetic panel. Keep this restriction enabled unless you have a specific reason to allow tenant users into other WordPress admin areas.

If you disable that restriction, WordPress roles and other plugins may affect what tenant users can access outside Booknetic. Review those permissions carefully.

Cached or delayed state

Some platform state may be cached briefly by WordPress or by platform-level update/licensing systems. After changing settings, plans, or plugin state, you may need to refresh the page or wait briefly before every screen reflects the change.

This should not be treated as permission to share data across tenants. It is a normal caution for SaaS owners: after sensitive settings changes, confirm the result from the correct tenant account.

Child records connected through parent records

Some Booknetic data is connected through a parent item. For example, appointment details belong to an appointment, and workflow action details belong to a workflow.

Those records are still expected to stay inside the same tenant boundary because the parent item is tenant-scoped. If you ever see a child detail appear under the wrong tenant, report it as a security issue.

Uploaded files and tenant deletion

Tenant deletion removes tenant records from Booknetic SaaS, but some uploaded files may remain on the server as orphaned files. This matters for privacy and GDPR-style deletion requests.

Before promising complete data removal, review the deletion guide and your WordPress uploads/backups process: How to cancel or delete a tenant in Booknetic SaaS.

Also avoid manually editing files inside WordPress upload folders used by Booknetic. File ownership, file paths, and file references are managed by Booknetic and WordPress.

Customer-facing notifications and file URLs

If a notification template includes a file URL, the recipient may be able to open that URL later if the file remains on the server. Be careful when adding uploaded-file links to customer-facing workflow messages.

If you need to verify whether a tenant workflow message was sent, use Workflow Logs rather than guessing from email delivery alone: Workflow Logs in Booknetic SaaS.

Security hygiene rules

Security: Keep platform-owner accounts, tenant admin accounts, and WordPress administrator accounts separate. Most permission mistakes come from sharing high-trust accounts too widely.

Follow these rules when operating Booknetic SaaS:

• Do not share WordPress Super Admin or WordPress Administrator credentials with tenant admins.
• Do not use your own WordPress administrator account as a tenant admin account.
• Do not reuse one WordPress user as the admin for multiple tenants unless you intentionally want that person to have multi-tenant access.
• Use clear, separate usernames and email addresses for each tenant account.
• Do not manually edit Booknetic files under wp-content/uploads/booknetic/ unless Booknetic support or your developer gives you a specific cleanup plan.
• Keep tenant access restricted to the Booknetic panel unless the tenant truly needs broader WordPress access.
• Review plan capabilities before telling a tenant they "should" see a module. The module may be hidden or limited by the plan.
• If you use workflow notifications, make sure tenant-facing messages use the tenant's business details and do not accidentally include owner-only or platform-only information.

Common questions

Can two tenants accidentally see each other's data?

In normal Booknetic SaaS tenant-side flows, tenant data is scoped before it is read or written. Tenant A should not see Tenant B's customers, appointments, services, staff, locations, workflows, or payments.

If you ever see anything that looks like cross-tenant visibility, do not ignore it and do not try to work around it. Contact Booknetic support immediately with the tenant name, user account, page URL, approximate time, and a screenshot with any sensitive customer data redacted.

Can I, as the SaaS owner, modify a tenant's appointments?

The SaaS owner area is for platform administration: tenants, plans, payments, settings, owner workflows, and related SaaS management screens.

Whether you can directly edit a tenant's day-to-day booking data depends on the specific UI surface available in your installation. Do not assume that the owner panel is an unrestricted "act as tenant" area. If you need to change a tenant's operational records, use the tenant's own scoped Booknetic workspace or confirm the supported admin path for your installation.

Can a tenant admin manage their own billing?

Yes, tenant billing is shown inside the tenant's Booknetic panel where the tenant's plan and permissions allow it. The tenant can review their own billing/subscription state and use the plan-change or cancellation options exposed to them.

They cannot manage the platform's plan editor, other tenants' billing, or owner-side payment settings.

If I delete a tenant, is their data gone?

Deleting a tenant removes tenant data from Booknetic SaaS and cannot be undone from the app. However, uploaded files may remain on the server as orphaned files, and hosting backups may also retain copies outside Booknetic SaaS.

For the full deletion workflow and privacy caveats, see How to cancel or delete a tenant in Booknetic SaaS.

What if a tenant's customer asks for their data to be removed?

The tenant should delete the customer record from their tenant admin panel when appropriate. If the request also involves uploaded files, backups, or a formal GDPR/right-to-be-forgotten process, review your WordPress uploads folder, hosting backups, and legal obligations.

This page is not a full legal/GDPR walkthrough. For strict deletion requirements, create an internal process with your legal or privacy owner.

What should I do if I suspect a cross-tenant data exposure?

Stop and report it immediately. Email [email protected] with the details, including:

• the tenant name or slug;
• the user account involved;
• the page or workflow where the issue appeared;
• the date and time;
• screenshots or forwarded messages, with sensitive data redacted where possible.

Do not send the same suspected data to other tenants, and do not post customer data in public channels.

Related documentation

• Tenant management: /documentation/tenant-management
• Plans and capabilities: /documentation/plans-and-capabilities
• Workflow Logs: /documentation/workflow-logs
• Cancelling and deleting tenants: /documentation/cancelling-and-deleting-tenants
• Tenant URLs and routing: /documentation/tenant-urls-and-routing

Quick checklist for SaaS owners

Before onboarding tenants, confirm that:

• Your WordPress administrator account is separate from tenant accounts.
• Each tenant has its own tenant admin user.
• Tenant users are restricted from general WordPress admin pages unless intentionally allowed.
• Plans and capabilities match what each tenant should see.
• Workflow templates do not expose owner-only or platform-only information to tenant customers.
• Your deletion process includes uploaded files and backups, not only the in-app tenant delete action.
• Your team knows to contact support immediately if cross-tenant visibility is suspected.