TENANT / CLIENT MANAGEMENT
For real estate companies, property managers, leasing teams, client-service teams, KYC and screening teams, finance teams and authorised administrators
|
LEASEORA TENANT / CLIENT MANAGEMENT Detailed User and Technical Operations Guide Invitation • Registration • Profile • KYC • Screening • Applications • Lease • Payments • Wallet • Maintenance • Documents • Cross-Module Services • Analytics • Mobile |
For real estate companies, property managers, leasing teams, client-service teams, KYC and screening teams, finance teams and authorised administrators
Version 1.0 | July 2026
|
|
Purpose of this guide This guide explains how a real estate company uses Leaseora's Tenant / Client module from invitation and registration through profile completion, KYC, screening, property application, lease assignment, rent payment, wallet, maintenance, documents, notifications, wider property services, analytics, blacklisting, SuperAdmin oversight and the mobile app. It also provides a detailed technical reference based on the supplied models, controllers, services, events, notifications and jobs. |
1 Purpose, Audience and Terminology
The Tenant / Client module is Leaseora's central client identity and relationship layer. It connects each client to landlords, properties, leases, payments, wallets, maintenance requests, documents, communications, mortgage applications, property purchases, WeBuild bookings and land transactions.
|
Item |
Description |
|
Primary users |
Real estate companies, landlords, leasing teams, property managers, KYC and screening teams, finance teams, client-service teams, SuperAdmins and clients. |
|
Business term |
This guide uses Client in business-facing instructions because Leaseora serves renters, buyers, mortgage applicants, land buyers and development clients. |
|
Technical term |
Controller, model, route and notification names retain Tenant where supplied by the system design. |
|
Client record |
Tenant is linked to User through user_id and carries portfolio, identity, employment, KYC and status data. |
|
Operational boundary |
Leaseora supports onboarding, verification, screening and service access. Final legal, credit, KYC, tenancy and enforcement decisions require authorised human review and applicable law. |
|
|
Historical records Removing a client from an active portfolio relationship should not automatically erase lease, payment, KYC, maintenance, screening or audit history that must be retained. |
2 Complete Tenant / Client Lifecycle
Figure 1. Complete Tenant / Client lifecycle
|
Stage |
Business outcome |
|
Invite or register |
A User and Tenant relationship is established. |
|
Profile |
Personal, employment and emergency information is completed. |
|
KYC |
Identity and address evidence are reviewed. |
|
Screening |
Background, credit and references support the landlord decision. |
|
Apply |
Client applies for a property listing. |
|
Lease |
Landlord assigns and activates a lease using the client record or unique code. |
|
Ongoing service |
Client uses dashboard, payments, wallet, maintenance, documents and notifications. |
|
Additional services |
Client accesses Lease Angel, mortgage, property purchase, WeBuild and land. |
|
Oversight |
Landlord analytics, CRM, bulk actions, blacklist and SuperAdmin controls apply. |
3 Roles, Responsibilities and Segregation of Duties
|
Role |
Main responsibility |
Control |
|
Client Administrator |
Creates, invites and manages Client records. |
Should not alter KYC or screening evidence without authority. |
|
KYC Reviewer |
Reviews submitted identity documents. |
Should not approve their own manipulated submission or bypass evidence rules. |
|
Screening Analyst |
Runs background, credit and reference checks. |
AI output is advisory and must be verified. |
|
Leasing Officer |
Reviews listing applications and creates leases. |
Should use authorised approval criteria. |
|
Finance Officer |
Reviews rent, wallet and other client payments. |
Should separate payment verification from reconciliation. |
|
Client Service Officer |
Supports profile, notifications, documents and general access. |
Should not access restricted credit or KYC data without need. |
|
CRM / Communication User |
Logs authorised client communications. |
Must respect communication consent and privacy. |
|
SuperAdmin |
Provides platform oversight, suspension, KYC review and controlled support. |
Impersonation requires strong controls and audit. |
|
Client |
Provides accurate information, protects credentials and uses services under agreements. |
Can view and manage only their own records. |
|
|
Least privilege A user who can edit contact details should not automatically be able to view KYC documents, credit results, wallet transactions or all cross-module records. |
4 Core Client Models and Relationships
|
Model |
Purpose |
|
User |
Authentication and platform account. |
|
Tenant |
Core client identity, employment, KYC and portfolio status. |
|
TenantProfile |
Extended profile information. |
|
TenantInvitation |
Landlord invitation, token, status and expiry. |
|
TenantKycDocument |
Uploaded identity and address documents. |
|
TenantKycVerification |
KYC processing and decision record. |
|
TenantScreening |
Screening case. |
|
TenantScreeningResult |
Background, credit or screening result. |
|
TenantReference |
Reference contact and feedback. |
|
TenantBlacklist |
Landlord-specific blacklist record. |
|
TenantDocument |
Client document library. |
|
TenantBankAccount |
Verified withdrawal account. |
|
ListingApplication |
Application for a rental property. |
|
Wallet |
Client wallet. |
|
TenantMortgageEligibilityScore |
Mortgage eligibility result. |
Figure 2. Leaseora Client ecosystem
5 Phase 1 - View All Clients
|
STEP |
Open the Client Portfolio Primary user: Landlord / Client Administrator |
Navigate to Tenants -> All Tenants. TenantController@index provides the landlord portfolio view and getData supplies paginated, searchable records.
|
Filter |
Use |
|
Name |
Search first or last name. |
|
Email |
Search account or profile email. |
|
Phone |
Search contact number. |
|
Property |
Clients linked to a selected property. |
|
Lease status |
Active, pending, expired or historical relationship according to deployed filters. |
|
Date joined |
Client creation or portfolio-link date. |
|
Dashboard statistic |
Meaning |
|
Total clients |
All clients in the landlord scope. |
|
Active clients |
Clients with active status or current relationship under the deployed definition. |
|
Overdue payments |
Clients with overdue payment records. |
|
Expiring leases |
Clients with leases approaching end date. |
Use search for name, email, phone or unique code. Use export for CSV or Excel under authorised permissions.
|
|
Scope by landlord A landlord should see only clients legitimately linked to their portfolio, property, application, lease or authorised shared relationship. |
6 Client Record Fields and Statuses
|
Field |
Purpose |
|
user_id |
Linked platform account. |
|
unique_code |
Short identifier used for search and lease assignment. |
|
first_name / last_name |
Client legal or profile name. |
|
email / phone |
Primary contact details. |
|
date_of_birth |
Identity and eligibility information. |
|
nationality / gender / marital_status |
Profile fields subject to lawful use and privacy controls. |
|
employment_status / employer_name / annual_income |
Employment and affordability context. |
|
emergency contact |
Name and phone for authorised emergency use. |
|
profile_photo |
Client profile image. |
|
status |
Active, inactive or blacklisted. |
|
kyc_status |
Pending, verified or rejected. |
|
|
Sensitive and protected information Use nationality, gender, marital status and similar personal data only where lawful, necessary and authorised. Do not use protected attributes for unlawful discrimination. |
7 View an Individual Client Profile
|
STEP |
Review the Full Client Profile Primary user: Landlord / authorised staff |
|
Profile area |
What it shows |
|
Personal details |
Name, date of birth, nationality, gender and marital status. |
|
Contact |
Email, phone and emergency contact. |
|
Employment |
Status, employer and income. |
|
Leases |
Active and historical leases. |
|
Payments |
History, overdue records and behaviour score. |
|
Maintenance |
Submitted requests and outcomes. |
|
Documents |
KYC, lease, receipts and other authorised documents. |
|
KYC |
Submission and verification status. |
|
Screening |
Risk score and results. |
|
CRM |
Communication history and linked lead information. |
edit and update allow authorised changes. destroy should be used only after legal, financial, KYC, lease and audit retention review.
|
|
Profile edits require provenance Where possible, record who changed a sensitive field, the previous value, the new value, time and reason. |
8 Add a Client Manually
|
STEP |
Create or Link a Client Record Primary user: Landlord / Client Administrator |
1. Open Tenants -> Add Tenant.
2. Enter personal, contact and employment information.
3. Search for an existing User by email.
4. If a matching User exists, confirm identity before linking.
5. If no User exists, create the User and Tenant records.
6. Send the setup invitation.
7. Confirm the Client appears in the landlord portfolio.
8. Record the generated unique code.
|
|
Do not create duplicate people Search email, phone, unique code and identity context before creating a new account. Duplicate Client records can fragment leases, payments, KYC and communications. |
9 Invite a Client
|
STEP |
Send a TenantInvitation Primary user: Landlord / Client Administrator |
TenantController@invite and @sendInvitation create the invitation workflow. The mobile landlord API also supports invite.
|
TenantInvitation field |
Purpose |
|
landlord_id |
Landlord issuing the invitation. |
|
email |
Recipient address. |
|
token |
Unique invitation token. |
|
status |
Pending, accepted or expired. |
|
expires_at |
Invitation expiry time. |
1. Enter the client email.
2. Confirm the email is correct.
3. Send the invitation.
4. TenantInvitationMail delivers the unique link.
5. Client opens the link before expiry.
6. Client creates or confirms the account.
7. Invitation becomes Accepted and the portfolio link is created.
|
|
Invitation token security Tokens should be single-use, time-limited, unpredictable and invalidated after acceptance or replacement. |
10 Invitation Monitoring, Expiry and Resend
|
Status |
Meaning |
|
Pending |
Sent but not accepted. |
|
Accepted |
Client completed the invitation flow. |
|
Expired |
Expiry date passed without valid acceptance. |
|
☐ |
Pending invitation is associated with the correct landlord. |
|
☐ |
The recipient email has not been entered incorrectly. |
|
☐ |
The token has not expired or already been used. |
|
☐ |
A resend creates or rotates the token according to policy. |
|
☐ |
Duplicate invitations do not create duplicate Tenant records. |
11 Phase 2 - Client Self-Registration
|
STEP |
Register a New Client Account Primary user: Client |
Auth\TenantRegistrationController and API\Mobile\Auth\TenantAuthController@register handle web and mobile registration.
1. Enter first name, last name, email, password and phone.
2. Select or confirm country.
3. Review the applicable terms and privacy information.
4. Submit registration.
5. Receive TenantEmailVerificationNotification.
6. Verify the email.
7. Create or activate User and Tenant records under the deployed sequence.
8. Create the client wallet through the configured tenant-wallet creation service.
|
|
Wallet creation method requires confirmation The supplied scenario refers to a LandlordWalletService equivalent for clients. Confirm the actual tenant wallet service, event or observer used in production. |
12 Email Verification and Account Activation
|
☐ |
Verification link belongs to the correct User. |
|
☐ |
Link is time-limited and single-use where configured. |
|
☐ |
Unverified accounts have restricted sensitive actions. |
|
☐ |
Verification does not by itself mean KYC Verified. |
|
☐ |
Failed and repeated attempts are monitored. |
|
|
Separate account verification from identity verification Email verification confirms control of an email address. KYC confirms identity under a separate process. |
13 Complete the Client Profile
|
STEP |
Update Personal, Employment and Emergency Information Primary user: Client |
|
Profile area |
Information |
|
Personal |
Date of birth, nationality, gender and marital status. |
|
Employment |
Employer, job title, annual income and employment type. |
|
Emergency contact |
Name and phone. |
|
Photo |
Upload to tenant-profiles storage. |
|
Password |
Change through updatePassword or mobile changePassword. |
|
Notifications |
Choose authorised communication channels. |
|
☐ |
Names match identity documents where required. |
|
☐ |
Phone and email are current. |
|
☐ |
Income frequency and currency are clear. |
|
☐ |
Emergency contact is accurate and consented where required. |
|
☐ |
Profile photo is appropriate and safely stored. |
|
☐ |
Password change requires the appropriate authentication step. |
14 Profile Photo and File Controls
Tenant\ProfileController@updatePhoto and the mobile profile controller manage photo updates.
|
☐ |
Validate image type and size. |
|
☐ |
Remove embedded metadata where appropriate. |
|
☐ |
Store outside public writable paths or use protected delivery. |
|
☐ |
Delete or replace the previous photo according to retention policy. |
|
☐ |
Do not treat a profile photo as formal KYC evidence unless the KYC process explicitly uses it. |
15 Phase 2 - Submit KYC Documents
|
STEP |
Submit Identity Verification Primary user: Client |
TenantKycController and the mobile KYC controller allow the client to submit government ID, proof of address and selfie or liveness evidence.
|
Document type |
Purpose |
|
Government ID |
Passport, national ID or driving licence according to accepted rules. |
|
Proof of address |
Utility bill, bank statement or configured evidence. |
|
Selfie / liveness |
Image or provider process used to compare the live person with identity evidence. |
1. Open KYC Verification.
2. Review accepted document types and quality instructions.
3. Upload the government ID.
4. Upload proof of address.
5. Complete the selfie or liveness step.
6. Review the submission.
7. Submit for processing.
8. Track status through mobile status or the web view.
TenantKycDocument stores the evidence. TenantKycVerification stores processing and result information. KycVerificationService@processSubmission orchestrates the configured provider or review process.
|
|
Identity verification provider The supplied scenario permits OpenAIService or a third-party KYC provider. Confirm the production provider, country coverage, liveness method, data transfer and retention before go-live. |
16 KYC Status and Review
|
KYC status |
Meaning |
|
Pending |
Submission received or under review. |
|
Verified |
Identity review approved. |
|
Rejected |
Submission declined with a reason and resubmission process where permitted. |
TenantKycSubmittedNotification informs the landlord. TenantKycApprovedNotification and TenantKycRejectedNotification inform the client.
|
☐ |
Documents belong to the correct client. |
|
☐ |
ID is readable and not expired under policy. |
|
☐ |
Name and date of birth match the profile. |
|
☐ |
Proof of address is recent enough under policy. |
|
☐ |
Selfie or liveness result is reviewed. |
|
☐ |
Provider result and human decision are recorded. |
|
☐ |
Rejection reason is clear and appropriate. |
|
|
KYC approval is not tenancy approval Verified identity does not prove affordability, suitability, payment reliability or entitlement to a particular property. |
17 KYC Privacy, Retention and Resubmission
|
☐ |
Restrict document access to authorised KYC users. |
|
☐ |
Encrypt evidence in transit and at rest. |
|
☐ |
Log views, downloads, decisions and exports. |
|
☐ |
Define retention for approved, rejected and withdrawn submissions. |
|
☐ |
Avoid placing ID numbers or images in notifications. |
|
☐ |
Provide a correction or resubmission route. |
|
☐ |
Delete temporary provider files according to the configured data agreement. |
Figure 3. Client onboarding, KYC and screening flow
18 Phase 3 - Initiate Client Screening
|
STEP |
Open the Screening Case Primary user: Landlord / Screening Analyst |
TenantScreeningController provides background checks, credit checks, references, consolidated screening data, AI score, statistics and export.
|
☐ |
Client consent and lawful purpose are confirmed. |
|
☐ |
The landlord is authorised to screen this client. |
|
☐ |
Identity and KYC information are sufficient for the provider. |
|
☐ |
The relevant property or lease context is known. |
|
☐ |
The client can correct inaccurate personal information. |
19 Background Check
initiateBackgroundCheck triggers the configured criminal-record and eviction-history process. Results are stored in TenantScreeningResult.
|
|
Jurisdiction and fairness The availability and lawful use of criminal or eviction information varies. Apply the current local rules, relevance period, accuracy requirements and individual review process. |
20 Credit Check
initiateCreditCheck requests the configured credit score, payment history and outstanding-debt information.
|
☐ |
Correct identity and consent are used. |
|
☐ |
The credit bureau and permissible purpose are configured. |
|
☐ |
The report date and source are recorded. |
|
☐ |
Currency and debt amounts are understood. |
|
☐ |
The client has a process to dispute inaccurate information. |
|
☐ |
The result is not used outside the authorised decision. |
21 Reference Checks
sendReferenceRequests contacts the client references. updateReference records received feedback.
|
Reference control |
Requirement |
|
Contact permission |
Client provided or authorised the reference contact. |
|
Identity |
Confirm the responder is the intended reference. |
|
Structured questions |
Use consistent and relevant questions. |
|
Evidence |
Record date, channel and response. |
|
Privacy |
Do not request unnecessary sensitive information. |
|
Decision use |
Consider reliability and possible bias. |
22 AI Screening Score and Recommendation
|
STEP |
Calculate and Review the Screening Score Primary user: Screening Analyst / landlord |
calculateScore uses OpenAIService to analyse the available screening information and produce a 0-100 score, Low / Medium / High risk level and an Approve / Conditional / Reject recommendation.
|
AI output |
Meaning |
|
Screening score |
Model-generated summary score. |
|
Risk level |
Low, medium or high risk classification. |
|
Recommendation |
Approve, conditional or reject suggestion. |
|
Consolidated data |
getScreeningData combines background, credit and references. |
|
|
AI is advisory The landlord must review the original evidence, affordability policy, applicable law and individual circumstances. Do not use an AI score as the sole reason for a decision. |
HighRiskTenantNotification informs the landlord when the configured high-risk condition is met. statistics and export support oversight and reporting.
23 Screening Decision Record and Audit
|
☐ |
Screening sources and dates are recorded. |
|
☐ |
Consent and permissible purpose are retained. |
|
☐ |
AI model or service version is traceable where available. |
|
☐ |
Human reviewer records the decision and reason. |
|
☐ |
Conditions are specific and proportionate. |
|
☐ |
The client receives the appropriate application decision through the listing workflow. |
|
☐ |
Screening evidence is retained only as long as required. |
24 Phase 4 - Apply for a Property Listing
|
STEP |
Submit a ListingApplication Primary user: Client |
|
Field |
Purpose |
|
listing_id |
Property listing selected by the client. |
|
message |
Cover note or relevant context. |
|
supporting documents |
Payslips, references, ID or configured evidence. |
|
status |
Pending at submission. |
1. Open the property listing.
2. Review rent, property details and requirements.
3. Select Apply.
4. Enter the message.
5. Upload required supporting documents.
6. Review the application.
7. Submit and record the reference.
NewTenantApplicationNotification informs the landlord.
|
|
Application documents may overlap with KYC Reuse or reference approved documents where lawful and secure rather than creating unnecessary duplicate copies. |
25 Landlord Reviews the Listing Application
|
STEP |
Approve or Reject a ListingApplication Primary user: Leasing Officer / landlord |
|
☐ |
Listing is active and available. |
|
☐ |
Client profile and contact are complete. |
|
☐ |
KYC status is reviewed according to policy. |
|
☐ |
Screening evidence is current and authorised. |
|
☐ |
Income and affordability are assessed consistently. |
|
☐ |
Supporting documents are complete. |
|
☐ |
Any conflict or duplicate application is understood. |
aiApprovalSuggestions can provide AI-assisted application suggestions. The authorised landlord user decides.
|
Action |
Notification |
|
Approve |
ListingApplicationApprovedNotification to the client. |
|
Reject |
ListingApplicationRejectedNotification to the client. |
|
|
Reasoned decision Use consistent, lawful and documented criteria. Provide a suitable rejection explanation or review route where required. |
26 Phase 5 - Assign a Lease to the Client
|
STEP |
Create the Lease Primary user: Landlord / Leasing Officer |
LeaseController@store creates the pending lease. fetchTenantByUniqueCode and searchTenants locate the correct client.
1. Open Create Lease.
2. Find the client by unique code, name or email.
3. Confirm the correct Tenant and User record.
4. Select property and unit.
5. Enter dates, rent, currency, deposit and payment frequency.
6. Generate the payment schedule.
7. Save the lease as Pending.
8. Request signature.
9. Send LeaseAssignedNotification to the client.
10. Receive LeaseCreatedLandlordNotification as confirmation.
|
|
Identity before assignment A unique code accelerates search but should not be the only identity check where two people or accounts could be confused. |
27 Tenant Unique Code System
Every client has a unique_code such as TEN-ABC123. It supports fast portfolio search and lease assignment without relying only on email.
|
Use |
Controller / relationship |
|
Lease assignment |
LeaseController@fetchTenantByUniqueCode. |
|
Search |
TenantController@search. |
|
CRM conversion |
CrmPropertyLink can connect the CRM lead and Client record. |
|
Portfolio linking |
Client shares the code with an authorised landlord. |
|
☐ |
Code is unique and non-guessable enough for its purpose. |
|
☐ |
Code is not treated as a password or authentication secret. |
|
☐ |
Landlord confirms the client name and contact before linking. |
|
☐ |
Code changes or account merges preserve relationships. |
28 Client Lease Dashboard
|
STEP |
View the Lease and Payment Schedule Primary user: Client |
Tenant\LeaseController and Mobile\LeaseController show active and historical leases.
|
Area |
What the client can access |
|
Lease detail |
Property, unit, dates, rent, deposit and terms. |
|
Payment schedule |
Due dates and amounts. |
|
Payment history |
Paid, overdue and upcoming records. |
|
Health score |
Lease health based on payment behaviour and compliance. |
|
Documents |
Signed lease PDF and other authorised files. |
|
Print / download |
Lease summary and document download. |
|
|
Health score explanation The client should understand the factors used, the date of the score and how to correct inaccurate data. |
29 Phase 6 - Client Main Dashboard
|
STEP |
Use the Client Dashboard Primary user: Client |
|
Dashboard area |
Purpose |
|
Active lease summary |
Property, rent and next due date. |
|
Wallet balance |
Available wallet amount and currency. |
|
Upcoming payments |
Rent and other authorised obligations. |
|
Maintenance |
Recent requests and status. |
|
Notifications |
Unread notification count. |
|
Quick actions |
Pay Rent, Submit Maintenance and View Lease. |
|
Stats |
Total paid, overdue and upcoming. |
|
Recent activity |
Latest platform actions. |
|
|
Dashboard data should reconcile Amounts and statuses should come from verified underlying lease, payment, wallet and maintenance records rather than separate manual summaries. |
30 Phase 7 - Pay Rent
|
STEP |
Pay a Rent Instalment Primary user: Client |
Tenant\RentPaymentController and Mobile\RentPaymentController support gateway, wallet and bank-transfer payment methods.
|
Method |
Process |
|
Gateway |
Flutterwave, Stripe, Revolut, Paystack or Squad session and verification. |
|
Wallet |
wallet->deductFunds, LandlordPayout creation and ProcessLandlordPayout. |
|
Bank transfer |
Upload proof and landlord verification. |
LeasePaid confirms the client payment, LeasePaymentReceivedNotification informs the landlord and TenantPaymentConfirmation provides the detailed receipt. downloadReceipt and downloadPdfReceipt provide client receipts.
|
|
Verified payment only Do not mark rent Paid from a browser redirect or uploaded receipt alone. Verify the provider or bank evidence and prevent duplicate application. |
31 Payment History, Reminders and Behaviour
|
☐ |
Payment amount and currency match the schedule. |
|
☐ |
Paid date and provider reference are stored. |
|
☐ |
Partial and overdue rules are defined. |
|
☐ |
Reminder excludes already paid records. |
|
☐ |
Receipt is linked to the correct client and lease. |
|
☐ |
Payment behaviour score uses transparent, accurate records. |
Figure 4. Client payments, wallet and maintenance flow
32 Phase 8 - Client Wallet
|
STEP |
Use the Leaseora Wallet Primary user: Client |
|
Wallet area |
Purpose |
|
Balance |
View available balance in configured currencies. |
|
Top-up |
Gateway, saved card, SEPA or virtual account according to country and configuration. |
|
Payments |
Pay rent, services and maintenance charges. |
|
Withdrawal |
Withdraw to a verified TenantBankAccount. |
|
Transactions |
View full history and receipts. |
|
Statistics |
Detailed wallet statistics and trends. |
|
Health score |
Wallet behaviour and risk indicator. |
|
|
Country and provider availability Top-up, SEPA, virtual account and withdrawal methods depend on configured providers, supported countries, account status and verification. |
33 Client Bank Accounts and Withdrawals
|
STEP |
Add and Verify a Withdrawal Account Primary user: Client |
1. Open Bank Accounts.
2. Select Add Bank Account.
3. Choose country and bank.
4. Enter account details.
5. Verify the account number through the configured provider.
6. Confirm account name.
7. Save the account.
8. Set the primary account if appropriate.
|
|
Account ownership Do not allow payout to an unverified or unrelated account without the approved exception and fraud review process. |
34 Phase 9 - Client Maintenance Requests
|
STEP |
Submit and Track a Maintenance Request Primary user: Client |
Tenant\Shared\MaintenanceController, TenantMaintenancePortalController and the mobile maintenance controller support request creation and tracking.
1. Enter title and description.
2. Choose category and priority.
3. Confirm property and unit.
4. Upload safe and relevant photos.
5. Submit the request.
6. Track status changes.
7. Add comments or updates.
8. Rate the completed job.
9. Pay an approved maintenance charge through gateway, wallet or verified bank transfer.
MaintenanceStatusChanged informs the client when the configured status changes.
|
|
Emergency process A maintenance request is not a substitute for emergency services, evacuation or immediate utility isolation. Display the correct local emergency instructions. |
35 Phase 10 - Client Documents
|
STEP |
Manage Client Documents Primary user: Client |
Tenant\DocumentController supports index, upload, download and destroy. Mobile lease documents provide mobile access.
|
Document category |
Examples |
|
Lease agreements |
Signed lease PDFs and amendments. |
|
Payment receipts |
Rent and other payment evidence. |
|
KYC documents |
Restricted identity evidence. |
|
Maintenance reports |
Completion or charge documents. |
|
Legal documents |
WeBuild, property purchase, land sale or other contracts. |
|
☐ |
Client owns or is authorised for the document. |
|
☐ |
Document is stored under the correct category. |
|
☐ |
KYC evidence has restricted access. |
|
☐ |
Downloads are logged where required. |
|
☐ |
Destroy respects legal and audit retention. |
|
☐ |
notifyLandlord does not expose confidential contents unnecessarily. |
36 Phase 11 - Client Notifications
|
STEP |
Review and Manage Notifications Primary user: Client |
Tenant\NotificationController and the mobile notification controller provide list, mark read and mark all read functions.
|
Notification category |
Examples |
|
Lease |
Assigned, activated, renewal and termination. |
|
Payment |
Due, confirmed, overdue and receipt. |
|
Maintenance |
Assigned, in progress and completed. |
|
Documents |
Ready to sign or signed. |
|
KYC |
Submitted, approved or rejected. |
|
Property services |
WeBuild progress, purchase and land-sale status. |
|
Wallet |
Credited, withdrawal and SEPA expiry. |
|
|
Notification is not the legal record The underlying lease, payment, KYC or application record is authoritative. Notifications summarise changes and may be delayed or disabled by preference. |
37 Notification Preferences
Tenant\ProfileController@updateNotificationPreferences controls email, SMS and push toggles per event type.
|
☐ |
Mandatory legal or security communications remain deliverable where permitted. |
|
☐ |
Marketing communication is separated from transactional communication. |
|
☐ |
Push token and SMS number belong to the client. |
|
☐ |
Preference changes are logged. |
|
☐ |
Sensitive data is not placed in message previews. |
38 Phase 12 - Profile and Settings
|
STEP |
Manage Account Settings Primary user: Client |
|
Setting |
Effect |
|
Currency |
Controls displayed amounts and wallet context. |
|
Language |
Controls supported interface language. |
|
Notifications |
Controls channel preferences. |
|
Privacy |
Controls available privacy choices. |
|
Payment methods |
Shows connected methods. |
|
Password |
Changes login credential. |
|
2FA |
Adds step-up protection for wallet or sensitive actions. |
|
Account deletion |
Starts a GDPR or account-closure request. |
|
|
Account deletion is a request, not automatic erasure The platform may need to retain leases, payments, invoices, KYC decisions, fraud records and legal evidence. The deletion workflow should explain what can be deleted, anonymised or retained. |
39 Account Security and Two-Factor Authentication
|
☐ |
Use a strong unique password. |
|
☐ |
Require current password or step-up check for password change. |
|
☐ |
Use 2FA or transaction PIN for wallet actions. |
|
☐ |
Invalidate sessions after password reset where appropriate. |
|
☐ |
Notify the client of important security changes. |
|
☐ |
Provide recovery codes or a controlled recovery process. |
|
☐ |
Monitor suspicious login, OTP and withdrawal attempts. |
40 Phase 13 - Lease Angel Rent Financing
|
STEP |
Apply for Rent Financing Primary user: Client |
Tenant\LeaseAngelController and Mobile\LeaseAngelController support the financing flow in which the landlord receives full rent upfront and the client repays the platform in instalments.
|
Notification |
Purpose |
|
LeaseAngelScheduleCreated |
Repayment schedule created. |
|
LeaseAngelScheduleReminder |
Upcoming repayment. |
|
LeaseAngelPaymentFailed |
Payment attempt failed. |
|
|
Financing is subject to approval Application does not guarantee financing. Terms, fees, affordability, fraud checks and applicable credit rules must be clear. |
41 Phase 14 - Mortgage Applications
|
STEP |
Apply for a Mortgage Primary user: Client |
1. Browse available mortgage products.
2. Review amount, rate, term and eligibility.
3. Complete the AI-assisted eligibility check.
4. Enter personal, employment and financial information.
5. Upload required documents.
6. Submit the application.
7. Track the status.
MortgageApplicationReceivedNotification confirms submission and MortgageApplicationStatusUpdateNotification communicates status changes.
|
|
AI eligibility is preliminary A score or recommendation does not guarantee mortgage approval or replace credit, affordability, valuation and legal review. |
42 Phase 15 - Property Purchases
|
STEP |
Browse and Purchase a Property Primary user: Client / buyer |
1. Browse active sale listings.
2. Open the property detail.
3. Submit a purchase offer.
4. Review counter-offers.
5. Receive approval where accepted.
6. Pay the 10% deposit through an available method.
7. Pay remaining instalments.
8. Track completion and documents.
|
Notification |
Purpose |
|
SaleOfferApprovedNotification |
Offer approved. |
|
PropertyDepositConfirmedNotification |
Deposit confirmed. |
|
PropertySaleCompletedTenantNotification |
Sale completed. |
43 Phase 16 - WeBuild Bookings
|
STEP |
Book and Track a WeBuild Unit Primary user: Client |
1. Browse published projects.
2. Open the project and available unit.
3. View BIM or 3D content where available.
4. Select the unit and build plan.
5. Submit the booking.
6. Make the down payment.
7. Pay scheduled instalments.
8. Review construction updates.
9. Receive project-completion communication.
|
Notification |
Purpose |
|
WeBuildBookingConfirmationNotification |
Booking confirmed. |
|
WeBuildConstructionUpdateNotification |
Construction progress update. |
|
WeBuildProjectCompletionNotification |
Project completed. |
44 Phase 17 - Land Purchases
|
STEP |
Browse, Apply and Pay for Land Primary user: Client / buyer |
1. Browse published parcels.
2. Review parcel details and converted price.
3. Contact the owner where needed.
4. Submit a purchase application.
5. Receive approval or rejection.
6. Pay outright or by instalment.
7. Download agreements and receipts.
8. Receive completion notification.
|
Notification |
Purpose |
|
LandApplicationApprovedNotification |
Application approved. |
|
LandPaymentReceivedNotification |
Payment confirmed. |
|
LandSaleCompletedNotification |
Sale completed. |
45 Phase 18 - Landlord Client Analytics
|
STEP |
Review Client Analytics Primary user: Landlord / portfolio manager |
|
Metric |
Purpose |
|
Payment behaviour |
On-time, late and overdue trends. |
|
Occupancy |
Active client and property occupancy context. |
|
Retention |
Renewals and continued portfolio relationship. |
|
Average lease duration |
Typical active lease length. |
|
Overdue patterns |
Frequency, amount and concentration of overdue payments. |
|
Lease health |
Payment and compliance summary. |
|
Maintenance behaviour |
Volume, category and resolution history. |
|
Screening distribution |
Risk levels and decision outcomes under authorised reporting. |
|
|
Analytics require definitions Document period, currency, active-client definition, partial payment treatment, transferred leases, former clients and excluded records. |
46 Landlord Bulk Client Operations
|
STEP |
Perform Authorised Bulk Actions Primary user: Landlord / Client Administrator |
|
Bulk action |
Use |
|
Notifications |
Send authorised messages to selected clients. |
|
Export |
Export selected client data. |
|
Status update |
Update active or inactive status where allowed. |
|
Bulk invite |
Upload CSV and create invitations. |
|
Other bulkAction |
Configured assign, tag or portfolio operation where implemented. |
|
☐ |
Selection is reviewed before execution. |
|
☐ |
Each client belongs to the landlord scope. |
|
☐ |
The action has an audit record. |
|
☐ |
Bulk messages respect communication preference and purpose. |
|
☐ |
CSV errors are reported per row. |
|
☐ |
Duplicate email or existing User handling is defined. |
47 CRM Communication Integration
|
STEP |
Log Client Communications Primary user: Authorised CRM / client-service user |
CrmCommunicationController@store logs email, phone, WhatsApp, SMS and other authorised communications. CrmPropertyLink connects a converted CRM lead to the Client record.
|
CRM capability |
Purpose |
|
Communication timeline |
Chronological record of client contact. |
|
Channel logging |
Email, phone, WhatsApp, SMS and in-person. |
|
Sentiment analysis |
AI-assisted communication tone analysis. |
|
Property link |
Connect lead, property and Client records. |
|
Audit |
Identify user, time, channel and action. |
|
|
Sentiment is advisory AI sentiment can misread context, language, sarcasm or culture. Do not use it alone for enforcement, blacklisting or credit decisions. |
48 Client Blacklisting
|
STEP |
Blacklist or Remove a Client from Blacklist Primary user: Authorised landlord user |
TenantController@blacklist sets the landlord-specific Client status to Blacklisted and creates or uses TenantBlacklist. removeFromBlacklist reverses the landlord blacklist status.
|
☐ |
Reason is specific, accurate and supported by evidence. |
|
☐ |
Decision is authorised under policy and law. |
|
☐ |
The scope is limited to the landlord relationship unless a platform action is separately justified. |
|
☐ |
Client is notified through TenantBlacklistedNotification where appropriate. |
|
☐ |
Review, correction and removal process is available. |
|
☐ |
Historical records remain intact. |
|
|
Blacklisting is high impact Do not blacklist automatically from one late payment, complaint, protected characteristic or unverified allegation. Apply proportional, consistent and reviewable criteria. |
49 Blacklisting, Suspension and Inactive Status Are Different
|
State |
Owner |
Effect |
|
Inactive |
Landlord or business workflow |
No current active relationship or service state under the deployed definition. |
|
Blacklisted |
Landlord-specific decision |
Client cannot submit new listing applications to that landlord. |
|
Suspended |
SuperAdmin platform action |
Platform account access is restricted. |
|
KYC Rejected |
KYC workflow |
Identity submission was not approved; resubmission may apply. |
|
|
Do not merge unrelated statuses A KYC rejection should not automatically become a blacklist, and a landlord blacklist should not automatically suspend the platform account. |
50 Phase 19 - SuperAdmin Client Oversight
|
STEP |
Use Platform-Wide Tenant Management Primary user: SuperAdmin |
|
Action |
Purpose |
|
index |
View clients across landlords. |
|
show |
View an authorised full profile. |
|
suspend |
Restrict a client account. |
|
activate |
Restore an authorised suspended account. |
|
impersonate |
Enter a controlled support session as the client. |
|
exportAll |
Export platform-wide client data under strict permission. |
|
|
Platform-wide access is exceptional SuperAdmin access should be role-restricted, purpose-limited and fully audited. Landlords should not be able to see unrelated clients through platform functions. |
51 SuperAdmin KYC Management
SuperAdmin\TenantManagement\KycController supports platform-wide KYC review, verification, rejection and statistics.
|
☐ |
Reviewer is authorised for the client country and provider. |
|
☐ |
Landlord and SuperAdmin decision precedence is defined. |
|
☐ |
Reason and evidence are recorded. |
|
☐ |
Client receives the correct result. |
|
☐ |
Approval-rate statistics do not expose personal data. |
52 Controlled Client Impersonation
impersonate supports support troubleshooting but creates significant privacy and security risk.
|
☐ |
Impersonation requires a high-privilege role. |
|
☐ |
A reason or support ticket is required. |
|
☐ |
The client or policy authorises the support process where required. |
|
☐ |
Start and end times are logged. |
|
☐ |
All actions are marked as impersonated. |
|
☐ |
Sensitive payment or security actions are blocked or require separate approval. |
|
☐ |
The session is clearly visible to the support user. |
|
☐ |
No client password is disclosed. |
|
|
Never use impersonation for convenience Use it only for authorised support, diagnostics or compliance functions. Ordinary account management should use administrative tools without entering the client session. |
53 Phase 20 - Tenant Mobile App
|
STEP |
Use the Full Client Mobile Experience Primary user: Client |
|
Mobile feature |
Purpose |
|
Dashboard |
Lease, wallet, upcoming payments and activity. |
|
Payments |
Gateway, wallet and bank-transfer rent payment. |
|
Maintenance |
Create and track requests. |
|
Lease |
View, sign and download. |
|
Listings |
Browse rental properties. |
|
WeBuild |
Browse, book, pay and track. |
|
Land |
Browse, apply and pay. |
|
Wallet |
Top-up, withdraw, transfer and history. |
|
Mortgage |
Browse, apply, track and pay. |
|
Property purchase |
Offers, deposit and instalments. |
|
Notifications |
Central notification centre. |
|
Profile |
Profile, KYC and settings. |
54 Mobile Authentication, OTP and Biometric Controls
API\Mobile\Auth\TenantAuthController supports login, logout, refreshToken, forgotPassword, resetPassword and verifyOtp. Biometric support may protect access on supported devices.
Figure 5. Mobile authentication and sensitive-action flow
|
|
Biometric is not server authentication by itself Biometric typically unlocks local credentials or a protected session. The server must still validate tokens, permissions and step-up requirements. |
55 Client Status Lifecycle
Figure 6. Client account, KYC and portfolio status lifecycles
|
|
Confirm exact production enums The supplied scenario uses status = active, inactive, blacklisted and kyc_status = pending, verified, rejected. It also describes under_review and SuperAdmin suspension. Confirm exact fields and transition rules. |
56 Notifications and Mail Reference
|
Notification / mail |
Recipient |
Trigger |
|
TenantInvitationNotification |
Client |
Invitation to join platform. |
|
TenantInvitationMail |
Client |
Invitation link. |
|
TenantEmailVerificationNotification |
Client |
Verify registration email. |
|
TenantKycSubmittedNotification |
Landlord |
KYC submitted. |
|
TenantKycApprovedNotification |
Client |
KYC approved. |
|
TenantKycRejectedNotification |
Client |
KYC rejected. |
|
HighRiskTenantNotification |
Landlord |
High-risk screening result. |
|
NewTenantApplicationNotification |
Landlord |
New listing application. |
|
ListingApplicationApprovedNotification |
Client |
Listing application approved. |
|
ListingApplicationRejectedNotification |
Client |
Listing application rejected. |
|
LeaseAssignedNotification |
Client |
Lease assigned. |
|
LeaseActivatedNotification |
Client |
Lease activated. |
|
LeasePaid |
Client |
Rent confirmed. |
|
LeasePaymentReceivedNotification |
Landlord |
Rent received. |
|
TenantPaymentConfirmation |
Client |
Detailed receipt. |
|
LeasePaymentReminderNotification |
Client |
Upcoming rent reminder. |
|
LeaseRenewalRequestedNotification |
Landlord |
Renewal requested. |
|
LeaseRenewalApprovedNotification |
Client |
Renewal approved. |
|
MaintenanceStatusChanged |
Client |
Maintenance update. |
|
WalletCreditedNotification |
Client |
Wallet credited. |
|
WalletWithdrawalNotification |
Client |
Withdrawal initiated. |
|
TenantBlacklistedNotification |
Client |
Landlord blacklist decision. |
|
TenantSepaExpiryNotification |
Client |
SEPA mandate expiring. |
57 Backend Models Reference
|
Model |
Purpose |
|
Tenant |
Core client model. |
|
TenantProfile |
Extended profile. |
|
TenantInvitation |
Invitation token and status. |
|
TenantKycDocument |
KYC evidence. |
|
TenantKycVerification |
KYC result. |
|
TenantScreening |
Screening case. |
|
TenantScreeningResult |
Background or credit result. |
|
TenantReference |
Reference details and feedback. |
|
TenantBlacklist |
Landlord-specific blacklist. |
|
TenantDocument |
Client document library. |
|
TenantBankAccount |
Withdrawal bank account. |
|
TenantMortgageEligibilityScore |
Mortgage eligibility score. |
|
ListingApplication |
Property rental application. |
|
User |
Account and authentication. |
|
Wallet |
Client wallet. |
58 Controllers Reference
|
Controller |
Purpose |
|
TenantController - Landlord Shared |
Portfolio, create, invite, profile, analytics, bulk actions and blacklist. |
|
TenantScreeningController |
Background, credit, references, AI score, stats and export. |
|
TenantKycController - Client |
KYC submission. |
|
Landlord\TenantKycController |
KYC verify or reject. |
|
SuperAdmin\TenantManagement\TenantController |
Platform management, suspension, impersonation and export. |
|
SuperAdmin\TenantManagement\KycController |
Platform KYC oversight. |
|
Tenant\DashboardController |
Client web dashboard. |
|
Tenant\ProfileController |
Profile, password, photo and notifications. |
|
Tenant\SettingsController |
Currency, language, privacy and payment methods. |
|
Tenant\LeaseController |
Lease view, renewal, documents and health. |
|
Tenant\RentPaymentController |
Rent payment and history. |
|
Tenant\DocumentController |
Document management. |
|
Tenant\NotificationController |
Notification centre. |
|
Tenant\LeaseAngelController |
Rent financing. |
|
Tenant\MortgageApplicationController |
Mortgage application. |
|
TenantWalletController |
Wallet and bank accounts. |
|
TenantMaintenancePortalController |
Maintenance, payment and rating. |
|
Tenant\Shared\MaintenanceController |
Web maintenance request. |
|
API\Mobile\Tenant\DashboardController |
Mobile dashboard. |
|
API\Mobile\Tenant\ProfileController |
Mobile profile. |
|
API\Mobile\Tenant\KycController |
Mobile KYC. |
|
API\Mobile\Tenant\MaintenanceController |
Mobile maintenance. |
|
API\Mobile\Tenant\NotificationController |
Mobile notifications. |
|
API\Mobile\Auth\TenantAuthController |
Mobile authentication, OTP and tokens. |
|
MortgageMobileController |
Mortgage mobile. |
|
PropertySaleMobileController |
Property-sale mobile. |
|
TenantWeBuildController |
WeBuild client flow. |
|
LandBrowsingController / LandMobileController |
Land browse, apply and pay. |
59 Services, Jobs and Integration Reference
|
Component |
Purpose |
|
KycVerificationService |
Processes KYC submission and provider workflow. |
|
TenantScreeningService |
Orchestrates screening. |
|
OpenAIService |
AI screening score, risk or eligibility support. |
|
CurrencyService |
Client currency context and conversion. |
|
ExchangeRateService |
Exchange-rate retrieval. |
|
FeeCalculationService |
Payment service fees. |
|
LandlordWalletService or tenant equivalent |
Wallet creation and management; production implementation to confirm. |
|
ProcessLandlordPayout |
Landlord payout after client payment. |
|
ProcessTenantPayoutJob |
Client wallet withdrawal. |
|
CrmPropertyLink |
Connects CRM lead and Client record. |
60 Daily, Weekly and Monthly Operating Procedures
|
Frequency |
Recommended activities |
|
Daily |
Review invitations, KYC submissions, listing applications, high-risk screening alerts, overdue payments, maintenance escalations and support cases. |
|
Weekly |
Review expiring invitations, KYC backlog, screening outcomes, lease expiries, notification failures, wallet exceptions and blacklist reviews. |
|
Monthly |
Reconcile client counts, active leases, payments, wallet and maintenance; review retention, exports, CRM communication and analytics. |
|
Quarterly |
Review screening criteria, KYC provider, access rights, mobile authentication, notification templates, blacklist policy and data retention. |
61 Worked Example 1 - Landlord Invitation to Active Lease
|
|
Scenario A real estate company has approved a prospective renter after an offline viewing and wants to onboard the person into Leaseora. |
|
Stage |
What happens |
|
1. Invite |
Landlord sends TenantInvitationMail. |
|
2. Accept |
Client opens the valid link and creates the account. |
|
3. Verify email |
Client confirms email control. |
|
4. Profile |
Client adds personal, employment and emergency data. |
|
5. KYC |
Client uploads ID, proof of address and selfie. |
|
6. Review |
KYC becomes Verified. |
|
7. Screening |
Landlord runs credit, background and references with consent. |
|
8. Decision |
Human reviewer approves the client. |
|
9. Unique code |
Client record provides TEN-style unique code. |
|
10. Lease |
Landlord creates a Pending lease using the code. |
|
11. Sign |
Client signs the lease. |
|
12. Activate |
Lease activates and the unit becomes occupied. |
|
13. Dashboard |
Client sees rent, next due date and documents. |
|
14. Payment |
Client pays rent and downloads the receipt. |
62 Worked Example 2 - Listing Application and Screening
|
|
Scenario A self-registered client applies for a listed apartment and has not yet completed full screening. |
|
Stage |
What happens |
|
1. Register |
Client self-registers and verifies email. |
|
2. Profile |
Client completes profile. |
|
3. KYC |
KYC is submitted and approved. |
|
4. Apply |
ListingApplication is created. |
|
5. Notify |
Landlord receives NewTenantApplicationNotification. |
|
6. Consent |
Landlord confirms screening consent and purpose. |
|
7. Checks |
Credit, background and reference checks run. |
|
8. AI support |
OpenAIService returns score, risk and recommendation. |
|
9. Human review |
Landlord reviews source evidence and affordability. |
|
10. Approve |
Application is approved and client notified. |
|
11. Lease |
Landlord creates and assigns the lease. |
63 Worked Example 3 - Client Uses Multiple Modules
|
|
Scenario An existing rental client later books a WeBuild unit and applies for a mortgage using the same Leaseora account. |
|
Stage |
What happens |
|
1. Existing identity |
Client profile, KYC and wallet already exist. |
|
2. WeBuild |
Client browses the project, selects a unit and books. |
|
3. Payment |
Client pays the down payment and instalments. |
|
4. Progress |
Construction updates appear in the same notification centre. |
|
5. Mortgage |
Client browses mortgage products and checks eligibility. |
|
6. Application |
Personal and employment data supports the mortgage form subject to consent and freshness. |
|
7. Status |
Client tracks the mortgage application. |
|
8. Documents |
Contracts, receipts and mortgage files appear in authorised document areas. |
|
9. CRM |
Company communications remain linked to the same client relationship. |
64 Privacy, GDPR and Data Subject Controls
|
☐ |
Provide clear privacy information at registration and KYC. |
|
☐ |
Record lawful purpose and consent where required. |
|
☐ |
Restrict KYC, screening, income and bank data. |
|
☐ |
Allow profile correction and notification preference management. |
|
☐ |
Provide an account-deletion or data-rights request process. |
|
☐ |
Retain legal, financial and security evidence only under documented rules. |
|
☐ |
Log exports, impersonation and sensitive access. |
|
☐ |
Separate landlord data responsibility from platform responsibility. |
|
☐ |
Protect international data transfers and third-party provider access. |
|
|
Data subject request does not override mandatory retention Explain which data can be deleted, anonymised, corrected, exported or retained because of lease, payment, tax, fraud, dispute or legal obligations. |
65 Implementation and Onboarding Checklist
Identity and onboarding
|
☐ |
Client status and KYC status enums confirmed. |
|
☐ |
Invitation expiry, resend and duplicate handling configured. |
|
☐ |
Email verification tested. |
|
☐ |
Tenant wallet-creation mechanism confirmed. |
|
☐ |
Profile fields and required fields approved. |
|
☐ |
Unique-code generation and search tested. |
KYC and screening
|
☐ |
KYC provider, countries and accepted documents configured. |
|
☐ |
Consent and retention process documented. |
|
☐ |
Landlord and SuperAdmin review authority defined. |
|
☐ |
Credit and background provider configured. |
|
☐ |
Reference templates approved. |
|
☐ |
AI score use, model output and human review documented. |
Lease and ongoing services
|
☐ |
Listing application criteria configured. |
|
☐ |
Lease assignment and signature tested. |
|
☐ |
Rent, wallet and bank transfer tested. |
|
☐ |
Maintenance and document access tested. |
|
☐ |
Notifications and preferences tested. |
|
☐ |
Lease Angel, mortgage, property sales, WeBuild and land access tested. |
Security and governance
|
☐ |
Role-based access tested. |
|
☐ |
Blacklist policy and review process approved. |
|
☐ |
SuperAdmin impersonation control tested. |
|
☐ |
Mobile token, OTP and biometric flow tested. |
|
☐ |
Export and deletion controls configured. |
|
☐ |
Audit and activity logs reviewed. |
66 User Acceptance Testing and Go-Live
|
Test area |
Acceptance test |
|
Tenant list |
Search, filters, pagination, stats and export. |
|
Manual create |
Existing User link and new User creation. |
|
Invitation |
Send, accept, expire, resend and duplicate prevention. |
|
Registration |
Web and mobile with email verification. |
|
Wallet creation |
Confirm one wallet per client and country currency. |
|
Profile |
Personal, employment, emergency, photo and password. |
|
KYC |
Submit, provider processing, approve, reject and resubmit. |
|
Screening |
Background, credit, reference and AI score. |
|
Listing application |
Submit, approve, reject and notification. |
|
Unique code |
Search, link and lease assignment. |
|
Lease |
View, sign, activate, download and health score. |
|
Dashboard |
Lease, wallet, payment, maintenance and notification totals. |
|
Rent payment |
Gateway, wallet, bank transfer and receipts. |
|
Wallet |
Top-up, pay, withdraw, bank account and trends. |
|
Maintenance |
Create, track, comment, rate and pay charge. |
|
Documents |
Upload, download, notify and restricted KYC visibility. |
|
Notifications |
List, read state and preferences. |
|
Settings |
Currency, language, privacy and payment methods. |
|
Lease Angel |
Apply and track schedule. |
|
Mortgage |
Browse, eligibility, apply and status. |
|
Property sale |
Offer, deposit, instalment and completion. |
|
WeBuild |
Browse, book, pay and progress. |
|
Land |
Browse, apply, pay and complete. |
|
Analytics |
Payment, occupancy, retention and overdue metrics. |
|
Bulk operations |
CSV invite, status, export and notifications. |
|
CRM |
Communication timeline and lead link. |
|
Blacklist |
Apply, notify, restrict new application and remove. |
|
SuperAdmin |
View, suspend, activate, KYC and export. |
|
Impersonation |
Reason, audit, restrictions and exit. |
|
Mobile auth |
Login, refresh, OTP, password reset and biometric. |
|
Security |
Cross-landlord isolation, role access and sensitive exports. |
|
|
Pilot recommendation Run one complete invitation, KYC, screening, listing application, lease, rent payment, maintenance request and account-support case before broad portfolio migration. |
|
Issue |
Recommended action |
|
Client does not appear |
Check landlord link, Tenant record, status and scope. |
|
Duplicate account |
Search email, phone, unique code and User before creation. |
|
Invitation expired |
Rotate or resend token under the configured process. |
|
Invitation creates duplicate |
Review existing User and Tenant linking logic. |
|
Email not verified |
Review notification delivery and verification expiry. |
|
Wallet missing |
Review tenant-wallet creation event or service. |
|
Profile photo fails |
Check file type, size, storage and permissions. |
|
KYC remains Pending |
Review provider response, queue and reviewer backlog. |
|
KYC data mismatch |
Check profile, document and provider result. |
|
Screening result missing |
Review provider, consent, job and TenantScreeningResult. |
|
AI score seems wrong |
Review source data, model input and human decision. |
|
Listing application invisible |
Check listing, landlord scope and status. |
|
Unique code not found |
Check formatting, client status and search endpoint. |
|
Lease linked to wrong client |
Stop activation and correct the relationship with audit. |
|
Rent paid but history pending |
Verify gateway callback, wallet transaction or bank proof. |
|
Client sees wrong document |
Review ownership, category and policy immediately. |
|
Notifications duplicated |
Review event listeners, queue retries and idempotency. |
|
Blacklist blocks all landlords |
Review landlord-specific scope and platform status. |
|
Impersonation not logged |
Disable feature until audit is restored. |
|
Mobile token loop |
Review refresh-token expiry and logout invalidation. |
68 Frequently Asked Questions
Can a landlord add a client without an invitation?
Yes. TenantController@create and @store support manual creation or linking.
What is the unique code for?
It enables quick search and lease assignment without relying only on email.
Does email verification mean KYC is complete?
No. Email and identity verification are separate.
Can KYC be rejected and resubmitted?
The supplied lifecycle indicates rejection with possible resubmission; confirm production rules.
Does AI decide whether a client is accepted?
No. AI provides screening or application suggestions; an authorised human decides.
Can a client apply before KYC?
The system may permit it, but the landlord policy should define what is required before approval or lease activation.
Can one client rent and later buy property?
Yes. The same account can access leases, purchases, WeBuild, land and mortgage features.
How can the client pay rent?
Gateway, wallet or verified bank transfer.
Can the client withdraw wallet funds?
Yes, to a verified bank account where supported.
Can the landlord see the client CRM history?
Authorised CRM users can view linked communication history.
What does blacklisted mean?
The client is blocked from new listing applications for that landlord under the supplied design.
Can SuperAdmin suspend the client?
Yes, under the platform oversight controller.
Can SuperAdmin log in as the client?
The supplied controller includes impersonate; it should be tightly controlled and audited.
Can the client delete the account?
The client can request deletion, but required legal and financial records may be retained.
Does the mobile app support biometric login?
The supplied design includes biometric support, subject to device and secure server-side controls.
69 Technical Matters to Confirm Before Production
|
Area |
Confirmation required |
|
Terminology |
Confirm menu label Tenant, Client or both. |
|
Status fields |
Confirm active, inactive, blacklisted, suspended and KYC transitions. |
|
User creation |
Confirm whether User is created before or after email verification. |
|
Wallet creation |
Confirm actual tenant wallet service, event or observer. |
|
Invitation |
Confirm expiry, resend, token rotation and existing User handling. |
|
Unique code |
Confirm format, regeneration and merge behaviour. |
|
Profile fields |
Confirm required, optional and protected-use fields. |
|
KYC provider |
Confirm provider, liveness, country coverage, data sharing and retention. |
|
KYC authority |
Confirm landlord versus SuperAdmin review precedence. |
|
Screening providers |
Confirm credit, background and reference integrations. |
|
AI scoring |
Confirm inputs, scale, model version, explanation and human review. |
|
High risk |
Define threshold and notification behaviour. |
|
Listing application |
Confirm required documents and status enums. |
|
Lease link |
Confirm multiple landlords and client-portfolio relationship model. |
|
Payment score |
Define payment behaviour and lease health score. |
|
Wallet |
Confirm multi-currency, top-up, withdrawal and fee rules. |
|
Documents |
Confirm categories, access, storage and deletion. |
|
Notifications |
Confirm mandatory and optional channels. |
|
Blacklist |
Confirm landlord scope, reason, duration, appeal and removal. |
|
Suspension |
Confirm platform effect on active leases and payments. |
|
Impersonation |
Confirm consent, audit, blocked actions and support policy. |
|
Mobile tokens |
Confirm expiry, refresh, revocation and device binding. |
|
Biometric |
Confirm local storage and server-side step-up. |
|
Deletion |
Confirm GDPR workflow, retention and anonymisation. |
|
Exports |
Confirm columns, masking and authorised scope. |
|
CRM link |
Confirm lead-to-client conversion and duplicate merge. |
|
Cross-module data |
Confirm reuse of profile and KYC data with consent and freshness. |
|
|
Specification basis This guide preserves the supplied Tenant / Client module workflow and technical names. Any undefined production behaviour is listed for confirmation rather than assumed. |
70 Quick Reference - 32-Step Client Operating Flow
1. View or search the landlord Client portfolio.
2. Create or invite a client.
3. Generate a secure invitation token.
4. Client registers or accepts the invitation.
5. Verify the client email.
6. Create User, Tenant and configured wallet records.
7. Client completes profile and emergency contact.
8. Client uploads KYC evidence.
9. Process and review KYC.
10. Notify the client of approval or rejection.
11. Obtain consent and open screening.
12. Run background, credit and reference checks.
13. Calculate AI-assisted score and risk.
14. Record the human screening decision.
15. Client submits a ListingApplication.
16. Landlord reviews and approves or rejects.
17. Find the client by unique code or search.
18. Create the Pending lease and payment schedule.
19. Client signs and landlord activates the lease.
20. Client uses the main dashboard.
21. Client pays rent and downloads receipts.
22. Client manages wallet and verified bank accounts.
23. Client submits and tracks maintenance requests.
24. Client manages documents and notifications.
25. Client updates settings, password and privacy choices.
26. Client accesses Lease Angel where eligible.
27. Client applies for mortgage products.
28. Client submits property purchase offers.
29. Client books WeBuild units and tracks progress.
30. Client applies for and purchases land.
31. Landlord reviews analytics, CRM and authorised bulk actions.
32. Apply fair blacklist, SuperAdmin and mobile-security controls with full audit.
|
|
Business value Leaseora gives a real estate company one connected Client record that supports onboarding, identity, screening, rental, payments, maintenance, financing, property ownership and long-term relationship management. |
LEASEORA
TENANT / CLIENT MANAGEMENT
Onboard, verify, lease, serve and grow every client relationship from one connected platform.
|
|
Support and onboarding For Tenant / Client module onboarding, invitation setup, KYC, screening, lease assignment, wallet, mobile access or integration assistance, contact Leaseora through support@leaseora.com. |
leaseora.com
Was this article helpful?
Your feedback helps us improve our documentation.