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, My team, or My 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. Some permissions — mostly account-wide definitions like Define time off or Tags — 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 three roles: Admin (full access), Manager, and Employee. 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. For example, a team leader role could have Timesheet entries set to Edit: My team and View: My team, Project colleagues — they can correct their own team’s timesheets and see, but not change, entries from project colleagues.

​

Timesheet, time off, and schedule permissions

These permissions control day-to-day time tracking data.

​

Approval permissions

A manager who approves timesheets needs Approval events edit access for their team; only admins who design the flow need Approval workflow.

​

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.

​

Project, task, and tag permissions

​

Custom field permissions

​

Journal and report permissions

​

Account and visibility permissions

These permissions cover account configuration and the access-control settings themselves. The last four are the controls described in Assignments — a role needs them to manage who has access to what.

​

Assigning a role to a person

​

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 My team and My 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