How permissions work
Last updated July 4, 2026
You sign in→
UI shows your role's pages→
Database checks every request
- 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.
Rule of thumb: an empty page or missing section is almost never a bug. It's your permission set.
The six team roles
One role per person, set in Admin Settings → Team. Flags (below) add powers on top.
Admin FULL ACCESS
Everything: tasks, money, Books, settings
Team management + timesheet tools
Other people's personal lists
Super User ALL TASKS
Every task and project
All expenses; vendor bills (read)
Rates, Revenue, The Books, invoices
Most Admin Settings tabs
Internal Team SCOPED
Assigned tasks + lists they're on
Internal-only tasks (on their lists)
Own time + own expenses
Anyone else's data; money pages
External Team MASKED
Assigned tasks + lists they're on
Internal-only tasks, ever
Rates, budgets, money pages
Partner MASKED
Same scope as External Team
Budget visibility via the PM flag (per person)
Our internal rates or costs, ever
CPA / Accountant BOOKS ONLY
The Books, read-only + financial reports
Invoices, vendor bill PDFs, expense receipts
Writes: adjusting journal entries + flag notes
Tasks, time, budgets, rates, payroll, Ada
Flags that modify a role
badge PM flag
Adds Rates, the Budgets page, and work approval on the client's behalf. Grantable to anyone, any role.
shield_person Admin flag
Full access + team management. Owners only.
engineering Contractor flag
Costing info only. Does not change visibility.
lock Personal lists
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 delivered work
- 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.
Rule of thumb: if it took your time, it's either a task or a meeting. No third bucket.
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.
All meetings
Default. Internal + client meetings burn budget.
Client meetings only
Client calls burn budget; internal syncs don't.
No meetings
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
Upload file→
AI parses rows→
Map projects→
Review + create entries
- 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
event_lock Period lock
Admin closes a date range after review. No edits inside; imports skip those days.
receipt_long Client invoice
Sending an invoice locks the entries it billed.
handshake Vendor bill
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 September 17, 2026
- Project lists = planned, phased work on a timeline.
- Support lists = a ticket queue worked in priority order against a standing budget.
- On a support list, tasks are called tickets. Same object, different lifecycle.
The ticket lifecycle
New→
Board: To Do → In Progress → Pending Approval → Done 🎉
- Tickets arrive from the portal or the team. They sit in the New lane above the board until accepted.
- Accept a ticket and it lands in To Do. No estimate, no client sign-off.
- The team closes tickets, not the client.
Changed September 2026: the Estimating and Client approval stages were retired. Hours are tracked as they are logged, not promised up front.
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, when accepting or later | The commitment the client sees. |
The support plan
Replaces the Gantt. Team: Project Plan page. Client: Support plan tab.
- Capacity cards: Budget · Used · Available (meeting-policy aware).
- Queue: tickets in delivery order with hours logged; drag to reprioritize. No calendar.
- Ledger: every finished ticket with the hours it took.
- Calls & meetings: shown separately per the list's meeting policy.
Internal-only tickets never appear on the plan. Support budget dates are edited on Budgets.
What the client sees
- Their tickets, whether each is still New or on the board, Target Delivery Dates
- Support plan tab: capacity, queue order, hours logged
- 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
Project STAGED
Planned delivery. Moves through stages, joins a phase, carries Effort, can require approval.
Side Quest QUICK
One-off work. Plain To Do / In Progress / Done. No stages.
Usual RECURRING
Repeats on a schedule you set. Regenerates itself.
Project stages
Backlog→
Ready to Build→
Configuring→
QA→
UAT→
Pending Approval→
Approved→
Live
- 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.
Keep this page to yourself. This topic and the Permission sets topic are only visible to admins.
How an entry resolves
Time entry override?→
Task-level map?→
Rates "Bills as" default?→
Bills as themselves
- 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
receipt_long Invoices
Lines roll up under the main resource at the main resource's rate.
donut_small Budgets
Burn and resource rows use the billed-as resource, on our side and the client's.
monitoring Reports & plans
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.