Documentation
Nivaasos gives every person in a community exactly the access their role needs — nothing more. This page describes each role and the access rules that apply to everyone.
Roles
From the platform operator to an external auditor, each role has a clearly bounded job. A vendor role is reserved for a future vendor portal; today vendors are coordinated by managers.
The platform operator, or a property-management firm running a portfolio of communities.
Super admins are scoped, not global: independent operators on the platform can never see each other's communities.
A resident association or committee member who administers their community.
The professional manager a community hires to run day-to-day operations.
An apartment owner — including owners living abroad.
Owners are always the party responsible for maintenance dues, even when someone else pays.
A resident renting an apartment.
An external or neutral reviewer appointed by the community.
Auditors are read-only by construction — every change attempt is refused by the server.
Ground rules
Every request is checked against the signed-in person's active role on the server. Hiding a button is never the security boundary — the API itself refuses actions a role is not allowed to take.
There is no open registration. A community's admin or manager whitelists each member's Google account; anyone not on the list cannot sign in at all.
Every record belongs to exactly one community, and every query is scoped to it on the server. No role — including super admin — reaches data of a community it does not belong to or own.
Every create, update, and delete is written to an audit history with who did it and when, and the history itself is visible to admins, managers, and auditors.
An account can hold more than one role — a committee member who also owns a flat, for example — and switch its active view. Permissions always follow the active role.
Looking for the technical detail? The security page covers authentication, data isolation, and audit in depth.