Chat and Notifications

Use chat for conversation and alerts for actionable system state.

Mental Model

Alerts = triage stream (what changed, what needs action).
Chat = conversation stream (team and member discussion).

Treat alerts as your queue, chat as your workspace.

Daily Operating Flow

Open Alerts and clear actionable items first.
Jump from alerts into event/hub/ticket context.
Continue discussion in Chat when coordination is needed.
Return to alerts to verify the state change is complete.

Use Share location in the chat composer when you need to send your current position as a one-off message.

Hubbaly requests your current browser location for that share. Your browser may ask for permission if it has not already been allowed for this site.
Hubbaly shows a confirmation dialog before posting.
The message appears as a map card in that chat only.
It does not start live tracking and does not save the location to an album.

Delivery Setup

Use Notification Delivery for:

Push subscription health,
Email preference controls,
Repair and diagnostics tools,
Test send actions.

Moderator Messages and Safety Follow-up

Some Trust & Safety follow-up arrives as a normal direct message in Chat.

Use the matching case entry in Safety to see which report or outcome the follow-up belongs to.
Use Chat for the actual conversation with the moderator.
If you manage a hub moderation queue, keep Moderation & review enabled in Notification Delivery so new reports and queue-owned updates do not go missing.

Mention and Channel Boundaries

Mentions are scoped to valid channel members.
If someone cannot be mentioned, verify they are in the channel.
Event and hub privacy settings can affect who can see, join, and mention people in a channel.

Per-Chat Notification Preferences

Each chat has its own notification choice in chat settings:

All messages — every new message notifies you.
Mentions only — only @ mentions notify you. The chat still appears in your inbox.
Off — no notifications for this chat. The chat still appears in your inbox.

The choice is per-chat, so you can keep a busy hub channel on Mentions only and an event coordination chat on All messages without affecting the other.

@everyone in Group Chats

@everyone notifies the people who are currently in this channel. It is restricted:

In hub and event channels, only community owners, admins, and managers can use @everyone.
In direct group chats, only the channel owner or moderators can use it.
Direct one-to-one chats do not have a group mention.

@everyone does not override personal preferences. Anyone who set this chat to Off will not be notified, and people who left an auto-added chat are not pulled back in. If you are not allowed to use @everyone, the suggestion does not appear in your composer; if you type it manually, the send is rejected with an error so you do not accidentally feel like you reached the room when you did not.

The @everyone suggestion shows the audience size when available, for example Notify 42 channel members, so you know what your message will reach before you send.

@here is reserved for a future presence-based mention; today it is parsed but not delivered as a notification.

Starting Chats and Channels

Open Chat when you want to start a direct message, private group, hub channel, or event channel.

/chat is the universal create entry point for all four conversation types.
The creator now uses the same plain-language flow everywhere: choose what you are starting, where it belongs, who it is for, and what it should be called.
Hub and event pages reuse the same creator with the current scope already selected, so you do not have to choose the hub or event again.
Organisers can also create hub or event channels directly from /chat by searching for the hub or event they manage.
Use Hub -> Chat and Event -> Admin -> Chat when you need to manage an existing channel roster over time.
Members still experience one inbox model, with hub/event labels and imagery doing the separation work.

Hub Channels

Use Hub -> Chat when you need to manage which hub channels exist and who can access them.

General is for broad hub conversation.
Staff is for staff-only coordination.
Custom lets you create a purpose-built channel for a specific group or workflow.
Owners and admins can also rename, disable, and restore hub channels from the management panel on that page, while managers can still create long-lived support or ops channels there.
Hub organisers can still use /chat for quick one-off starts when needed.

Access rules matter:

All hub members means every member can see and post in the channel.
Invite only means access is limited to the people you explicitly add.
Open is the loosest setting and should be used deliberately.

Access rule and how people join are separate questions:

