Community Admin

Community admin surfaces live under Hub -> Admin and separate governance from event operations.

Governance vs Operations

Governance (usually OWNER/ADMIN)

Hub settings and branding,
Member management from Hub -> Members,
Invite and join-policy control,
High-impact moderation decisions.

Operations (OWNER/ADMIN/MANAGER where allowed)

Event creation and publishing,
Ticket and attendance operations,
Hub and event channel setup,
Event updates,
Event-day staffing/scanner workflows.

Use Roles and Permissions for exact boundaries.

Recommended Operating Rhythm

Weekly

Review join requests/invite health,
Verify member share-link policy still matches your moderation posture,
Review invite usage outcomes (joined, pending, no longer member) for anomalies,
Review hub and event channel rosters before major announcements or launches,
Review recent campaign email sends, scheduled items, and delivery outcomes,
Verify readiness for upcoming events,
Review moderation and incident queue.

Chat Operations

Use /chat for quick creation and Hub -> Chat / Event -> Admin -> Chat for ongoing channel control.

/chat can create direct messages, private groups, hub channels, and event channels from one shared creator.
Hub -> Chat is the durable roster view for hub channels, with owner/admin management controls on the page itself.
Event -> Admin -> Chat is the durable roster view for event channels, including rename, disable, and restore actions.
Event -> Admin -> Settings now only controls the event-wide chat switch.
Managers can help with operational channel setup, but wider hub governance such as member-role changes, branding, and join policy still stays with owners and admins.

Payments Readiness For Paid Tickets

Use Hub -> Admin -> Settings -> Payments as the source of truth before publishing or selling paid tickets.

A connected Stripe account is necessary, but it is not enough on its own.
For hubs that want to run paid events, the launch checklist treats monetisation, legal seller details, and payments as required setup work rather than optional polish.
New hubs now use Stripe-hosted onboarding and then Manage in Stripe to hand organisers into their Stripe Dashboard for ongoing payouts, disputes, and account maintenance.
Hubbaly now prefills safe hub context into new Stripe onboarding where possible: organiser email, hub name, public website, contact email, and a short hub description if you have set them.
Hubbaly also checks whether the platform paid-ticket path is actually ready for this hub: platform Stripe API access, the primary payment webhook, and Connect checkout rollout/gating when Connect is required.
Old event versus new event is not the deciding factor on its own. The hub’s rollout mode and the checkout path in use decide whether a paid sale is Connect-routed or still using legacy routing.
If Stripe returns with an expired onboarding link, Hubbaly now attempts to request a fresh onboarding link automatically. Continue setup remains the manual fallback if that redirect does not complete.
If you started Stripe setup from a blocked Event Admin action, Hubbaly now carries that context through onboarding and returns you to the original ticket or publish task once payments are actually ready.
If your Hubbaly session expires before Stripe can reopen onboarding, the refresh path now sends you back through Hubbaly login first instead of dropping you on a raw API error.
Stripe Dashboard access is still controlled by Stripe itself. Hubbaly confirms you are allowed to start the handoff, but the final dashboard access depends on the connected account’s Stripe login/team membership.
If Event Admin refunds show 0 Hubbaly fee / 0 Stripe fee on newly sold paid tickets, treat that as a routing/setup signal rather than a cosmetic display issue. It usually means the sale still used legacy checkout or the platform paid-ticket path was not active for that hub yet.
Treat Disconnect Stripe as a reset/relink action, not normal account management. It detaches the current hub-to-Stripe link and should only be used when you intentionally want to restart setup.
Draft events can still keep paid ticket types saved while setup is incomplete, but publishing or changing live paid tickets stays blocked until readiness is real.

Email Campaign Builder (Hub -> Admin -> Email)

Use this workflow for event reminders, logistics updates, and critical community announcements.

Email Studio

Build drafts with audience filters and event context,
Compose with visual blocks and hero/header branding controls,
Keep Live campaign preview open while editing,
Run Preview Audience, then Preview Campaign and Send Campaign Test,
Deliver with Send Now or schedule for a future send time,
Export recipients and outcomes CSV for audit/review.

Email Defaults

Set outbound from name and reply-to once for the hub,
Maintain default header/logo, colour palette, and footer/sign-off,
Pause optional hub and campaign emails when needed.

Template QA

Preview standard templates with sample variables,
Send one-off template tests before major sends.

Guide: Email Campaign Builder

Invite and Join Attribution Controls

Use Hub -> Admin -> Invites to create labeled invites with optional join messages and max-use limits.
Use the hub join policy to control member-led sharing: Open and Request hubs allow member-created tracked share links, while Invite only hubs keep share-link creation with organisers.
If members join from ?code=...&referrer=... URLs and need to sign in first, attribution is preserved after auth.

Operational guidance for member-created tracked share links:

