Skip to main content

Features Inventory

Last reviewed: 2026-06-13
Maintained by: Engineering

Purpose + Rules​

This document is the repo-state inventory for ZGRID. It is grounded in code that exists today and should be read as an implementation snapshot, not as a promise that every user experience is equally mature.

Prefer ../08-applications/features-by-application.md when you need a higher-level onboarding view grouped by application and maturity status.

How to Read This Page​

This is the detailed inventory layer of the public docs.

Rules for this inventory:

  • Implemented-only: include only capabilities backed by current code paths.
  • No roadmap/speculation: planned features are intentionally excluded.
  • Use (partial) when flow exists but is gated, incomplete, or lacks full UI/ops completion.
  • Feature names should describe user-facing capability, not internal symbol names.

Inventory by App / Package​

apps/api​

The API is the shared operating core of ZGRID.

Core route groups and capabilities:

  • Auth and session management: login, refresh, logout, current context, cookie/bearer transport support.
  • Account privacy and profile services: tenant data export, account deletion request create/status, mobile preference and device token management.
  • Tenant onboarding: building code resolve, structure lookup, registration, status, and resubmission.
  • Technician onboarding: invite resolve, specialty listing, profile completion, job access preparation, and invite management.
  • Manager/representative onboarding: review queues, decision actions, and leave/delegation flows.
  • Building context and hierarchy: building/section/entrance/floor/unit listing and manager CRUD, resident access code regeneration.
  • Issues workflow: create/list/detail, assignment, status transitions, comments, attachments, reviews, reopen requests, work logs, and feedback.
  • Service Requests workflow: tenant create/list/detail and manager transition actions with status history.
  • Conduct Reports workflow: tenant submit/list/detail and manager moderation actions (warn/resolve/dismiss/abuse-mark).
  • Help Requests workflow: building-scoped listing, create, claim, fulfill, delete.
  • Noise Notices workflow: tenant/community notice submission support.
  • Resident Directory workflow: building list, preference read/update, filtered resident listing.
  • Announcements/Documents/Building Decisions/Billing/Reserve Funds/Debtors: tenant-facing and manager-facing operational endpoints.
  • Notifications: list/read/read-all + push/device registration pathways.
  • Legal foundations: jurisdiction profiles, fee matrix/coefficient versions, building legal settings, unit-share readiness, and manager-visible rule drafts.
  • Reports/export: manager-facing operational reports and CSV export surfaces.
  • Admin platform endpoints: overview, organizations, subscriptions, feature entitlements, issues, privacy deletion queue, audit log.
  • Health/meta/webhook endpoints: health checks, metadata endpoints, Lemon webhook ingestion.

Auth/RBAC enforcement present:

  • Role checks (tenant, manager, technician, super_admin) at route level.
  • Additional tenant approval and workspace/subscription access guards on relevant manager/tenant routes.
  • Organization/building scope checks in service layers for sensitive flows.

Background/scheduled/ops behavior:

  • Scheduled privacy metadata cleanup workflow exists in GitHub Actions.
  • Retention/cleanup scripts and migration drift/schema checks are wired through repo scripts.
  • No always-on in-process job scheduler is defined in API runtime (cleanup is workflow/script-driven).

What this means in practice:

  • the API is where product rules become enforceable rules
  • internal web apps and mobile flows stay aligned because they share the same backend contract
  • integrations remain optional until the environment enables them

apps/back-office (Back Office)​

Back Office is the platform control layer for super_admin users.

Pages and user-facing capabilities:

  • Sign-in and auth guard flow.
  • Overview dashboard with platform summary cards.
  • Organizations list and organization detail.
  • Subscriptions list and per-organization subscription detail/override actions.
  • Feature entitlement management per organization.
  • Resident payment configuration at organization level.
  • Issues list and issue detail (platform visibility).
  • Jurisdiction profiles and draft-rule review/activation surfaces.
  • Privacy deletion requests queue and processing screens.
  • Audit log page.
  • Admin profile page.
  • Forbidden/error routing pages.

Admin action surface:

  • Activate/deactivate organizations.
  • Change/override subscription plan for organizations.
  • Enable/disable organization feature entitlements.
  • Maintain jurisdiction profiles and review legal rule drafts.
  • Process account deletion requests (reject/complete).
  • Platform-wide issue visibility and auditing.

In product terms, Back Office is where platform operators shape the rules and visibility that sit above any single manager organization.

apps/manager-desk (Manager Desk)​

Manager Desk is the operating workspace for manager organizations.

Pages and user-facing capabilities:

  • Sign-in, dashboard, and guarded workspace shell.
  • Buildings list/detail with structure management (sections/entrances/floors/units).
  • Issues list/detail and operational issue handling.
  • Service Requests manager queue.
  • Tenant onboarding requests list/detail and approve/reject.
  • Manager/representative onboarding request review.
  • Representatives management page.
  • Announcements/Documents/Building Decisions management pages and details.
  • Invoices, reserve funds, debtors, maintenance, and building reports pages.
  • Building legal settings and legal-readiness pages.
  • Technicians, notifications, profile, settings, and legal pages.
  • Subscription page (plan/usage/access mode/billing controls).

Manager action surface:

  • Maintain building hierarchy and unit inventory.
  • Review/approve/reject tenant onboarding requests.
  • Review manager/representative onboarding items.
  • Manage operational issues and service request lifecycle steps.
  • Manage representative assignments.
  • Manage content and building decision artifacts.
  • Manage legal settings, fee inputs, and building-level readiness data.
  • Access subscription and billing controls for organization.

In product terms, Manager Desk is where daily building operations and organization-level oversight meet in one workspace.

