Hubs & Hub Settings

Hubs are the primary shared spaces where activity happens inside a MustardHub Workspace. Each Hub represents a specific area of focus such as a team, location, topic, or recurring theme, and provides a consistent place for posts, recognition, updates, and shared visibility.

Rather than functioning as static folders or announcement boards, Hubs are designed to support ongoing participation. They give structure to where activity appears, who can contribute, and how recognition and points show up.

If you selected or named Hubs during onboarding, those choices simply established which spaces exist. To learn more about creating Hubs at onboarding, see B.3: Selecting & Creating Hubs at Onboarding.

How Hubs Function

Once your Workspace is active, Hubs operate continuously in the background. They do not require active management to function, and most activity within them is driven by normal use of the platform, not deliberate configuration.

Each Hub acts as:

A container for posts and recognition tied to a specific context
A way to shape who can contribute and how visible activity is
A signal that helps organize what appears across the Workspace

Hubs are not isolated. Activity that happens in a Hub can surface elsewhere in MustardHub, depending on visibility and discovery settings, but the Hub remains the structural home for that activity.

Hubs, Visibility, and the Discovery Feed

[show screen capture image of Hubs & Discovery in left rail]

Hubs and the Discovery feed work together.

A Hub defines where something originates. The Discovery feed is an aggregation of activity from Hubs. Posts created in a Hub can appear in the Discovery feed based on their visibility settings and the user’s access.

[show screen capture image of post audit trail in Discovery feed showing what Hub the post originated in]

This allows activity to feel connected across the Workspace without requiring every member to actively browse every Hub. Changing Hub settings affects how activity flows, not whether the Hub itself exists or functions.

To access Hub settings, click on the Hub name at the top of the page.

[show screen capture image of Hub title at the top of page highlighting it]

For a deeper explanation of posts, reactions, boosts, and feed behavior, see C.4: Posts & Interactions (Overview).

Hub Types and Their Mental Models

[show screen capture image of Hub type choices]

Each Hub operates in one of two structural modes. This choice determines who can create posts and how participation is shaped over time. Not all Hubs are required to have the same settings. Different Hubs can have different settings, allowing Organizations to segment who participates and how, when that level of control is needed.

Admin-Powered Hubs

[show screen capture image of Admin-Powered settings]

Admin-Powered Hubs are designed for structured, intentional communication.

In these Hubs:

Only Admins can create new posts
Members cannot initiate posts
Admins may allow or disallow
- Member visibility

- Reactions and comments on posts
Peer-to-Peer Giving is limited to Boosts only, when allowed

This structure is often used when the Hub’s purpose is clarity, consistency, or alignment rather than open-ended discussion. Activity still occurs, but it is guided rather than initiated by members. Examples include company announcements or staff reminders.

Community-Based Hubs

[show screen capture image of Community-Based settings]

Community-Based Hubs are designed for shared participation.

In these Hubs:

All members (including Admins) can create new posts
Member visibility is always enabled
Members can react and comment on all posts
Admins may enable Peer-to-Peer Giving

If Peer-to-Peer Giving is enabled, Admins can optionally set a per-post point limit per recipient, or establish no limit.

[show screen capture image of p2p limit settings]

This structure supports organic conversation, recognition, and shared participation.

Points and recognition in Hubs

[show screen capture image of points visibility settings]

Regardless of Hub type, Admins can always award points on behalf of the company.

For both Admin-Powered and Community-Based Hubs, Hub-level settings control how points appear on posts in the feed. These display options include:

Showing points with the amount
Showing points without specifying an amount
Hiding points and amounts entirely

These controls affect presentation, not whether points are awarded or tracked. They exist to support different cultural preferences around visibility and signaling.

Every Hub is created with defaults that are designed to work for most teams without adjustment. These defaults prioritize:

Predictable behavior
Gradual participation
Low Administrative overhead

Changing settings is optional. Nothing breaks if settings are left as-is, and normal engagement patterns often emerge without intervention. Settings exist to support intentional design, not constant tuning.

Setting recommendations

Most Admins make only a small number of deliberate decisions about Hubs over time.

Common intentional decisions include:

Choosing whether a Hub should be Admin-Powered or Community-Based
Deciding if Peer-to-Peer Giving belongs in a particular Hub
Adjusting how visible points are in sensitive or formal contexts

Settings that are often left unchanged:

Default visibility behavior
Reaction and comment availability when aligned with the Hub type
Point display defaults once a preference is established

There is no expectation that every Hub needs unique configuration. Consistency across Hubs is often more useful than precision.

Ongoing Hub management

Hubs are not fixed. Admins can:

Add or remove members from individual Hubs
[show screen capture image of adding/removing members settings]
Edit or archive existing Hubs without affecting past activity
[show screen capture image of archive hubs button]
Create new Hubs as needs evolve
[show screen capture image of adding hubs button]

These actions adjust participation and scope without changing historical behavior. Managing Hubs is about shaping future participation, not correcting past usage.

For role-based considerations and access details, see C.5: Members, Roles & Permissions.