Roles and permissions: control who sees what

A role in Beebole is a named set of permissions that controls what its holders can see and do. Every person has exactly one role, and each permission in a role sets two levels — View and Edit — scoped to targets such as Me, Managed people, or Managed projects. This page explains how roles work and what every permission controls.

​

How roles work

Roles live in Settings > Person Roles — click the button with your initials at the bottom of the sidebar to open Settings. Each role is a grid of permissions with three pieces:

• Permission — the area of Beebole it controls, such as Timesheet entries or Billing rates.
• Edit — the targets whose data the role can create, change, or delete.
• View — the targets whose data the role can see.

A permission with nothing selected shows Not allowed: people with that role don’t see that area at all. Two permissions — Timesheet entries and Reports — are simple on/off checkboxes instead of target selectors. Edit access always includes view access. When you add a target under Edit, Beebole adds it to View automatically; when you remove a target from View, it is removed from Edit too. At the top of the grid, the Admin role (full access) checkbox grants everything at once. Checking it replaces all individual permissions with full access; unchecking it clears the role so you can build it permission by permission.

​

Creating and managing roles

There is no Save button — every change to a role is saved automatically and applies to everyone holding that role. To manage an existing role, open its ⋯ action menu in the roles list: Duplicate copies the role with all its permissions, Archive hides it, and Delete removes it. Every new Beebole account starts with four roles: Admin (full access), Employee, People manager, and Project manager. You can edit them, duplicate them, or add your own.

​

Permission scopes

For permissions with target selectors, the targets you pick under Edit and View define whose data the permission covers. Each permission only offers the targets that make sense for it. The targets separate what the person manages from their colleagues — and, for tasks, what they own from what they manage: For example, a team leader role could have People details set to Edit: Managed people and View: Managed people, Project colleagues — they can maintain their own team’s profiles and see, but not change, the profiles of project colleagues.

​

Timesheet, time off, and schedule permissions

These permissions control day-to-day time tracking data. Timesheet and planning settings governs who may change that panel, not what it contains. Which plannings a person may record time on is one of its settings — Record time on these plannings — and it applies per person rather than per role. See Which plannings a person can book.

​

Approval permissions

Only the people who design the sign-off process need Approval workflow. Approving and rejecting timesheets isn’t a separate permission — it follows the stages of the approval workflow itself, so whoever a stage resolves as an approver can act, and administrators can always step in.

​

Billing, cost, and budget permissions

Financial data is hidden from anyone whose role has these set to Not allowed — they don’t see billing or cost amounts anywhere in Beebole, including reports.

​

Expense permissions

​

People permissions

Be deliberate with User account edit access: whoever holds it can change other people’s roles. Who manages whom is a separate permission, Assign people managers, in the assignment permissions below.

​

Project and task permissions

​

Assignment permissions

Assignment permissions separate changing data from deciding who works on what. A role can be allowed to edit projects without being allowed to assign people to them — or the reverse. When a role lacks an assignment permission, the matching controls simply don’t appear for its holders.

​

Custom field permissions

​

Journal and report permissions

​

Account and visibility permissions

These permissions cover account configuration and the access-control settings themselves. Show or hide by default sets the account-wide defaults described in Assignments. The per-item Who has access? panels and the per-person Show or hide panels follow the assignment permissions above instead — a role needs the matching Assign … permission to change who has access to what.

​

Assigning a role to a person

​

Common setups

The built-in roles cover the situations most teams ask about. Which time entries a role sees follows the people and projects it can view: Timesheet entries and Reports switch the features on, and the targets on People details and Project details decide whose time, on which projects, shows up.

​

Project managers see every hour logged on their projects

Give project managers the built-in Project manager role, or a copy of it. It is scoped to their projects rather than to a team: Project details at View: Managed projects, Assigned projects, People details at View: Me, Managed project members, with Timesheet entries and Reports switched on. Whoever logs time on a project they manage — employee or freelancer — appears in their reports and in the Team pane of the timesheet, and time on other projects stays out of sight. Then make them manager of the projects, or of a whole project category at once, in the Manages panel of their profile — see Assignments.

​

Freelancers and contractors see only their own time

Give them the built-in Employee role, or a copy of it: People details at View: Me, Project details at View: Assigned projects, and Timesheet entries on. They see their own timesheet and the projects assigned to them, and nothing about colleagues. If they must not see billing or cost figures either, keep Billing rates and Costs at Not allowed — the default on Employee.

​

Both at once

The two setups combine without a third role: project managers hold Project manager, everyone else holds Employee. A freelancer sees only their own time, while the manager of the project they work on sees the freelancer’s hours next to the staff’s. A separate role is only needed when a group wants something different — a finance role with View: All on Billing rates and Costs, for example, built by duplicating Project manager.

​

Best practices

• Grant the least access that works. Start from Not allowed and add View before Edit, only for the targets each role really needs.
• Name roles after responsibilities. Names like Project Lead or Finance make it obvious who should hold them.
• Prefer few roles over many. Targets like Managed people and Managed projects adapt to each holder, so one Manager role can serve every manager.
• Review roles when your structure changes. Targets follow manager and tag relationships — check that permissions still reach the right people after a reorganization.

​

Related content

​

Frequently asked questions