apps/zgrid-mobile (Zgrid App)​

ZGRID Mobile keeps residents and technicians inside the same operating flow without exposing the internal web workspaces.

Tenant​

  • Auth/session flow: login, session restore, logout cleanup boundaries.
  • Home tabs: announcements, issues, profile, payments (feature-gated), plus shared entry routing.
  • Issue reporting split flow: emergency vs common-area forms.
  • Issue detail and issue list viewing.
  • Documents, building decisions, reserve funds, and notifications screens.
  • Service Requests: list and report/create flow.
  • Help Requests: building-scoped community request screen.
  • Noise notice submission screen.
  • Resident Directory: visibility-based directory access and listing.
  • Privacy and legal screens (including export/deletion request UX).
  • Onboarding pending/rejected state screen.
  • Payments “coming soon” gating route/screen when feature flag disabled (partial).

Technician​

  • Technician-specific layout and route group.
  • Jobs list screen.
  • Technician issue detail flow.
  • Technician profile screen.
  • Technician setup/onboarding continuation screen.

In product terms, mobile keeps the field and resident side of the system close to the same live operational state as the manager workspace.

packages/api-client​

Shared contracts keep the ZGRID surfaces aligned on one API language.

Typed client surface:

  • Shared request client with refresh retry behavior and typed ApiRequestError.
  • Auth and context contracts.
  • Tenant onboarding + technician onboarding contracts.
  • Building context and hierarchy CRUD contracts.
  • Issues, comments, attachments, work logs, feedback, reopen/activity contracts.
  • Service Requests contracts and lifecycle action methods.
  • Conduct Reports contracts and moderation actions.
  • Help Requests contracts.
  • Resident Directory contracts/preferences/list filters.
  • Notifications, announcements, documents, building decisions, billing/reserve funds contracts.
  • Account privacy export/deletion request contracts.
  • Manager subscription and checkout/portal/change contracts.
  • Admin contracts (overview, orgs, subscriptions, issues, privacy queue, audit).

packages/validation​

Shared validation keeps repeated product flows consistent across apps.

Shared validation surface:

  • Login schema and shared language schema.
  • Tenant issue-reporting validation for common-area and emergency flows.
  • Tenant service-request validation.
  • Tenant onboarding basic info, access-code, and residence-selection validation.
  • Technician invite/profile-setup validation.

packages/web-shell​

Internal web surfaces share one shell language and one set of guardrails.

Shared internal web-app shell surface:

  • Ant Design provider wrapper.
  • MobileGuard small-screen guard for internal web apps.
  • Shared system/result states for unavailable, degraded, and expired-session views.

packages/monitoring​

Monitoring helpers keep optional browser-side reporting consistent across internal web surfaces.

Shared monitoring surface:

  • Shared browser-side Sentry initialization helper.
  • Shared browser exception capture helper for internal web apps.

database​

The database structure reflects the same core ZGRID domains seen in the product surfaces.

Schema is migration-driven and grouped by domain:

  • Auth/session domain: users, refresh tokens/session metadata hardening, device token/installations.
  • Organization/building/unit domain: organizations, buildings, sections/entrances/floors/units, memberships.
  • Operational work domain: issues, comments, reviews, work logs, reopen/feedback history.
  • Community domain: conduct reports, resident directory preferences, help requests.
  • Service and onboarding domain: tenant onboarding, technician onboarding, service requests and status history.
  • Billing/subscription domain: plans, subscriptions, history, payment/provider linkage, webhook event storage.
  • Privacy/audit domain: account deletion requests, audit logs, privacy metadata cleanup support.

Inventory by Role​

These role summaries describe who each surface is designed to support. They are not a substitute for API-enforced authorization rules.

super_admin​

  • Access Back Office dashboards, organizations, subscriptions, features, issues, audit, privacy requests.
  • Can process deletion requests and apply platform-level organization controls.
  • Can inspect cross-organization operational and billing state.

manager​

  • Access Manager Desk workspace for their organization/buildings.
  • Can manage buildings/units structure and operational modules.
  • Can review onboarding requests and manage representatives.
  • Can manage issues/service requests, announcements/documents/building decisions, legal settings, and organization billing page.

tenant​

  • Uses ZGRID Mobile routes and tenant-scoped API surfaces.
  • Can report issues (emergency/common-area), create service requests, create conduct reports, and use community modules.
  • Can access announcements/documents/building decisions/billing views, notifications, privacy export/deletion request.
  • Subject to onboarding approval and building/membership scope checks.

technician​

  • Uses technician mobile route group and technician-scoped issue handling surfaces.
  • Can access jobs/profile/setup flows and technician issue detail actions permitted by API role policy.

tenant + representative capability (scoped assignment)​

  • Representative capability is assignment-based (not global role replacement).
  • Assignment and candidate management is exposed on manager side.
  • Minimal representative scope is present in auth context for downstream feature gating.
  • Dedicated zgrid-mobile representative UX beyond shared tenant flows is (partial).

Known Partial Areas​

  • Payments tab in ZGRID Mobile is feature-gated with “coming soon” fallback (partial).
  • Representative capability has backend/context support and manager assignment UI, but tenant-side dedicated representative UX is (partial).
  • Some newly added community flows are implemented in API/mobile but still depend on continued UX hardening and content maturity (partial).

Source Pointers​

Use these paths when you need to trace a documented feature back to code:

  • apps/api/src/routes/
  • apps/api/src/features/
  • apps/back-office/app/
  • apps/manager-desk/app/
  • apps/zgrid-mobile/app/
  • packages/api-client/src/
  • database/migrations/
  • database/schema.snapshot.sql