Skip to main content

​
Beacon

Beacon is Meridian’s surface for campus events as an institutional process: creation and change, who must approve, how requests route across stakeholders, and how policy is expressed in software. Engagement feeds and notifications are part of the experience, but the center of gravity is the event system plus approval routing and the stakeholder model—not “just a feed.” Beacon has its own reporting (event performance, funnel and RSVP views where productized, approval throughput, and admin analytics). That is separate in intent from Compass utilization reports or Atlas org-directory and membership reporting, even though all three read from related data.

​
Key features

Event lifecycle

Draft → review → published → RSVP → check-in → wrap-up, with room needs delegated to Compass where applicable

Approval routing

Multi-step flows, domain-aware routing, and clear ownership at each gate

Stakeholder model

Roles, domains, and permissions that determine who sees what and who can move work forward

Beacon reporting

Event- and workflow-oriented analytics and admin dashboards distinct from Compass utilization or Atlas org metrics

​
Core capabilities

​
Events

  • Rich event definitions, collaborators, visibility, and templates (see Beacon event system)
  • Integration with Compass when events need rooms or resources on a schedule
  • Integration with Atlas when events are owned by or attributed to organizations

​
Approvals & policy

  • Configurable approval types (required vs notify vs acknowledge)
  • Conditional routing by event attributes, location, org, or domain rules
  • Audit-friendly progression: who acted, when, and outcome

​
Stakeholders

  • Institutional roles tied into routing (not only “org officers”)
  • Domain management where the product separates areas of responsibility
  • Alignment between Atlas org permissions and Beacon event/stakeholder rules where features intersect

​
Architecture

Beacon integrates with:
  • Frontend: operator and admin surfaces (for example under feature admin for Beacon configuration)
  • Backend: event and workflow routers in the monolith, plus notification channels (email, in-app, mobile where wired)
  • Compass: scheduling and rooms for event logistics
  • Atlas: organization membership and org-scoped policy that gates who can create or sponsor what

​
Who uses it

  • Event organizers: propose work, respond to feedback, publish when clear
  • Approvers & stakeholders: act inside routing rules without manual email chains
  • Admins: tune workflows, domains, and reporting for their campus

​
Getting started

Event system

Lifecycle, RSVP, check-in, and how Beacon talks to Compass and Atlas

HTTP API

Event-management and related REST surfaces

Atlas (organizations)

Org directory and permissions that often gate event creation

Compass (scheduling)

Utilization and room scheduling when events need space

Event management API

REST reference for org events, RSVPs, and assignments Beacon depends on.

Event dashboard (Atlas)

Organizer UI for agendas, readiness, and analytics tabs.

Platform analytics

Event pipeline powering funnel and RSVP insights in reporting.

Authentication overview

How attendees and organizers sign in across tenant subdomains.

Testing

Regression tests for event and auth flows before release.

Deployment

Shipping Beacon-related backend changes safely through CI.