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 the admin chat pages for ongoing channel control.

/chat can create direct messages, private groups, hub channels, and event channels from one shared creator.
Hub -> Admin -> Chat is the durable roster view for hub channels.
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.
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.

Campaign 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 from name and reply-to once for the hub,
Maintain default header/logo, colour palette, and footer/sign-off,
Define non-essential email policy for your hub.

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 Hub -> Admin -> Settings to control whether members can create tracked share links.
If members join from ?code=...&referrer=... URLs and need to sign in first, attribution is preserved after auth.

Operational guidance for Allow members to create tracked share links:

Turn it on when trusted members act as ambassadors and you want join or request attribution without making admins issue every link manually.
Leave it off 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 generate join-granting links.
In invite-only hubs, member-created links are view-only; in private invite-only hubs, members are blocked from creating them entirely.
Review Share Tracking after enabling it 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.

Before publishing each event

Ticket policy and capacity confirmed,
Hub payments status reviewed if any paid ticket type is live,
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 OVERRIDE_CONSENT, whether that happens through a role, a per-person override, or an event-staff invite.

Moderation Chat Reports and Bans

Use Hub -> Admin -> Moderation when a conversation, upload, or incident needs operator review.

Reports is the queue for chat issues members have flagged.
Bans shows who is currently blocked from hub chat.
Photo moderation and incident review should be treated as the same operational posture: act deliberately, capture the reason, and keep the outcome explainable.

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.