Trust & Security

Battle test: multiple tenants in a BuildWithHQ SaaS

How BuildWithHQ's first-class modules and APIs behaved with multiple tenants, scoped users, and hostile cross-tenant requests.

On August 30, 2026, we tested BuildWithHQ as a multi-tenant SaaS builders platform. Multiple tenant organizations operated inside the same SaaS while using different users, roles, DataRoles, locations, records, conversations, and support queues. The system worked within its designed boundaries: tenants remained separated, and each user could see or change only the information allowed by their server-derived identity and permissions.

How the environment was used

Two synthetic service organizations were created with separate users, locations, contacts, work orders, messages, and support tickets. We used the platform as those organizations rather than only checking whether database objects existed. The workload included ordinary inbox traffic, ticket-enabled email addresses, message bursts, ticket resolution and reopening, workflow actions, AI paths, integrations, record searches, and attempts to access another tenant’s data.

The SaaS used its normal three-database boundary: SaaS DB, SaaS Vector DB, and SaaS Immutable Logs. Builders, Template Library, and Platform Orchestration remained shared platform services and were not provisioned again for the SaaS.

What was tested

Every current first-class module and API surface in the launch inventory was exercised at its applicable layers, including UI contracts, application services, stored procedures, database behavior, and live integration paths. Coverage included Universal Inbox, Support Tickets, GoClaw, AI retrieval, workflows, contacts, work orders, files, conversations, activity, search, knowledge, collaboration modules, integrations, marketplace behavior, provisioning, and operational workers.

• Valid users attempting to read or change another tenant’s records.
• Users attempting to widen their location, role, DataRole, named-action, or AI-read authority.
• Client-supplied tenant and record identifiers that did not match the authenticated server identity.
• Duplicate messages, ticket-number continuity, mailbox ticketing controls, stale Inbox/GoClaw context, workflow approvals, and replay behavior.
• Clean provisioning, generated API and stored-procedure contracts, seed consistency, rollback, and disposal of the three SaaS databases.

Across the tested first-class features and APIs, tenant separation held and record visibility followed each user’s role, DataRole, location, ownership, and explicit capabilities. AI retrieval respected the same record permissions, governed actions stayed behind their approval controls, and requests carrying another tenant’s identifiers were denied.

Complete test inventory

The following 1,169 named tests all passed. Open any group to review every individual item.