Multitenancy in Generated Apps

Applies to: App Generation projects that use the SaaS Engine template

Multitenancy lets one application serve multiple organizations. Each organization must access only its permitted users and business data.

Request multitenancy during requirements gathering. AppWizzy includes it only when the generated schema identifies a multitenant application.

Define the tenant model

Before generation, specify these requirements:

  • the tenant name, such as organization, company, or workspace.
  • how users join a tenant.
  • whether one user can join multiple tenants.
  • which records belong to one tenant.
  • which roles work inside one tenant.
  • which roles can access all tenants.
  • how invitations, sign-up, and tenant changes must work.

Use one tenant term throughout your requirements. This term becomes part of the schema, source code, and interface.

What AppWizzy adds

When the generated schema enables multitenancy, AppWizzy adds a tenant entity. The default entity name is organizations.

AppWizzy also adds these schema elements:

  • a tenant relationship on users.
  • a tenant relationship on business entities.
  • a global access field on roles.
  • protected tenant fields that the basic schema process cannot edit.

The generated application uses these elements as its multitenancy foundation. Your requirements still define the required workflows and access rules.

Request a multitenant application

  1. Open Create New App.
  2. Select SaaS Engine.
  3. State that the application is multitenant.
  4. Name the tenant entity.
  5. Define tenant and global roles.
  6. Define tenant ownership for each business record.
  7. Describe invitation, sign-up, and membership workflows.
  8. Complete the AI Architect questions.
  9. Review and test the generated application.

Example requirement:

Create a multitenant CRM. Each company manages only its customers and deals. A platform administrator can access every company.

Verify tenant isolation

Test multitenancy with at least two tenants. Use separate users and records for each test.

Verify these cases:

  • tenant users cannot list another tenant's records.
  • tenant users cannot open another tenant's record by URL.
  • API requests enforce the same tenant rules.
  • global roles have only the requested access.
  • new users receive the correct tenant.
  • file and image access follows tenant ownership.

Generated relationships do not replace access testing. Custom pages, queries, and integrations must enforce the same tenant rules.

Change multitenancy later

Adding multitenancy after launch can require schema migrations, data assignment, and source changes. Define a tenant for every existing record.

Use Edit via Chat to request the change. Review the affected migrations and test existing data before release.

The current SaaS Engine project does not show the visual DB Schema editor. Use the application, source code, and tests for review.

Read Requirements Gathering and Create Schema for the initial generation process.