Role-based access
Residents, admin, security, board, and field staff receive only the permissions they need. The staff app hides entire modules — not just buttons — when a role cannot act.
Security, privacy & reliability
Designed as a business-critical community platform.
Final security controls and SLA commitments are documented in the implementation and service agreement. The architecture is already built for least privilege, auditability, and continuity.
Separate trust boundaries
Resident and staff apps are separate bundles with separate token audiences. Staff credentials never call resident mint APIs. Board users enter a distinct portal shell.
Audit trail
Important actions and approvals are traceable: who approved a visitor, who resolved an incident, who changed a role. Dual-control exists for sensitive IAM changes.
Data protection
Encryption in transit, controlled access, and secure credential handling. Resident and staff tokens live in secure device storage — not ordinary preferences. Web sessions use httpOnly cookies.
Backups & recovery
Automated backups and documented recovery procedures. Responsibilities are written into the service agreement, not implied by hosting.
Monitoring
Application and infrastructure monitoring with incident procedures. Release builds can pin certificates on mobile. Logging redacts authorization headers and sensitive fields.
Vendor continuity
The community previously lost digital capability when a property manager changed. Community Connect is structured so that does not happen again: the condominium owns the data and the policies; the provider operates the platform.
- Clear data ownership and export rights
- Defined uptime and support expectations
- Documented backup and recovery responsibilities
- Change-management process
- Exit / transition assistance if the provider changes
What we do not do
- We do not treat hidden buttons as authorization. The server enforces permission on every privileged operation.
- We do not put secrets in the resident or staff app bundle. Environment configuration is injected per flavor.
- We do not log passwords, tokens, or authorization headers.
- We do not store session tokens in ordinary browser storage on the admin or board portals.
Ask for the security and SLA appendix in discovery.
Confirm interest, run a discovery workshop, agree Phase 1, then pilot. The objective is not to buy an app — it is to establish a reliable, community-controlled operating platform.