Let eligible people join is the default. Eligible people can find the chat and join when they choose. Most channels should use this.
Add eligible people automatically adds the current eligible audience for that channel now, then adds future eligible people automatically. Use sparingly: it is appropriate for channels where every eligible person should land in the conversation, such as a hub-wide general channel or an event ticket-holder chat.
To include people outside the channel audience, use Add groups in channel settings (for example, add owners + admins to a ticket-holder chat).
People who are added automatically can still leave. If they do, the chat remembers their choice and will not re-add them on a later sync.
Invite-only channels and direct groups are always join-when-asked, never automatic.

Before creating a new channel, answer these questions:

Who needs to see this?
Who needs to post in it?
Is this a permanent hub channel or a temporary coordination space?
Should eligible people join when they choose, or be added automatically?

Event Chat Channels

Use Event -> Admin -> Chat as the main place to manage the event channel roster.

Ticket holders means anyone with an active ticket for that event can join, even if they are not a hub member.
Ticket holders who are members keeps the event chat inside the hub membership boundary for public-event/private-hub cases.
Staff is for event staff coordination.
Verified attendees (after check-in) is a later/additional channel for people whose attendance has actually been confirmed.
Organisers can rename event channels to match the job, such as Door team or Afterparty chat, without changing the underlying audience rule.
Use Event -> Admin -> Chat when you need to manage the live event channel roster over time.
Event chat appears once the event has at least one active event channel, and it disappears from the event page again when there are no active event channels left.
If you disable one event channel on purpose, you can restore it later from Event -> Admin -> Chat.
Use event updates for organiser announcements. Event chat no longer includes a separate event announcements channel.

Editing A Channel After Creation

Access rules stay fixed after a channel is created, but two things stay editable:

Channel name. Rename a channel to match the job at any time.
Membership behavior. Toggle between Let eligible people join and Add eligible people automatically as the channel grows or quiets down.

You can change both in two equivalent places:

In-chat, open the header overflow menu and pick Chat details. The same surface opens for direct messages, private groups, hub channels, and event channels.
In the channel roster, use Hub -> Chat -> Manage channels or Event -> Admin -> Chat and edit the channel from there.

Direct messages and invite-only channels do not expose membership behavior because they are always join-when-asked.

New-event setup can create initial event channels through the same canonical channel-creation flow. Each preset you select gets its own membership behavior picker, so you can ship a hub-wide ticket-holder chat as auto-add while keeping a staff chat as opt-in. The setup is purely a convenience; chat itself stays channel-driven and is managed afterwards from Event -> Admin -> Chat.

Saving Chat Photos to an Album (Pro+)

Pro+ hub channels can automatically save still-image photos posted in a channel to a chosen hub album. This is useful for capturing event memories without asking people to upload separately.

For hub owners: Before any channel can use this feature, enable “Save chat photos to an album” in Hub Admin -> Advanced features. This is a one-time hub-level opt-in (requires Pro+).

For organisers: Once the hub-level option is on, open channel settings (Chat details in the header overflow, or Hub -> Chat -> Manage channels) and pick an album in the Save photos to album section. Only albums belonging to the same hub are available. Clear the selection to stop saving.

For people posting photos: When a destination album is configured, you will see a notice in the channel: “Photos you send here are also saved to [Album].” The album name is only shown if you can access that album. Your original photo (including date, camera, and location metadata) is saved to that album as a full-quality copy. The chat message itself still shows the normal optimized chat image. GIFs and video are not captured.

Whether location coordinates from your photos are ever shown to album viewers depends on two settings, both off by default: the hub-wide Show photo locations and metadata in albums option in Hub Admin -> Advanced features, and the per-album Show photo locations on the map setting. Locations are shown only when both are turned on.

When Notifications Fail

Confirm browser notification permission is Allowed.
Run push repair in Notification Delivery.
Confirm topic-level delivery preferences are enabled.
Check blockers/extensions/shields.
Send a test notification and capture result.

If still failing, escalate with URL + UTC timestamp + subscription diagnostics.

Alert Hygiene Best Practices

Clear or archive read alerts regularly.
Use selection mode for bulk cleanup after high-volume periods.
Keep critical alert types enabled for event-day operations.