People & permissions

A workspace usually has two kinds of people in it: the ones who run it, and the ones who just use it. Cobblr treats those differently, and lets you get as granular as you need in between.

Managers and members

Whoever runs the workspace (the owner, admins, editors) works in the full interface: every module, the configuration hub, the builder. People with the roles below that, members and guests, start with almost nothing and see only what you've granted.

That split is what makes it safe to bring people in. A club volunteer or a shop worker doesn't need the workspace; they need their job's screen.

Granular grants

Below the broad roles, permissions are individual capabilities: adjust stock, create a part, run this action. You can grant them two ways:

• Directly to a person, one capability at a time.
• As a custom role you define: bundle the capabilities a job needs ("counter staff" can look up parts and adjust stock, nothing else) and assign the role to whoever holds that job.

What someone can't do is also what they can't see. The interface hides what a person lacks the capability for, and the server withholds it either way; the two are resolved from the same source, so there's no gap between them.

The member portal

Members don't land in the admin interface at all. They sign in to a slimmed-down portal and go straight into the custom app you built for them; with several apps, they get a launcher. Combined with an app's read scope and their grants, a member's whole experience can be one focused tool: scan things in, check things off, see the list that matters to them, and nothing else.

A workspace can even run app-first for everyone, hiding the builder chrome behind a "grow door": the app feels like a standalone product until someone with the permission steps through into full Cobblr.