Hubs and Community Setup

Hubs are the operating container for events, members, chat, and trust history.

End-to-End: Set Up a New Hub

Create your hub from Create Hub.
Add the core details:
- Name,
- URL,
- Short description,
- Visibility.
Add profile and contact context:
- Tagline,
- Website, email, and social links,
- Non-member visibility choices for private hubs.
Decide access and joining:
- Open, request, or invite-only join policy,
- Simple request intro or application questions if people must ask to join,
- Terms and rules where needed.
Add basic branding:
- Theme colour,
- Banner,
- Logo.
Configure governance:
- Assign ADMIN users,
- Assign MANAGER users for event operations,
- Keep OWNER count intentional.
Create first share links or invites only after the join policy is final.
Create your first draft event and run an internal dry run before external promotion.

Join Policy Decision Guide

Policy	Best for	Tradeoff
Open join	Fast growth, low friction communities	Lower pre-join vetting
Request to join	Trust-sensitive or curated communities	Admin approval overhead
Invite only	Private teams, controlled membership	More manual invite management

Hub Settings

Use the Create Hub page for the first pass. After the hub exists, use Hub -> Admin -> Settings to refine how the hub presents itself and how people join it.

Core Details

Use this section to make the hub understandable before anyone sees a join page or invite.

Name and URL are the only required fields on the create page.
Choose a name and short URL slug you are comfortable sharing widely. This URL cannot be changed after the hub is created.
Use the description to explain who the hub is for, what happens there, and why someone would join.
Visibility decides whether the hub can become a public destination or stays member-only.
Treat these details as the headline summary members and guests see first.

Branding

Branding controls the visual identity of the hub across setup, member pages, and shared links.

Theme colour affects key surfaces across the hub. Choose a colour that still reads clearly in light and dark themes.
Banner and logo are used on hub pages and related surfaces.
Different hub surfaces and screen sizes can show different crops of the same banner.
Treat banners as background art rather than a place for text or precise layout.
Keep important subjects near the centre and away from the edges when possible.
On the create page, selected banner and logo files upload after the hub record is created. If an upload fails, retry from Hub Admin after creation.
Upload the hub banner first if you want to reuse it on the join page later.

The social sharing card is an optional image used for hub link previews in chat and social apps.

Use it when your hub banner is decorative but shared links need a more branded preview.
It can be useful for sponsor or partner lockups, campaign artwork, or a graphic designed specifically for link previews.
You do not need one if the hub banner already works well as a shared-link image.
If you do not upload one, Hubbaly uses the hub banner as the default, then falls back to the logo where needed.
A 1200x630 image is a good target, but it is not a strict requirement and Hubbaly does not block other reasonable image shapes.
Keep important text, logos, faces, and partner marks away from the edges because apps can crop previews differently.
The image affects hub-level share previews first. Event and album pages keep their own images first, then may fall back to the hub social sharing card if they do not have their own image.
Email headers continue to use the email header image, not the social sharing card.
Private hub join URLs stay generic unless the viewer opens a valid share link or invite path.

Profile and Contact

Use this for the public-facing context around your hub.

Add a short tagline for cards, lists, and previews.
Add the few links that help people verify the hub or take the next step, such as website, contact email, and social profiles.
Keep curated links tidy: feature the most important destinations and leave secondary links under More links.
For private hubs, review whether non-members should see non-email links and email/contact links on the join page.
Avoid adding links that create confusion about where people should join, buy tickets, or ask for help.

Access and Joining

This is where you decide who can discover the hub and how they get in.

Visibility controls whether the hub itself is public or private.
Join policy controls whether people join instantly, request access, or must be invited.
Open lets people join instantly.
Request lets people ask to join and wait for approval. On the create page, choose a simple request introduction or an application form with custom questions.
Invite only keeps access controlled through organiser-created invites and tracked links.
Member-created share links follow the join policy automatically: members can share Open and Request hubs, while Invite only sharing stays with organisers.
Private hub overview pages do not expose About/contact/social sections to logged-out visitors.
Public event links can still exist for events marked public, but those event pages do not turn a private hub into a public hub destination.
You can start simple on the create page and refine request copy, application questions, share links, and invites after the hub exists.

Use this as the practical rule: a hub must be public before it behaves like a public destination.

Private hubs do not have a public hub profile page and should not be treated as something people will find through normal search results.
Public hubs can be shared directly and may start appearing in search results over time, but that usually takes time and is never guaranteed.
A public event inside a private hub does not make the hub itself public. People can open the public event page, but that does not turn the private hub into a public browse destination.
If discoverability matters, keep the hub slug stable, use a clear hub name, and write a short description that explains what the hub is for in plain language.
Add website, contact, and social links when they help people verify that the hub is real before they join.

When someone shares a public hub link in chat or social apps, the preview usually comes from the hub’s public metadata.

