How permissions work
Last updated July 4, 2026
- Two layers: the interface hides what your role can't use, and row-level security on the server enforces it.
- Every read/write carries your personal login. The server decides what comes back, not the page.
- Hand-crafted API calls get the same answer as the UI. There is no way around your role.
The six team roles
One role per person, set in Admin Settings → Team. Flags (below) add powers on top.
Admin FULL ACCESS
Super User ALL TASKS
Internal Team SCOPED
External Team MASKED
Partner MASKED
CPA / Accountant BOOKS ONLY
Flags that modify a role
Adds Rates, the Budgets page, and estimate approval. Grantable to anyone, any role.
Full access + team management. Owners only.
Costing info only. Does not change visibility.
Private to their owner. Even admins and Ada can't read them.
Access matrix
| Area | Admin | Super User | PM flag | Internal | External / Partner | CPA |
|---|---|---|---|---|---|---|
| Tasks & boards | ✓ all | ✓ all | role's scope | assigned + member | assigned + member | ✕ |
| Internal-only tasks | ✓ | ✓ | role's scope | ✓ on their lists | ✕ never | ✕ |
| Time (Tick Tock) | ✓ all + import | own | own | own | own | ✕ |
| Budgets + forecast | ✓ | ✕ | ✓ | ✕ | ✕ | ✕ |
| Rates | ✓ | ✕ | ✓ | ✕ | ✕ | ✕ |
| Revenue & client invoices | ✓ | ✕ | ✕ | ✕ | ✕ | read |
| Vendor bills | ✓ | read | ✕ | ✕ | ✕ | read + PDFs |
| Expenses | ✓ all | ✓ all | own | own | own | read all |
| The Books | ✓ full | ✕ | ✕ | ✕ | ✕ | read + JEs |
| Admin Settings | ✓ | limited | ✕ | ✕ | ✕ | ✕ |
| Ada assistant | ✓ own scope | ✓ own scope | ✓ own scope | ✓ own scope | ✓ own scope | ✕ |
| Vault | ✓ team + personal | per sharing | per sharing | per sharing | per sharing | ✕ |
✓ full · partial (own data / read-only / per grant) · ✕ none. The PM column shows what the flag adds.
Client portal users
Separate system. Not team members. Granted per project.
They see
- Their projects only: tasks, tickets, Support plan, chat
- Status reports (once one has been sent)
- With the Approver grant: approve / request changes on ticket estimates
- With the Budget grant: dollars at their contract rates, burndown vs Target, forecast only if enabled per project
They never see
- Our internal rates or costs
- Internal-only tasks, other clients, the team app
Paused project = read-only for them (chat stays open). Their assistant is portal Ada, never the team one.
Ada and permissions
- Ada answers with your permissions. Same question, different role, different answer. By design.
- Never readable by anyone: the Vault, personal lists.
- Financial data has an extra gate in Ada's own code. Rates need admin or PM.
- CPA accounts are declined; the accountant reads The Books directly.
How time tracking works
Last updated July 4, 2026
- All time lives in Tick Tock as entries: start a timer, or log after the fact.
- An entry = person + Project List + the day it started, usually attached to a task.
- Entries feed budgets, support plans, status reports, profitability, and invoices.
Two tracking modes per Project List
| Internal (default) | External | |
|---|---|---|
| System of record | TaskFlow | The client's own time system |
| How hours get in | Timers + Log time | Timesheet import only |
| Task time UI | Shown | Hidden (no double entry) |
| Exceptions | n/a | Internal meetings (anyone) · admin corrections |
Set per list in Edit Project List → Time tracking.
Meeting time and budgets
Each list picks a Meeting policy: which meetings burn the hours budget.
Default. Internal + client meetings burn budget.
Client calls burn budget; internal syncs don't.
Meetings never burn budget.
- Applies to: Budgets, support plan capacity, status reports.
- Does not touch invoicing. Billing is a separate decision.
- Excluded time is always shown (footnote or card), never hidden.
Timesheet import
- Tick Tock → Import timesheet. Accepts image, PDF, or CSV exports from client time systems.
- Everyone can import their own timesheet. The target is locked to yourself.
- Admins can import for any member, or "Everyone in the file" (rows auto-route by name; unmatched rows are skipped and flagged).
- Duplicate files are caught (override: "Import again anyway").
- Locked days are skipped and flagged.
- CSVs use tracked time, not estimates. Deleted rows ignored.
When time gets locked
Admin closes a date range after review. No edits inside; imports skip those days.
Sending an invoice locks the entries it billed.
Reconciling a contractor bill locks their time + rates for that period.
- Admins can unlock with a reason (audited), fix, and re-lock.
- Principle: billed history matches what was billed. Corrections move hours within the same totals or land in the open period.
Support lists and the ticket flow
Last updated July 4, 2026
- Project lists = planned, phased work on a timeline.
- Support lists = a ticket funnel worked as a prioritized queue against a standing budget.
- On a support list, tasks are called tickets. Same object, different lifecycle.
The ticket lifecycle
- Tickets arrive from the portal or the team. They sit in the funnel strip, not on the board.
- The team enters an estimate in hours.
- The client's approver signs off (or requests changes).
- Approved tickets join the board. The team closes tickets, not the client.
Who approves estimates
Approve / request changes from the ticket's card in the portal.
Client said yes on a call or email? Admin/PM records method, date, note.
Both paths leave the same audit trail on the ticket.
Two dates, deliberately
| Date | Who sets it | What it means |
|---|---|---|
| Requested due date | Client, at submission | Their ask. Information, never a promise. |
| Target Delivery Date | Team, after estimating | The commitment the client sees. |
The support plan
Replaces the Gantt. Team: Project Plan page. Client: Support plan tab.
- Capacity cards: Budget · Used · Committed · Pipeline · Available (meeting-policy aware).
- Queue: tickets in delivery order; drag to reprioritize. No calendar.
- Budget line: red marker where the queue exhausts the budget. Client-visible per list, your choice.
- Est vs actual ledger: every finished ticket's estimate against logged hours. This is how estimating improves.
- Calls & meetings: shown separately per the list's meeting policy.
Internal-only tickets never appear on the plan and skip approval. Support budget dates are edited on Budgets.
What the client sees
- Their tickets + funnel stages, estimates awaiting approval, Target Delivery Dates
- Support plan tab: capacity, queue order, budget line if enabled
- With the Budget grant: dollars at their contract rates + burndown
- Never: internal-only tickets, our internal costs, internal notes
Project Lists, plans, and task types
Last updated July 4, 2026
- Work lives on Project Lists. Each belongs to a company and may carry a short code.
- List settings shape the flow: flow type, project plan, time-tracking mode, meeting policy, budget.
Two flow types
| Project | Support | |
|---|---|---|
| Shape | Planned + phased, timeline | Ticket funnel + queue |
| Plan view | Gantt (phases) | Support plan (capacity + queue) |
| Budget dates | Inherited from the plan's timeline | Edited directly on Budgets |
Three task types
Planned delivery. Moves through stages, joins a phase, carries Effort, can require approval.
One-off work. Plain To Do / In Progress / Done. No stages.
Repeats on a schedule you set. Regenerates itself.
Project stages
- That's the default catalog. Each list can rename, reorder, or trim it.
- Stage = where in the delivery pipeline. Board status = is anyone on it right now. Independent on purpose.
The project plan
- Phases on a timeline. Tasks join phases; the plan drives the budget window, status reports, and the client's plan view.
- Approval flow: lists that require approval block Done until the client approves. Portal or team-side, both audited.
- Internal-only tasks: invisible to clients and external roles, skip approval, hide Effort/Phase.
Paused projects
- Team side: project plan hidden.
- Portal: read-only for clients (no new requests, edits, approvals). Chat stays open.
- Unpausing restores everything.
What shadow billing is
Last updated July 8, 2026 · Admins only
- A person's time can bill as a different resource. The person who did the work is the shadow; the resource the client sees is the main resource.
- Hours, rates, and dollars all flow under the main resource. Clients and external viewers never learn the shadow exists.
- Set up in Admin Settings → Rates ("Bills as") per person, with per-task overrides on the task itself.
How an entry resolves
- First match wins. Most setups only use the Rates default.
- The resolved resource decides the rate and whose name appears on invoices, budgets, and reports.
Where it applies
Lines roll up under the main resource at the main resource's rate.
Burn and resource rows use the billed-as resource, on our side and the client's.
Status reports, support plans, and portal views all show the main resource.
Who sees what
| Viewer | Sees |
|---|---|
| Admin · Super User · Internal Team | Real people, plus a "bills as" badge where mapped |
| External Team · Partner | Main resource only. Assignees, mentions, comments, and chat are remapped |
| Client portal | Main resource only. The portal cannot even read a shadow's profile |
- Masking is enforced in the database, not just the interface. A hand-crafted request gets the same masked answer.
- Internal-only tasks are excluded from client views entirely, so no masking is needed there.
Rules to work by
- Never name a shadow in client-visible text: task titles, comments on client lists, status reports, chat.
- Check the "bills as" badge on Budgets before sending an invoice for a mapped list.
- Reconciled vendor bills still pay the real person. Shadow billing changes what the client sees, not what we pay.