Tenant Portal SaaS: The Flows You Must Test Before Tenants Log In

Before tenants log in, test six flows: the invite and first login, data isolation so no tenant ever sees another's records, rent payments, maintenance requests, document access, and notifications. A tenant portal fails most often at the invite path and at isolation, because those are the parts a demo with one account never exercises.

If you would rather have it tested for you, see how RAITHub would test this below. This is the test-plan companion to the build-focused tenant portal features tenants actually use; here the job is proving the portal is safe before you send the first invite.

What makes a tenant portal risky to launch?

Three things stack up: it is multi-tenant, so one access bug exposes everyone; it moves money, so payment edge cases cost real rent; and its users are not staff, so they will hit the empty, error and mobile states your team skips. Name the critical flows and test each on a production-like environment with realistic data, as a brand-new user with an empty account.

Flow	Minimum bar to pass	Automate or manual
Invite and first login	An invite works once, for the invited email only, expires, and lands the tenant on a useful empty state	Automate plus one manual run on a real phone
Data isolation	No tenant can read or change another tenant's lease, payments, documents or messages	Automate at the database and the API
Rent payments	Success, decline, refund and a duplicate webhook leave one correct balance	Automate in test mode
Maintenance requests	A request routes to the right landlord or contractor and is visible only to the parties	Automate
Documents	Leases and uploads are reachable only by the parties; private files are not guessable URLs	Automate plus one manual check
Notifications	Reminders, status changes and receipts fire once, at the right local time	Automate with a fixed clock

How do you test the invite and onboarding flow?

Most portal sign-ups are invite-only, and the invite path is where the real first impression and the first security hole both live. Test it as the tenant will experience it, then test the ways it can be abused.

• Open an invite link, set a password, and confirm the tenant lands on an empty but clear dashboard, not a blank page or an error.
• Use the same invite link twice. The second use must fail.
• Use an invite intended for one email while logged in as a different account. It must not attach to the wrong tenant.
• Let an invite expire, then try it, and confirm the message tells the tenant what to do next.
• Run the whole flow on a real phone, including the email link opening in an in-app browser.
• Check the welcome and reset emails arrive, render correctly and do not land in spam.

How do you test data isolation between tenants?

Isolation is the flow that, if wrong, turns one bug into a breach for everyone. Test it where it is enforced: the database and the API, not the screen. For a shared-schema SaaS, PostgreSQL row-level security is a common backstop; the trade-offs between tenancy models are in multi-tenant vs single-tenant SaaS and database per tenant vs shared schema.

Create two tenants with data, then attack the boundary. On a Postgres project you can test the policies directly, as a specific user, inside a transaction that is rolled back. Run it on a staging copy, not production:

begin;
-- Act as a member of tenant A
set local role authenticated;
select set_config('request.jwt.claims',
  '{"sub":"TENANT_A_USER","tenant_id":"TENANT_A"}', true);

-- 1. Can A read tenant B's leases? Expect 0 rows.
select count(*) from leases where tenant_id = 'TENANT_B';

-- 2. Can A move a payment into tenant B? Expect an error or "UPDATE 0".
update payments set tenant_id = 'TENANT_B' where tenant_id = 'TENANT_A';
rollback;

Then do the same through the API: take a record ID from tenant B and request it as a tenant A user. OWASP calls this broken object level authorization (OWASP API1:2023). A Playwright loop keeps it running on every release. For the full isolation hunt and fix, see users can see another tenant's data and the Postgres row-level security guide.

What should the role matrix cover?

A tenant portal usually has at least tenant, landlord or property manager, contractor and admin. Write every action against every role, include anonymous visitors, and test the "Refuse" cells with two accounts per role.

Action	Tenant	Manager	Contractor	Admin
Read own lease and payments	Allow	Allow, own units	Refuse	Allow
Raise a maintenance request	Allow	Allow	Refuse	Allow
See a maintenance job	Own only	Own units	Assigned only	Allow
Read another tenant's records	Refuse	Refuse	Refuse	Allow, logged
Change own role	Refuse	Refuse	Refuse	Allow
Open admin routes and APIs	Refuse	Refuse	Refuse	Allow

The defensive auth plan, including the self-promotion test and session checks, is in testing login, roles and data access.

How do you test rent payments and maintenance requests?

