Act 1: First Contact

3. Behind the Scenes: Provisioning

Story

Sarah submitted the trial form. She doesn't see it, but several things happen in a single coordinated transaction to get her company ready.

The system creates everything in one atomic transaction:

1Company record — name, address, status set to ACTIVE, environment set to CUSTOMER
2Tenant — a multi-tenant abstraction linked to the company
3Roles — default roles created: OWNER, COMPANY_ADMIN, HRMANAGER, PAYROLLMANAGER, EMPLOYEE
4Permissions — each role gets granular defaults (module + action + resource level)
5Subscription — a CompanySubscription with status TRIALING and an end date
6User record — Sarah's account created (or linked if she exists), with the OWNER role
7Trial record — logged for deduplication and analytics
8OTP email queued — an invitation OTP is prepared for delivery

All or nothing. If any step fails, everything rolls back. No orphan records, no half-setup companies.

Failure	What the user sees	What happens next
Any step fails mid-transaction	Generic error, no company created	Full rollback, user retries
User already exists in the system	Assigned to the new company with OWNER role	No duplicate user, proceed normally
Company name matches existing (different domain)	Allowed — no conflict	Companies are isolated by tenant
User exists but email not verified	Must verify email before accessing the dashboard	Same OTP verification flow applies
Trial expired and user wants another	Depends on policy — typically rejected	Contact support for extension

Scenario	Behavior	Why
Same company name, different domain	Allowed	Company names are not globally unique
User signed up before but never completed OTP	New invite sent, old one invalidated	Fresh start for the new trial
Provisioning modes differ	Self-serve: status ACTIVE with trial. Admin-provisioned: status LOCKED	Different trust levels for different entry points

ZettaHRM

A modern HRM workspace for employee management, attendance tracking, leave approvals and structured day-to-day HR operations.