Use Open or Request when trusted members act as ambassadors and you want join or request attribution without making admins issue every link manually.
Use Invite only when onboarding needs to stay tightly controlled by admins, especially during sensitive launches or heavy moderation periods.
Member-created tracked links never bypass hub policy: request-based hubs still require approval, and invite-only hubs do not let members create share links.
Review Share Tracking after member-led sharing so you can see which members are distributing links and whether the resulting joins or requests match the hub’s intent.
In Hub -> Admin -> Invites, use Usage on a share link to inspect current joined members and pending requests for that link, or use Usage in Share Tracking to inspect one creator across all of their links.
Invite search, status filters, and share-link filters refresh server-side while keeping the previous rows visible, so do not interpret a brief Refreshing state as an empty invite list.
Rapid repeated share-link creation is guarded. If Hubbaly asks you to wait before creating more links, pause instead of repeatedly clicking the create action.

Shared details

Use Hub -> Admin -> People -> Shared details when a Pro+ hub collects reusable hub-scoped details through Details to collect.

Configure collection in Hub -> Admin -> Advanced features -> Details to collect.
Use Shared details to review answers people have shared with this hub for interest, joining, invite acceptance, tickets, and events.
Details stay scoped to this hub, are not shared with other hubs, and are visible only to the Hub Admin roles selected for each detail.
Contact-style details and all stored answers are encrypted at rest; contact reveals and exports are audit logged.
Use event forms, waivers, consent forms, and feedback forms for event-specific or signed records instead of turning Shared details into a general record store.

Before publishing each event

Ticket policy and event sales cap confirmed if needed,
Hub payments status reviewed if any paid ticket type is live,
Legal seller details completed when the hub will sell paid tickets,
Event-level and ticket-level ticket notes checked for clarity where buyers need extra guidance,
Required forms attached/published,
Staff assignments and permissions tested,
Event schedule and visibility verified.

Ticket Notes Reuse

Use Event -> Admin -> Tickets when one event or ticket type needs buyer guidance that should appear during selection and checkout.

Start with Event Ticket Notes for shared guidance that should apply across the event.
Add or override notes on a ticket type only when one ticket needs different instructions.
Reuse from this hub is copy-only. It pulls previously used notes from the same hub into the current editor, but later edits do not sync across events or ticket types.
Keep this content practical and buyer-facing. Use it for what someone needs to know before they continue, not for internal ops notes.

Event day

Scanner operators assigned,
Form blockers resolved deliberately,
Critical updates posted clearly,
Attendance and incident logs monitored.

Post event

Attendance and reconciliation reviewed,
Refunds/voids resolved,
Lessons captured for next event.

Identity Verification Review

Use Hub -> Admin -> Verification when Hubbaly has enabled this advanced capability for a selected community and that hub needs a durable private door-check workflow beyond one event.

Keep the hub setting off unless the community has made an intentional trust/safety decision to use it.
Members maintain their own legal name and optional private photo from the hub verification page.
Owners and admins can review those submissions, verify members directly from hub admin, or revoke an existing reviewed state with a reason.
Event-day scanner review is still available, but only for events that explicitly enable it.
If you want door staff to verify at live events, give them the separate VERIFY_MEMBERS event-staff permission.
Start with reusable event staff roles, then use per-person Customise access only when one staff member needs a one-off event exception.
Only owners and admins can grant sensitive event permissions such as VERIFY_MEMBERS or the required ticket-docs override, whether that happens through a role, a per-person override, or an event-staff invite.

Trust & Safety Cases and Bans

Use Hub -> Admin -> Trust & Safety when a conversation, upload, profile, hub, event, or incident needs operator review.

Cases is the shared queue and history view for reports tied to your hub.
The chat, photo, and incident tabs still give you the specialized operator context when that workflow is needed.
Bans and other restrictions should be explainable, deliberate, and recorded clearly.

Good practice:

Review context before acting,
Remember that removed media or manually deleted messages can still appear as restricted evidence in the report flow,
Use the restricted evidence view when you need the preserved text/media itself or the preserved sender identity history,
Expect that preserved evidence can stay in a short moderator-only retention window after the case is resolved before it is purged,
Use dismissal when the report is not actionable,
Use bans for ongoing safety/control issues, not as a default first response.

High-Risk Actions (Pause and Double Check)

Changing community roles,
Bulk member removal,
Destructive moderation actions,
Refund/void actions,
Visibility changes on active published events.

If an Admin Action Fails

Verify active hub context and your role.
Verify event-scoped staff permissions if relevant.
Confirm this is governance vs operations action.
Capture exact error text + URL + UTC timestamp.
Escalate with minimal reproduction steps.

High-Quality Handoffs

Use a consistent handoff note when shifts change or when support/ops takes over:

Open issues and immediate risk,
Actions already attempted,
Decisions made and by whom,
Next owner and escalation route.

Template: Support Playbooks.