Test rent payments in your provider's test mode: success, decline, refund, and the same webhook delivered twice, confirming the balance changes once. Stripe recommends recording processed event IDs so a repeated event is skipped (Stripe: webhooks), and publishes test cards in its testing documentation. The layered plan is in testing payments and webhooks end to end.

For maintenance requests, test the routing and the visibility:

• A request raised by a tenant appears for the right manager and, once assigned, for the right contractor, and for nobody else.
• A contractor sees only assigned jobs, never the tenant's full history or other properties.
• Status changes notify the tenant once, not on every save.
• A photo uploaded with a request is reachable only by the parties to that job.

Buy, build or hire this testing?

Option	Choose this when	Trade-off
Off-the-shelf tenant portal (test the vendor's product)	You are buying a portal, not building one	Little of your own code to test; you inherit the vendor's isolation and payment behaviour
Your own Playwright and SQL suite	A developer can own isolation, payment and matrix tests and keep them current	Lowest cost to run; you must design the isolation tests yourself
A freelance tester before go-live	You want one outside pass	Variable depth on multi-tenant isolation; check their SaaS experience
A managed QA plan or a one-off pre-launch audit	You want invites, isolation, payments and documents tested end to end before the first invite	An outside dependency; keep the tests in your repository

Doing it yourself is realistic: plan 3 to 5 days for a developer who knows the stack. The main risk of going alone is testing isolation with one tenant, which can never fail.

Why RAITHub for this

• Multi-tenant isolation is everyday work. Sundor Skin, a B2B platform RAITHub built, runs 146 PostgreSQL tables under row-level security with 530+ tests and a suite that tries to read other buyers' data. PropDesk, a property-management SaaS, has 4 roles, Stripe rent collection and 1,024 tests.
• Tests at the database, the API and the screen, so isolation is proven where it is enforced.
• Honest limits. Security testing is application-level, against OWASP guidance; it is not a CREST- or PCI-certified penetration test. The figures above are test suites for platforms RAITHub built, not a standalone QA case study.

When you don't need us

• Your portal has one tenant and no shared data. Test the invite and payment flows yourself.
• You have a QA engineer who owns release testing. Give them this plan.
• A customer or regulator requires a certified penetration test. Use a certified firm; RAITHub is not SOC 2 or ISO 27001 certified.

How RAITHub would test this

• Scope: agree the tenancy model, the roles and the payment flows on a free 15-minute call.
• Plan: a risk map of invites, isolation, payments, maintenance and documents, with a test for each.
• Test: isolation at the database and the API with two tenants, the invite path, payments in test mode, maintenance routing and document access.
• Deliver: a ranked bug report with reproduction steps and a suggested fix, plus the isolation and payment tests as automated tests in your repository.
• What you receive: the report, the tests and a handover note. IP is yours; an NDA is standard.

The audit is fixed-price, quoted in writing after the call. See QA as a Service, AI-built app testing, and, if you are still building, SaaS development and the PropTech industry page. To book it, ask for a pre-launch QA audit.

Documentation checked on 10 October 2026.

Frequently asked questions

What flows must you test in a tenant portal before launch?

The invite and first login, data isolation between tenants, rent payments, maintenance requests, document access and notifications. Start with the invite path and isolation, since those are the parts a single-account demo never exercises.

How do you test that tenants cannot see each other's data?

Create two tenants with data, then request one tenant's records while signed in as the other, at the API and directly against the database policies on a staging copy. If any read or write succeeds across tenants, the isolation is broken.

How do you test an invite-only onboarding flow?

Confirm an invite works once for the invited email only and expires, lands the tenant on a useful empty state, and cannot be attached to the wrong account. Run the whole path on a real phone, including the email link.

Should maintenance requests be visible to all contractors?

No. A contractor should see only assigned jobs, never a tenant's full history or other properties. Test this by assigning a job to one contractor and confirming another contractor cannot read it.

How long does QA take for a tenant portal?

For a portal with several roles and rent payments, plan 3 to 5 days for a developer who knows the stack: a day on isolation, a day on payments, and the rest on invites, maintenance, documents and notifications.

Is this the same as a penetration test?

No. This is functional and application-level security testing of your own isolation and access rules against OWASP guidance. A penetration test is a broader, often certified engagement. If a customer or auditor needs a pentest report, use a certified provider.