Announcements — Platform Admin Guide

This guide is for platform administrators publishing announcements that span more than a single makerspace. For per-makerspace announcements, see the Makerspace Admin Guide. For concepts, see the Overview.

Who can do this

Platform admin access is gated by membership in the platform-admins Cognito group. There is no separate Manage Announcements permission at the platform level — platform admin membership is the permission.

The first time you sign in as a platform admin after the announcements rollout, a lightweight identity record is created for you in the application database (just-in-time, no manual onboarding required). This record is what backs the snapshotted creator name on every announcement you publish.

Finding the page

1. Sign in to the Platform Admin app.
2. Go to Communications → Announcements.

The page has two tabs — Active and History — that mirror the makerspace-admin layout, with two additional capabilities:

• You can target Public and Authenticated audiences (makerspace admins can only target their own members).
• You can choose any display surface (Banner, Dashboard, or Both); makerspace admins are locked to Dashboard.

Creating an announcement

1. On the Active tab, click New Announcement.
2. Fill in the form:

Field	Description
Title	Short headline. Plain text. Required.
Body	The notice itself. Plain text. Required.
Audience	Public or Authenticated (see below). Required.
Display surface	Banner, Dashboard, or Both. Required.
Starts at	When the announcement becomes visible. Browser-local time.
Expires at	Optional. When the announcement automatically drops off.

3. If you pick Public audience you must check the safety acknowledgement before Save unlocks. See the next section.

Choosing an audience

Pick this audience	…when
Public	Pre-login visitors must see the notice (e.g. scheduled platform-wide downtime, billing-portal outage, security advisory). Also visible to all signed-in users.
Authenticated	All signed-in users across the platform need to see it, but anonymous visitors should not (e.g. a new feature rollout, a beta program invitation).
Makerspace members	Not selectable from the platform UI — the audience picker only offers Public and Authenticated, and the backend rejects makerspace_members with a 422 if a platform admin tries to author one. Single-makerspace notices are authored by that makerspace’s own admins from their admin UI.

The PUBLIC audience safety acknowledgement

Public announcements are visible to anonymous visitors on the login page. Anyone with a link to your platform sees them. Search engines may index them indirectly via the cache.

Before you can save a Public announcement the form requires explicit acknowledgement that:

• The title and body must contain no PII, no makerspace-specific operational details, and no internal links.
• The content is appropriate for an unauthenticated audience.

If you uncheck the box, Save disables. This is a deliberate speed bump, not a substitute for review — please get a second pair of eyes on anything you’re about to publish to anonymous viewers.

Display-surface guidance

Surface	When to use
Banner	Brief, high-visibility notices (one-sentence outages, single-link advisories). The banner sits above every page in the audience surface.
Dashboard	Longer notices that benefit from breathing room (release notes, feature announcements, multi-step actions).
Both	High-priority notices that warrant a banner and the longer dashboard treatment simultaneously. Members see the same announcement in two places. Use sparingly.

Public announcement timing

• The public endpoint is cached in-process for 60 seconds per backend instance.
• A newly-published Public announcement may take up to a minute to appear on the login page across every server.
• Likewise, a deactivation may take up to a minute to take effect on anonymous surfaces. Plan critical takedowns with this lag in mind.
• Authenticated surfaces (Banner / Dashboard for signed-in users) are not cached this way and update on the user’s next page load.

Editing, deactivating, reactivating

These flows are identical to the makerspace-admin flow — see the Makerspace Admin Guide. Three platform-specific notes:

• Editing audience is not allowed. Once an announcement is created, its audience is locked. To change audience, deactivate the existing announcement and publish a new one.
• Editing display surface is allowed. Use it for promoting a Dashboard-only notice to Both as you near an event date.
• Deactivating a Public announcement still respects the 60-second cache window before anonymous viewers stop seeing it.

The History tab

The History tab mirrors the makerspace-admin History tab — search, status filter, date range, 25-row pagination, URL-driven state. The difference is scope: as a platform admin, you see history of platform-scope announcements only (Public + Authenticated audiences, no makerspace assigned). Makerspace-scope history lives in each makerspace’s own admin UI. Title search is a case-insensitive substring match (body content is not searched in v1).

The snapshotted creator name protects audit accuracy. Announcements published before the platform-admin user-bootstrap rolled out display a “Platform Admin” fallback name; everything published after rollout displays the actual platform-admin user’s given_name family_name.

Things to watch for

• No “also send as notification” bridge in v1. Announcements are pull-only. If a notice is operationally critical (e.g. immediate billing-portal outage), pair it with a broadcast.
• No targeting specific makerspaces from the platform side. The platform UI only authors Public + Authenticated audiences; single-makerspace announcements are authored by the makerspace’s own admins. Cross-makerspace cohort targeting is on the roadmap.
• No CSV export of history. Use the search and date-range filters; if you need a bulk extract, raise a request with engineering.