The social sharing card typically uses the hub name, short description, and a main image such as the banner or logo.
Choose a banner or logo that still reads well in a wide preview crop.
Avoid putting important text near the edges of the artwork, because the social sharing card may crop differently from the hub page itself.
If the preview looks weak, improve the hub name, description, banner, or logo rather than relying on the post text to fix it.

Regular MEMBER users can generate tracked hub share links when the hub’s join policy allows member-led sharing.

Members can create reusable share URLs for Open and Request hubs, so your team can see which member created the link and which joins or requests came through it.
Members cannot create share links for Invite only hubs. Owners, admins, and managers still create invite links from Hub -> Admin -> Invites or the hub share sheet.
Member-created links do not grant staff or admin access, and they never bypass your join policy.

How it behaves by join policy:

Open: a tracked member share link can lead to an immediate join, and the member who shared it is still recorded as the source.
Request: the link still tracks who shared it, but the recipient must still submit a join request. It does not auto-approve or auto-join.
Invite only: member-created share links are off. Use organiser-created share links or email invites instead.

Operational implication:

If member-led sharing creates too much moderation pressure, switch the hub to Invite only until onboarding should be admin-controlled again.
Review Hub -> Admin -> Invites periodically so you can see which member-created links are active and whether their join outcomes still match the hub’s moderation posture.

Hub Settings Join Page Appearance

Use this to shape the first impression for people opening your join page.

Choose whether the join page uses the default gradient, the main hub banner, or a dedicated join-page banner.
Join-page banners also crop differently across screen sizes, so keep important subjects near the centre.
Preview before sharing public or invite links.
Treat join-page banners as background art, not as a precise information layout.

Rules

Rules are for behaviour guidance. They do not create an acceptance record on their own.

Use rules to explain how people should participate, what is welcome, and what is not.
Turn on Show rules on the join page when you want prospective members to see expectations before joining.
Keep rules short, direct, and easy to scan.
Use the starter template if you need a first draft, then remove anything that does not fit your hub.
Use terms instead when someone must explicitly accept a notice before joining.

Terms

Terms are for acceptance, not just guidance. They can also be your member terms and privacy notice.

Publish terms when members need a stable notice about membership, privacy, waivers, or other required conditions.
Turn on Require terms acceptance to join only when people must explicitly agree before becoming members.
Use it to tell members what data you collect, why you collect it, who can see it, and how long you keep it.
Keep the title simple and the content current. The create page can use the starter template, but you are responsible for making the wording accurate.
Do not require terms until the content is actually ready to publish.
Review terms whenever you add applications, reusable details, event forms, waivers, photos, attendance workflows, exports, or new staff access.

Details to collect

Hub -> Admin -> Advanced features -> Details to collect is for reusable hub-scoped details such as full name, phone number, organisation or group, or another operational detail you need across interest, joining, invite acceptance, tickets, or events.

It is a Pro+ feature and starts off disabled by default.
No additional details are collected unless you add a detail and choose where it is required.
Answers are encrypted at rest, stay with this hub, and are not shared with other hubs.
Answers are visible only in Hub Admin to the owner/admin/manager roles you choose for each detail.
Members can review their own shared details from Account -> Shared details or the hub’s own Shared details page where they still have access.

Use reusable hub-scoped details for information you need again, such as a workshop organiser needing a full name and phone number. Use event forms, waivers, consent forms, or feedback forms for event-specific answers, signed records, anonymous feedback, or anything that needs its own retention and consent context.

Owner Privacy Responsibilities

Hubbaly handles platform account, login, payment, security, and operational processing. When hub owners decide why and how hub-specific member data is collected, used, shared, exported, and retained, they may be controllers for their own hub activity, and Hubbaly may support that activity under its DPA as processor.

Before inviting members, make sure you can answer:

What member data do we need for this hub, and what is optional?
What is our lawful basis for collecting it?
Who can see it: owners, admins, managers, event staff, members, public visitors, or exported tools?
How long do we need memberships, application answers, attendance, photos, messages, and incident records?
Are we collecting special-category data such as health, disability, religion, safeguarding, child, or criminal-offence information?

Practical rules:

Do not collect more than you need.
Put member-facing privacy details in the hub terms/privacy notice before collecting reusable details, applications, waivers, photos, attendance details, or sensitive data.
If you export member lists or form answers, protect the export and delete it when it is no longer needed.
Review the notice when you change join forms, event forms, photo usage, attendance workflows, exports, or staff access.
Ask for legal advice before collecting sensitive or child-related information in a live hub.

From your active hub admin area (Hub -> Admin -> Invites), you can:

Create tracked share links,
Set expiry and usage limits,
Send role-targeted invites by email,
Add join messages for recipient context,
Review invite usage outcomes (joined, pending, no longer member),
Revoke links and invites when needed.

Operational notes:

Admins can allow/disable member share-link creation from Hub -> Admin -> Settings.
Multi-use invites remain valid until the configured max-use limit is reached.
Re-opening the same invite as the same account is idempotent (it does not consume another use).
If join requires sign-in, share/referrer attribution in the join URL is preserved after login.

