Tenant isolation and dedicated infrastructure

Technical specification for per-tenant Firebase provisioning and data isolation.

Model

One Firebase project per organisation (tenant). Each company added to the platform receives its own Firebase project. The project includes:
- A dedicated Firestore database (default or named). All collections (staff, users, *_workview, JobWork, ManagmentJobs, Leads, sharedAccounts, emailHistory, etc.) are scoped to that project. No shared database across tenants.
- A dedicated Firebase Storage bucket (default project bucket or custom). All report and document paths are under that bucket. No cross-tenant object access.
- Firebase Authentication: User accounts are per project. No shared identity store across tenants. Google OAuth and email/password are configured per project.
- Cloud Functions: Deployed per project (or single codebase deployed to multiple projects). Each invocation runs in the context of one project; no cross-tenant data access.
- App Distribution / Hosting: Per project. CRM PWA may be hosted per project (multi-site) or behind a single host with project selection by domain or auth claim. Android app builds are distributed per project via App Distribution.

New tenant onboarding creates a new Firebase project (automated or manual). Project ID and config (apiKey, authDomain, etc.) are stored in a central registry or delivered to the tenant. Environment-based configuration in the CRM and Android app points to the correct project (e.g. via build-time env or runtime config document).
No production secrets committed; project configs and service account keys stored in Secret Manager or secure config store. Token storage for shared accounts (e.g. Gmail) is per project and restricted to super_admin.

Data isolation: Logical and physical separation. Firestore and Storage have no cross-project access by default. Supports compliance requirements (e.g. data residency, audit per tenant). Access control and security rules apply only to that project’s resources.
Audit: Per-project audit logs (Firestore, Storage, Auth). Simplifies per-tenant audit trails and incident response.
Rules: Firestore and Storage rules are deployed per project. Same rule logic can be reused across projects; no need to encode tenant ID in every rule when each project is single-tenant.

Supports single-company deployments (one project) and multi-company white-label (one project per company). Multi-site hosting: separate Firebase Hosting sites per project or reverse proxy routing by domain. Environment-based configuration (e.g. FIREBASE_PROJECT_ID) selects project at build or runtime.