Skip to main content
TimeTracker decides what you can do using two things: a role and the capabilities inside it. A role is a named bundle, like Project Manager. A capability is one named permission inside that bundle, like “approve time”. You get a role. The role gives you capabilities. Every button in the product checks a capability before it appears.

​
The seven roles

Every workspace starts with these seven. You can also build custom roles from the same capability list, and all but two of the seven can be edited or renamed to fit your team. For the exact capability-by-capability grid, see the roles and permissions matrix.

​
How the roles rank

Most of the roles form a clean ladder, where each one holds everything the role below it holds: Owner (66) → Admin (65) → Project Manager (43) → Member (16) → Contractor (12) → Client (0) The number is how many of the 66 capabilities that role carries. Finance sits off to the side, not on that ladder. It holds 14 capabilities, all of them also held by an Admin – but it is not a wider version of Member. A Member can create tasks, track time and build reports. Finance cannot do any of those. So Finance is a specialist role, not a senior one. If Daniel also needs to track his own hours, give him a custom role that adds time.track – do not assume Finance already includes it. Two other things worth knowing:
  • Owner and Admin differ by exactly one thing. An Admin can do everything an Owner can, except delete the workspace. That is irreversible, so it stays with the Owner alone.
  • Project Manager and Finance are siblings, not ranked. Priya (Project Manager) runs delivery. Daniel (Finance) runs the money. They overlap on invoices and expenses, and that is deliberate.
A Client holds an empty capability set. That is not an oversight – a portal contact is not a member of your team. They see only what is shared with their client company. See what clients can see.

​
Capabilities

A capability is a single named permission such as time.approve or invoice.manage. There are 66 of them, grouped by area: The capabilities reference lists all 66 with a plain description of each.

​
A capability is not a scope

This is the single most misunderstood part of the permission model, so it is worth slowing down.
  • A capability answers: may you do this at all?
  • A supervision scope answers: for whom?
Both have to pass. Example. Priya is a Project Manager, so she holds time.viewOthers. That does not mean she sees everybody’s hours. She sees the hours of the people in her scope. If Jonas is not in her scope, Priya has the permission but not the person. If someone says “I have permission but I still cannot see it”, the answer is almost always scope. See supervision scope.

​
Custom roles

If none of the seven fit, an Admin or Owner can build a custom role by picking capabilities from the same list. A workspace might create “Studio Lead” – a Member who can also approve time. You can also edit five of the seven built-in roles directly. Owner and Client are locked; Admin, Project Manager, Finance, Member and Contractor can be renamed and have their capabilities changed to fit how your business actually works. Two limits apply:
  • Owner-exclusive actions cannot be granted. Deleting the workspace stays with the Owner no matter what role you build. It is never offered as a checkbox.
  • A custom role can only combine existing capabilities. It cannot create a new kind of permission.
You need role.manage. See custom roles.

​
Per-person exceptions

Sometimes one person is the exception. Rather than building a whole role for them, you can adjust them individually. Per-person exceptions are subtractive only. They take something away. They can never grant a person something their role does not already include. If you need to grant, change the role or build a custom one. Today this is exposed as one switch: Clock in and out, on a person’s record. Example. Everyone on the team can clock in and out, but Ana is a contractor who bills by the deliverable and should not use the clock. Switch clock access off for Ana alone, and leave everyone else untouched. Location rules act as a second subtractive layer – they block an action based on where someone is, without changing their role. See per-person permissions.

​
How the checks stack up

When you open a page, four separate gates run. They fail in different ways, and telling them apart saves a lot of support time.
When someone reports a missing feature, ask which of the four it is before changing anything. The decision tree is on I cannot see a feature.

​
Who can change permissions

​
Common questions

A workspace has one Owner. If you need a second person with near-total control, make them an Admin – the only thing they cannot do is delete the workspace. To hand over the business, transfer ownership. See change someone’s role.
Not by default. Viewing other people’s time needs time.viewOthers, which Members do not hold. Give them a custom role if they need it.
Contractor is the narrower one. A Contractor tracks time and works tasks, but cannot see your client list and cannot build reports. Use it for freelancers who should not see your whole book of business. See manage contractors.
Yes. Seats count everyone with access, including portal contacts and people who have been invited but have not signed in yet. See seats.
Cost visibility is its own capability, rate.viewCost, separate from rate.viewBilling. Someone can see what you charge without seeing what you pay. Reports enforce the same split. See cost rates.

Permissions matrix

Every capability against every role.

Supervision scope

Which people and projects you can see.

Custom roles

Build a role that fits your team.

Apps and modules

Switching whole areas on and off.