Private Hub Guest Surfaces

If a hub is private, treat the guest-facing surfaces as narrow entry points, not as public profile pages.

The main hub overview does not advertise About/contact/social information to logged-out visitors.
Public albums are not promoted from the private hub overview page.
The hub photo index and timeline are not general browsing surfaces for non-members, even if a specific public album URL is shareable.
Direct URLs to specifically public resources can still work when policy allows, but they should not be treated as general browsing entry points into the hub.

Public Hub Photo Browsing

If a hub itself is public, the photo surfaces can be a legitimate discovery path for non-members.

PUBLIC albums can be browsed by logged-out visitors and by logged-in accounts that have not joined the hub yet.
Logged-in non-members should still see the hub as public-but-not-joined, not as a signed-out viewer.
Member-only or otherwise restricted albums remain hidden from the general photo index and timeline.
Direct links to restricted albums stay unavailable until the viewer has the right membership or event relationship.

Email Invites

Use email invites when you know exactly who should be brought in.

Choose the target role carefully before sending.
Add a join message when recipients need extra context.
The Bypass join request/application flow toggle only appears for request-gated hubs, and it defaults on there.
Use event staff invites when access should be tied to one event workflow.

Pending Email Invites

This list shows invites that are still live and waiting to be used.

Check expiry dates.
Revoke invites you no longer want active.
Use the copied invite link if you need to resend it manually.

Invite History and Usage

Use these views to understand what happened after sending or sharing access.

Invite History shows completed, expired, or otherwise non-pending invites.
Invite Usage shows whether someone joined, is still pending, or is no longer a member.
Review this after campaigns, ambassador pushes, or moderated onboarding periods.

Share links are useful when you want a reusable tracked join path instead of a one-person email invite.

Set expiry or max-use limits when you want tighter control.
Use the full invite manager when the recipient should be granted access to an invite-only hub.
Review creator totals in Share Tracking if multiple admins or members are distributing links.
For Open and Request hubs, member-created share links are available automatically. Creator attribution is part of the point: admins can see which member created the link and what happened after it was used.
The Share Links list shows use counts per link, and each link now has a Usage action that shows current joined members and pending requests attributed to that link.
Share Tracking shows creator totals such as links created, direct joins, current joined members, and pending requests.
Each creator row in Share Tracking also has a Usage action so admins can inspect joined members and pending requests across all links that creator has issued.

Join Requests and Approvals

Use Hub -> Admin -> Approvals when your hub uses request-based access.

Review pending requests promptly so people do not sit in limbo.
Expand request details before approving if your hub uses a request intro or application form.
Keep approvals consistent with the hub’s published join policy.

Role Snapshot

OWNER: full control shared with the other owners, including owner-role changes, full-handoff ownership transfer, and destructive controls.
ADMIN: full admin except owner-role changes and ownership transfer.
MANAGER: event/ticket operations and day-to-day channel setup, not full governance.
MEMBER: standard participation.

If another owner is already in place, an owner can step down to ADMIN from Hub -> Admin -> Settings. Use full ownership transfer only when the recipient is not already an owner and needs to accept the handoff.

Full matrix: Roles and Permissions.

Hub Chat and Support Channels

Use hub chat for long-lived community discussion, and keep event-specific coordination inside the event.

/chat can now start direct messages, private groups, hub channels, and event channels from one creator.
Hub -> Chat reuses that same creator with the current hub already selected.
Use Hub -> Chat when you want to manage the durable hub roster: create channels, rename them, and decide whether they are for all hub members, invite-only groups, or an intentionally open space.
Put temporary event coordination in Event -> Admin -> Chat instead of filling the hub with one-off event channels.
Decide your default support path before launch, for example a broad General channel plus a smaller staff or ops channel for the organising team.

Door-check details

For selected communities, Hubbaly can enable this advanced workflow. If the hub then turns it on, members can maintain private door-check details for events that use it.

Open Hub -> Verification to save your legal name and, if useful, an optional private photo.
Changing those details can move a previously reviewed record into Needs re-review until someone checks it again.
Owners/admins can review those records from Hub -> Admin -> Verification, and events can choose whether scanner operators can reveal them at the door.

Pre-Launch Checklist (Before You Invite Members)

Join policy is intentional and tested.
Core admin team and escalation owner assigned.
Terms/rules and member privacy notice (if used) reviewed and published.
First event drafted with ticket and forms strategy.
Alert and chat channels ready for member support, including any first event-specific channels.

Common Setup Mistakes

Too many owners too early

Keep ownership limited. Multiple owners are valid, but use ADMIN for most trusted operators and reserve OWNER for the few people who truly need equal control.

Publishing invite links before policy is finalised

Set join policy and governance first so early members enter the intended experience.

Blurring manager and admin responsibilities

Use managers for event execution and day-to-day channel operations, not hub governance and role control.