Deskie controls who can do what through a role-based permission system. Every person who signs in has one or more roles, and each role grants a fixed set of permissions. This article explains the roles that exist, exactly what each one can do, how location-level access works alongside workspace-level access, and what the superadmin account is. Understanding these roles helps you decide who to invite, what access to give them, and why a teammate might not see a particular page or button.
How the permission system works
Deskie does not check individual abilities one by one. Instead, every action in the app maps to a named permission, and every role is granted a fixed list of those permissions. When you try to do something, Deskie works out your role for the relevant context and checks whether that role includes the permission the action requires.
The permissions Deskie tracks cover the major areas of the product. They include managing the workspace, creating locations, inviting users, and managing billing; managing a location, managing members, viewing analytics, and managing bookings; managing visitors, assets, resources, events, and tasks; sending messages, managing the community feed, and managing tickets; and the basic abilities to view the dashboard, view the calendar, and view members. There is also a single platform-management permission reserved for the superadmin.
Two ideas are worth keeping in mind. First, permissions are tied to roles, not to individual people, so you change what someone can do by changing their role. Second, your effective role depends on context: the same person can be an admin in one workspace and a regular member in another, and Deskie resolves the right role for whatever workspace and location you are currently viewing.
The two levels of roles
Deskie has roles at two levels, and it is important to understand the difference. For background on how workspaces and locations relate, see workspaces and locations.
- Workspace roles apply across an entire workspace and all of its locations. The workspace roles are Owner, Admin, Member, and Guest. There is also a special Staff role that sits outside this ladder and grants access feature by feature; it is covered in its own section below.
- Location roles apply to a single location. The location roles are Admin and Member. A location Admin is referred to in the product as a Manager.
Workspace roles take precedence over location roles. When Deskie decides what you can do, it looks at your workspace role first; only if you have no workspace role for the relevant workspace does it fall back to your location role. In practice this means a workspace Owner or Admin is treated as an admin everywhere in the workspace, regardless of any per-location settings.
Workspace roles in detail
Workspace Owner
The Owner has the broadest access inside a workspace. An Owner can manage the workspace, create locations, invite users, and manage billing. The Owner also has every operational and location-level ability: managing the location, managing members, viewing analytics, and managing bookings, along with managing visitors, assets, resources, events, and tasks. On the communication side, the Owner can send messages, manage the community feed, and manage tickets. The Owner naturally also has the basic abilities to view the dashboard, the calendar, and members.
Workspace Admin
The Workspace Admin role carries the same full set of abilities as the Owner. A Workspace Admin can manage the workspace, create locations, invite users, manage billing, and perform every location, operational, and communication action available in the workspace. For day-to-day operations, treat Owner and Admin as having equivalent reach across the workspace.
Workspace Member
The Workspace Member role is intentionally limited. A Workspace Member can view the dashboard, view the calendar, view members, and send messages. They do not have administrative permissions: they cannot manage the workspace, manage billing, manage members, manage bookings on behalf of others, or manage assets, resources, events, visitors, the feed, or tickets. This is the appropriate role for a regular person who uses the space but does not help run it.
Workspace Guest
Guest is the most restricted workspace role. Guests are deliberately excluded from administrative responsibilities: they cannot hold admin roles, and they are not eligible to be promoted to a location Manager. When you choose who can be given elevated access, guests are filtered out by design. For more on guest accounts, see guests.
The Staff role and custom staff roles
Sometimes the person who needs access is not a member and not a full admin: a cleaning contractor who should only see Tasks, a bookkeeper who should only see Invoices and Payments, a community manager who runs events but should stay out of billing. The Staff workspace role exists for exactly this. Staff sit outside the Owner-to-Guest ladder entirely: they see and can access only the features their staff role grants, and nothing else, not even the member-facing pages.
Staff roles are bundles you define
Under Settings, in the Staff section, you create named staff roles, each a bundle of feature grants, and then add staff users assigned to one of those roles. There are 40 grantable features, organized into the same groups as the admin navigation: Operations (Calendar, Tasks, Notes), People (Members, Teams, CRM, Guests, Visitors, Check-ins, Tours, Waitlist), Space (Plans, Fractionals, Assets, Assignments, Passes, Events, Resources, Layouts, Printing), Hardware (Access, Printers, Point of Sale, Screens), Communication (Messages, Email, Feed, Mail, Tickets, Website, Newsletters), Finances (Invoices, Payments, Coupons, Credits, Expenses, Reports, Digest), and Management (Documents, Files). Not grantable: Timeclock and Schedules, which run on their own location-based staffing model, workspace Settings, and the superadmin surface.
How staff access is enforced
A staff member's navigation shows only their granted features, and the enforcement is server-side, not just hidden menu items: opening an ungranted page directly is refused. Grants map to the underlying permissions, so a staff member granted Invoices can genuinely work with invoices, not merely view the page.
Staff are not members
Staff users have no member profile, no onboarding or agreement flow, and no billing. Adding a staff user sends them an invite email with a link to set their password; the link stays valid for seven days. Only workspace Owners and Admins can manage staff roles and staff users. Deleting a staff role does not delete its people: they remain Staff with zero grants, seeing nothing until they are assigned another role.
Location roles and Managers
Alongside workspace roles, Deskie supports per-location roles so you can give someone administrative control over a single location without making them an admin of the whole workspace. A location role can be Admin or Member, and a location Admin is what the product calls a Manager.
A Manager can operate on everything inside their assigned location, but they cannot see data from other locations in the same workspace. Concretely, a Manager has the location-level and operational permissions: managing the location, managing members, viewing analytics, managing bookings, creating tasks, managing visitors, managing assets, managing resources, and managing events, plus sending messages, managing the feed, and managing tickets, and the basic view abilities. What a Manager does not get are the workspace-wide permissions: they cannot manage the workspace itself, create locations, invite users, or manage billing.
Workspace Owners and Admins automatically have Manager-level access to every location in their workspace. They do not need to be added as a Manager, and they do not appear on a location's Managers list, because they are already shown separately as workspace admins.
A location Member is the equivalent of a Workspace Member scoped to a location: they can view the dashboard, view the calendar, view members, and send messages.
How location access is enforced
Most data in Deskie is scoped to a location. When you have a specific location selected, that location is the only one in view, even for admins, which is what makes switching between locations show the right data. When an Owner, Admin, or superadmin has no specific location selected, they see an "All Locations" view that spans every location in the workspace. A Manager, by contrast, is always limited to the location or locations where they hold the Manager role.
Adding and removing Managers
Managers are added and removed from a location's role settings. Only a workspace Owner or Admin (or a superadmin) can add or remove a Manager. A Manager cannot create more Managers for their own location, which keeps people from escalating their own privileges.
A few rules govern the process:
- The person you promote must already be a member of the workspace. Adding a Manager does not invite someone new into the workspace; inviting people is a separate step covered in inviting and onboarding.
- Guests cannot be made Managers and are excluded from the list of eligible candidates.
- Workspace Owners and Admins appear in the candidate list even though they already have full access, so you can see them, but they are labeled by their workspace role.
- You cannot remove yourself as a Manager.
Superadmin
Superadmin is a platform-level account, separate from the workspace roles above. It is a flag on the user account rather than a workspace membership, and it is reserved for Deskie's own platform operators rather than for coworking space staff.
A superadmin holds every permission in the system, including the platform-management permission that no other role has. Superadmins are treated as admins of any workspace they view, can access all workspaces, and can use the "All Locations" view in any of them, even without an explicit workspace or location role. This account exists for cross-workspace platform administration and support.
Where roles show up in the app
Roles do more than gate server actions; they also shape what you see in the interface. Deskie hides or shows parts of the UI based on your permissions and your effective role, so a Workspace Member will not see admin-only panels and a Manager will not see workspace-level settings that do not apply to them. If a teammate reports that a page or button is missing, the usual explanation is that their role does not include the permission that page requires.
Because workspace roles take precedence over location roles and the same person can have different roles in different workspaces, the safest way to reason about access is always: which workspace and location is this person currently in, and what is their role there.
Choosing the right role
As a quick guide:
- Give Owner or Admin to people who help run the whole workspace, including billing, locations, and inviting others.
- Make someone a Manager (location Admin) when they should run one specific location but should not touch workspace-wide settings, billing, or other locations.
- Use Member for people who use the space and need everyday visibility but no administrative control.
- Use Staff for non-member helpers who need a precise slice of the admin side, like a contractor who should only see Tasks; you define exactly which features each staff role can access.
- Use Guest for the most limited access; guests cannot be given admin or Manager roles.
To learn how people first receive a role when they join, see inviting and onboarding.