A staged workflow that replaces WhatsApp groups, emailed PDFs, and spreadsheets with a single tracked case per unit — from the first invite to the final move-out close-out.
Each application is a case. It moves through defined stages — visible to the admin at all times. Nothing falls through the cracks.
Admin or Owner
The admin or property owner generates a tracked invite link for the incoming resident. Owner invites include a sub-invite step: the owner can forward a separate tenant invite link directly from their portal — the original invite is consumed when the tenant link is generated.
Applicant (resident / tenant)
The applicant completes a 4-step wizard: account creation, personal details, any sub-processes the scheme requires (pets, vehicles, etc.), and a mandatory signed acceptance of the complex rules. SA ID is captured and encrypted at this stage — it becomes the global identifier for this person across all Zyden schemes.
Owner then Admin
The application enters a staged approval queue. For tenant applications, the owner approves first ("pending owner"). Owner-resident applications go straight to admin approval ("pending admin"). The admin sees all pending applications in the Action Stream on the dashboard.
System
Once approved, the unit record is updated and the resident gains access to their portal. The unit shows "live" status in the admin console. An access_map entry is created, giving the resident login access to that scheme's subdomain only.
Move-out is tracked as a separate case type — not a WhatsApp thread. The unit doesn't reset until the close-out is approved.
The owner or admin initiates a move-out against a specific unit. The unit enters "move-out in progress" status — a banner appears in the admin console for that unit.
The admin reviews the move-out request. This is the checkpoint for outstanding balances, damage deposits, or compliance checks — handled in your levy system, linked from the unit record.
Once approved, the unit action is closed, the resident's access is revoked, and the unit status resets to vacant — ready for the next onboarding pipeline.
During step 1 of the application, the applicant's South African ID number is captured, encrypted with AES-256, and stored as a keyed blind index in the database. It is never stored in plaintext.
The blind index means Zyden can detect if the same person applies to multiple schemes (deduplication) without ever decrypting the SA ID for lookup. Every person in the system has exactly one identity record, regardless of how many schemes they belong to.
AES-256 field-level encryption
SA ID, name, phone — all encrypted at the column level before storage.
Blind index deduplication
HMAC-SHA256 keyed hash enables lookup without decrypting. One identity per person, globally.
Signed acceptance of complex rules
Applicant accepts during step 4. Name, IP address and timestamp logged to an immutable record.
No PII in URLs or HTML attributes
Decrypted values are never embedded in page source as onclick data or query parameters.
Automated stage reminders
Email nudges sent to applicants or owners when a pipeline stage has been idle for too long. Not yet built — on our backlog.
Book a 30-minute demo. We'll walk through the full onboarding pipeline — from invite generation to approval — in real time.
Book a Demo →