Joining and growing your WorkHive hive (your team's private workspace)

What a hive is, in concrete terms

The hive is WorkHive's team workspace: a private space for one plant's team. One plant equals one hive. Inside the hive:

• People: every worker who has joined this hive with their role and skill matrix
• Assets: the canonical asset register in Asset Hub
• History: all logbook entries, PM completions, fault notifications, parts consumption
• Schedules: PM plans, shift handovers, day planner blocks
• Knowledge: AI Assistant context trained on this hive's data

Workers in Hive A cannot see Hive B's data. Period. No path through the UI, no path through the API, no path through the AI assistant. This is the foundation that lets a Cabuyao chocolate factory and a Cebu food plant both use the same WorkHive platform without ever leaking data to each other.

Solo mode: WorkHive without a plant

Many workers do not have a plant hive yet. They might be:

• A freelance maintenance engineer between contracts
• An OFW-track new graduate building a portfolio for the Saudi or UAE market
• A contractor whose client has not adopted WorkHive yet
• A student learning industrial maintenance during practicum
• A worker whose plant is still on paper and they want to start digital personally

Solo mode is for them. Sign up with a username and password - no email needed - and get the full WorkHive toolset (Logbook, Engineering Design, Skill Matrix, AI Assistant, Day Planner) scoped to a personal hive of one. Solo data stays private; nobody else sees it. Joining a plant hive later does not move any of it: there is no import step, and no choice to make. Your solo hive stays yours and keeps its entries; the plant hive is a second membership alongside it. Your skill badges are held against your name rather than against either hive, so those show up wherever you are.

This is one of the under-told values of WorkHive: it works as a personal professional toolkit, not only as a plant tool.

How to join an existing plant hive

Three steps:

1. Sign in or create an account. Username plus password, no email needed; takes about 30 seconds.
2. Enter the hive code. Your supervisor gives it to you. There is no public directory of plants to browse: deliberately, because a searchable list of which plants use which software is not yours to publish.
3. Request to join. You join as a worker; there is no role to pick. The supervisor sees the request and approves it, and can promote you afterwards if your job calls for it.

After approval, the worker gets immediate access to the hive's tools. Existing logbook entries become searchable; PM assignments start appearing in their queue.

Two roles, and four ways to view the same nav

This trips people up because the words overlap, so take them separately.

There are two ROLES: worker and supervisor. That is the whole list. Creating a hive makes you its supervisor. Everyone who joins is a worker until a supervisor promotes them. A supervisor can approve and reject join requests, remove members, publish a shift plan, recompute risk scores, and read the full audit log; a worker does the maintenance work and records it.

Separately, the navigation has four VIEW MODES — All, Field, Supervisor and Engineer: which filter which tools you see so a technician is not scrolling past integration settings to reach the logbook. Switching to Engineer view does not grant you anything; it is a lens on the same menu, and anyone can switch it.

Two gates are worth separating from both: the full audit log is supervisor-only, and the AI Quality dashboard is gated by the hive's maturity stair rather than by anyone's role: a hive earns it, a person is not granted it.

Data isolation between hives

Multi-tenancy in industrial software is hard because the consequences of leakage are severe. A competitor seeing your fault history, a supplier seeing your consumption forecast, a contractor seeing your cost data: any of these is grounds for losing the platform's trust.

WorkHive enforces isolation at three layers:

• Automatic per-hive data isolation: every query the app makes is scoped to your hive's ID on the database server itself, so one hive can never read another's records. There is no "view all" backdoor.
• API token scope: integration tokens are bound to a single hive. A leaked token for Hive A cannot retrieve Hive B's data.
• AI assistant context: the AI's vector store and retrieval index are partitioned per hive. The AI literally cannot answer a question with another hive's data because it cannot read it.

Cross-hive access exists but only via explicit, scoped, named permissions: a contractor whose work spans multiple plants, a supplier on consignment stock across a network. Default is total isolation.

Running several plants

Filipino conglomerates often run 3 to 20 plants across the country. The pattern that works:

• Each plant is its own hive. Day-to-day operations stay autonomous; each plant's supervisor manages their own membership and PM schedule.
• There is no group layer yet. A corporate roll-up across child hives: one dashboard showing PM compliance, MTBF (mean time between failures), MTTR (mean time to repair) and OEE (overall equipment effectiveness) for every plant: is on the roadmap and not in the product, so a director wanting the comparison today collects it per plant. Worth knowing before you plan a rollout around it.
• Per-plant benchmarking becomes natural. Plant A's PM compliance is 87 percent; Plant B's is 62 percent. The corporate team can see the gap and dispatch help.

Frequently asked questions

Sources

• Supabase, Row Level Security documentation. The PostgreSQL feature WorkHive uses to enforce hive isolation at the database layer.
• WorkHive platform positioning, "Four Gaps One Hive" with the hive as the per-plant boundary. workhiveph.com
• Related WorkHive guides: Digital logbook rollout · Skill matrix