Skip to main content
Atlas is Meridian’s surface for clubs and registered organizations: recognition, directory, membership, roles, governance documents, budgets where configured, messaging, and the admin tooling campus staff use to oversee the org ecosystem. It is intertwined with Beacon (org-hosted events and approvals) and Compass (rooms and scheduling when org life touches space), but Atlas is framed around the org as the unit of work, not around utilization curves or the global event approval graph. Atlas ships its own reporting—org health, membership, engagement-style org metrics, finance queues where enabled, and event analytics scoped to an organization’s programming. Those are conceptually separate from Compass utilization reports and Beacon cross-campus event and approval analytics.

​
Key features

Organization directory

Recognition status, profiles, search, and the institutional view of clubs and orgs

Membership & roles

Join flows, applications, officer permissions, and lifecycle of membership

Governance & policy

Permissions, verification tiers, and org-side rules enforced in Atlas routes and UI

Atlas reporting

Org-scoped dashboards and exports—distinct product intent from Compass utilization or Beacon approval funnel reporting

​
Core capabilities

​
Organization operations

  • Admin and self-service flows for org leaders (rosters, messaging, announcements)
  • Platform-admin views for compliance, recognition, and risk (see Atlas admin)
  • Finance and budget workflows where the tenant has enabled them (finance & budgets)

​
How Atlas meets Beacon and Compass

  • Beacon carries the event approval graph and stakeholder routing; Atlas supplies which org is acting and who in that org may create or sponsor events under policy.
  • Compass carries scheduling and utilization; Atlas does not replace that framing—orgs consume space through the same shared backend and UI patterns.

​
Reporting

  • Org-level analytics and templates (for example event analytics under org management where documented in deeper pages)
  • Membership and participation signals for student-affairs operations
  • Separate from Compass “how hard are rooms running?” and from Beacon “how fast do approvals move across campus?”

​
Architecture

Atlas is implemented as routes, models, and React surfaces inside the monolith (not a separate microservice). See Atlas architecture for how getModels(req, …), org-scoped permissions, and admin entrypoints fit together. Integrations with other products:
  • Backend API: org management, membership, messaging, finance, configuration (Atlas backend)
  • Beacon: org-owned events and policy alignment
  • Compass: org context when booking or events touch rooms and schedules

​
Who uses it

  • Student org leaders: run the org day-to-day within policy
  • Student affairs / org advisors: recognition, oversight, reporting
  • Students: discover and join organizations
  • Platform admins: global configuration and exception handling

​
Getting started

Admin dashboard

Operator-facing org management and reporting entrypoints

Atlas backend

REST map, auth gates, and multi-tenant access patterns

Permissions

Org-scoped roles and enforcement

Data model

Core collections and invariants for organizations

​
Deep dives (internal)

Architecture

How Atlas is wired end-to-end (routes, UIs, model access)

Backend APIs

Endpoint map and request shapes

Frontend

React entrypoints and API usage

Membership

Join flows, applications, and member management

Messaging

Org messages, visibility, and API endpoints

Event analytics

Org-scoped event analytics where implemented

Troubleshooting

Common failure modes