Roles and Access

BareBones Ticketing has no single list of roles. Access comes from several separate sources, and each is checked on its own. This page is the owner of the department access-level table; other pages link here rather than repeating it.

The three department access levels

Department access is granted to a group and mapped to a department at one of three levels. The levels build on each other: Work includes View, and Admin includes Work.

Level	What you can do in that department	What it does not include
View	See the department's tickets, queues, and projects you are allowed to see.	Commenting, assigning, moving tickets to the next status, the extra Admin duties, or any configuration.
Work	Everything in View, plus everyday agent work: posting comments, moving tickets to the next status, and assigning them.	The extra Admin duties, or any configuration.
Admin	Everything in Work, plus the extra department duties: bulk owner, watcher, and participant changes; creating a project for the department; managing a department project through its life; and keeping project-manager assignments up to date.	`SystemAdmin`, configuration of any kind, other departments, or unrelated records.

You do not hold a level directly. You belong to groups; groups are mapped to departments at a level. If more than one active mapping reaches you for the same department, the highest level wins. The user, group, mapping, and department must all be active.

A level applies only to the department it was mapped for. Admin in one department gives you nothing in another.

That Admin row lists what the level adds by default, not every use of it. A workflow move can carry a minimum access level requirement, and a System Administrator can set that to Admin — so passing that one move needs Admin, even though moving tickets is otherwise Work. See Workflows and statuses.

The other sources of access

Source	What it gives	What it does not give
SystemAdmin grant	Full administration: tenant and department setup, users, groups, the company directory, single sign-on, department-access mappings, the service catalog, custom fields, tags, workflows, statuses, SLA policies, business calendars, mail, web access, certificates, storage, database, licensing, import, diagnostics, audit, and redaction.	Ordinary ticket Work, requester relationships, or approvals, where those are checked on their own.
Internal requester relationship	Sight of one ticket, when you are its requester, an active watcher, a copied person, or an active participant.	Agent work, internal comments, or any department access.
Explicit project manager assignment	Looking after the content of that one project.	Department access, ticket visibility, or authority over other projects.
Direct project role	Staffing on a project and sight of it.	Running the project, mapping administration, or ticket access.
Named ticket approver	Deciding one active approval.	Queue access, or the ability to make the transition itself.
External participant	Public comments and external-safe files on the specific tickets they were linked to.	Internal sign-in, the requester portal, the queue, search, projects, or administration.
Customer Portal requester	Time-limited access from a signed Customer Area handoff to the customer-visible Service Catalog, My Tickets, their own ticket and its follow-up, and Return to Customer Area.	Quick Ticket, global search, preferences, approvals, projects, agent work, administration, or an ordinary internal account.

Department Admin is not SystemAdmin. Configuration is SystemAdmin-only, and department Admin is deliberately turned away there.

Requesters, agents, and administrators

The manual uses these words for the common cases:

A requester is anyone submitting a request. Being a requester needs no department access. A requester sees the tickets they are named on.
An agent is a user with Work access to at least one department. There is no separate agent role to grant.
A department administrator is a user with Admin access to at least one department.
A System Administrator is a user holding an explicit SystemAdmin grant.
An external participant is an outside person invited into specific tickets. They sign in through an invitation, not as an internal user.
A Customer Portal requester arrives from the Customer Area through a signed single sign-on (SSO) handoff. The product creates or reuses an account tied to the identity provider, with a generated internal login and a generic display name. The customer never chooses or uses a BareBones Ticketing password. The access lasts at most eight hours and does not extend with use.

A licence does not grant access

Licensing and access are separate, and each is checked on its own. A valid licence lets the installation run and caps how many workers it may have. It gives no one access to any department, ticket, project, or administration screen. See Editions.

What you can see is not what you can do

The menus you see are built from your role and your department access. They help you find your way; they do not decide what you are allowed to do. When you actually try to do something, the product checks your access again — every time, wherever the request comes in, including a page you reach by typing its address directly — and refuses it if you are not allowed.

The reverse is also true: a button you cannot see is only the screen tidying itself. Its absence is not the real rule.

Two things only re-check; neither grants access. Step-up confirms that an administrator who already has access is still the person at the keyboard before a sensitive change — it cannot supply access no one had. The product-use check can block a change when the licence does not currently allow changes — it cannot grant access either.