Skip to main content

Community Workflows

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

ZGRID does not treat community activity as disconnected from building operations. Resident reporting, community help, directory visibility, and moderation-oriented flows sit inside the same shared platform state as issues, notifications, and manager work.

Current Scope​

The current community layer includes:

  • help requests
  • conduct reports
  • noise notices
  • resident directory visibility and preferences

These flows are implemented across the API, mobile experience, and manager-facing review or visibility surfaces where relevant.

Help Requests​

Help requests support lightweight community coordination inside a building context.

Current shape:

  • residents can create and view building-scoped requests
  • requests can be claimed or fulfilled where the workflow supports it
  • the flow stays tied to building scope rather than becoming a separate messaging system

Conduct Reports​

Conduct reports support resident reporting for behavior or rule-related incidents that need manager visibility.

Current shape:

  • tenants can submit and review their own reporting flow
  • managers can review, warn, resolve, dismiss, or mark abuse where the workflow supports those actions
  • the workflow is designed as a moderated operational process, not an open social feed

Noise Notices​

Noise notices support building-level reporting around disturbance events.

Current shape:

  • tenants can submit noise-related notices through the mobile/API flow
  • the capability sits alongside the broader community and operational reporting layer
  • the feature is intentionally scoped to building operations rather than general chat or commentary

Resident Directory​

The resident directory is a scoped community visibility feature, not a public directory.

Current shape:

  • directory access is bound to the relevant building context
  • residents can manage preference-driven visibility where supported
  • manager and resident surfaces rely on API-enforced scope checks rather than client-only filtering

Design Principle​

The ZGRID community layer is meant to keep building communication and reporting structured.

That means:

  • community workflows stay building-scoped
  • moderation and visibility rules stay API-enforced
  • resident-facing convenience does not replace operational traceability