What Weblabor Teams is
What the team layer adds to Weblabor Base, what it changes, and where the rest is documented.
Weblabor Teams is Weblabor Base with the team as the unit of your product. You clone it, build on it and merge the base into it for as long as the project lives. Read this first to know what the team layer adds, what it changes in the base, and which guide covers each part.
What it is built on
Everything Weblabor Base ships is in this kit, unchanged: accounts and sign-in, the account area, the admin panel, roles and permissions, plans and add-ons on Stripe, notifications, web push and the PWA, two languages, timezones, country detection, the public site and this help centre. None of it is documented again here. The base has its own site at base.wbor.dev, and its help centre at base.wbor.dev/help is where you install, configure, deploy and extend the shared part.
The base's own folders stay in the repository, docs/weblabor-base/ and resources/views/landing/weblabor-base/, untouched and unused. Everything about teams lives in docs/weblabor-teams/ and resources/views/landing/weblabor-teams/, so a merge from the base never fights it.
What the team layer adds
- Teams. A
Teammodel with a name, a description, a logo, extra fields of your own and an owner. A person creates as many teams as they want and belongs to as many as they are added to. See Teams and the team switcher. - A workspace per team. After signing in the person picks a team and every screen under
/teamruns inside it: its dashboard, its settings, its members, its roles, its plan. Switching teams switches all of it. - Members and invitations. Someone is added by email, phone or username. An existing account joins immediately; a new one is invited to register, or has its account created on the spot, depending on one config key. See Members and invitations.
- Roles per team. Each team has its own roles on Spatie Permission's teams mode, an owner role with every team permission, and a default role for new members. The team writes more roles from its own screen. See Team roles and permissions.
- Billing per team. The plan, the add-ons, the card, the invoices and the usage limits belong to the team, through a billing adapter that comes in the kit as
packages/billing-team. See Team plans and billing. - Files and storage per team. One shared file library the team works in, and a storage quota you set on the team's plan and sell more of. The team logo lives there too. See Team files and space.
- A team's data, moved between environments. From its settings a team packs everything it owns into a zip and loads it into a team somewhere else, files included. What travels is read from the relations your own
Teammodel declares, so the tables you add come along without touching the exporter. See Move team data between environments. - Teams in the admin panel. Two resources, teams and memberships, with the billing panel of each team. See Teams in the admin panel.
What it changes in the base
The base is merged, not rewritten, but a few things mean something different once the team exists. Keep them in mind when you read a base guide.
| In Weblabor Base | In Weblabor Teams |
|---|---|
| After sign-in the person lands on their own dashboard. | After sign-in the person lands on /app, the team switcher, and then in the team's dashboard at /team. |
One permission guard, web. |
Two: web for the admin panel and the switcher, team for everything inside a team. The same policy class picks the right one. |
| Roles are global. | Global roles for the admin panel, plus roles scoped to each team. |
The subscription belongs to the user, managed from /account/plans. |
The subscription belongs to the team, managed from /team/plans, /team/add-ons, /team/billing and /team/payment-methods. |
| Categories are global. | Categories belong to the team that created them. |
| The file library and the storage quota belong to the person. | They belong to the person and to the team: /app/media is personal, /team/media is the team's shared one, each with its own quota. |
| A new registration creates an account. | A new registration also joins every team that invited that email. |
The account area at /account, the profile, the sessions, the notifications and the language stay personal: they follow the person into every team.
What the kit is good for
A product sold to companies, agencies, clinics, schools, studios: anything where several people share one account and one bill, and one of them decides who gets in. A product where the same person works for more than one customer. A product that needs the base's admin panel to see every customer and what each one pays.
What it is not for
A product with one account per person and nothing shared, where the base alone is the shorter road. A product where the tenant needs its own database: Weblabor Teams isolates by a team_id column and a permission context, not by connection.
Where to go next
- Get it running on the base's site, which applies as it is. Then Configure teams for the keys the team layer adds.
- Teams and the team switcher for what the person sees first.
- The team context and Build a team-scoped CRUD before writing your first screen inside a team.