Native "Spaces" / Pages — entity profiles distinct from Groups and Member Profiles

BuddyBoss currently offers two container types: Member Profiles (a person) and Groups (a community of people). There's no native way to represent an entity — a business, brand, organization, venue, team, or public figure — that members can follow rather than join. This is the Facebook Pages model, and it's arguably the biggest structural gap between BuddyBoss and mainstream social platforms.

The problem

Site owners who need entity profiles today have to choose between bad workarounds:

  • Repurposing Groups — but Groups imply membership and peer discussion, not a brand publishing to followers. Group admins, join requests, and forums are the wrong mental model, and "Join Group" is the wrong call to action for a storefront or organization.
  • Repurposing Member Profiles — creating fake "user" accounts for businesses, which pollutes member directories, breaks analytics, and violates the one-person-one-account assumption.
  • Third-party plugins (SpacesEngine) — which proves the demand exists, but adds another paid dependency, another update cycle, and integration seams (activity feed, notifications, search, app support) that a native feature wouldn't have.

Communities that need this include marketplaces (seller storefronts), local/city networks (venues, restaurants, services), professional networks (companies, agencies), fan communities (creators, teams), and nonprofit hubs (member organizations).

Proposed feature

A third first-class object type — "Spaces" (or Pages) — with:

Core

  • Space profile: cover/avatar, description, category, contact info, location, links, business hours
  • Follow model (one-directional) instead of join/membership
  • Space-authored posts that appear in followers' activity feeds, clearly attributed to the Space, not the individual admin
  • Multiple roles per Space: Owner, Admin, Editor (post as the Space)
  • A Spaces directory with search and category filtering, parallel to the Members and Groups directories
  • Frontend Space creation with optional admin approval, and per-membership-level limits on how many Spaces a member can create

Integration points

  • Activity feed, notifications, mentions, and moderation all Space-aware
  • BuddyBoss App parity (this is where third-party plugins struggle most)
  • REST API endpoints for Spaces, so headless and custom builds can consume them
  • Hooks/filters so developers can extend Space types (e.g., a "Store" space type with WooCommerce product tabs)

Later / optional

  • Verified badge support
  • Space-level analytics for owners (follower growth, post reach)
  • Reviews/ratings on Spaces
  • Paid Space tiers via existing membership plugin integrations

Why native, not plugin territory

Entity profiles touch nearly every subsystem — feeds, notifications, search, the app, moderation, REST API. That's exactly the kind of feature that fragments when left to third parties: SpacesEngine works, but its existence (and price point) shows customers are already paying for this and would prefer it in the platform. Facebook, LinkedIn, and even Discord (community servers vs. verified brand servers) all treat entities as first-class. A community platform without an entity object caps the use cases BuddyBoss can serve.

Minimum viable version

If full scope is too large for one release: Space profiles + follow model + Space-attributed posts in the activity feed + a directory. Roles, app parity, and API can follow. Even the MVP eliminates the fake-user-account workaround.