Team
LogPac Operations · 7 people · one agent
| Name | Role | Teams | Status | Last active |
|---|---|---|---|---|
| Connor Santana csantana@logpac.io | Owner | Leadership | active | 9/21/2026, 8:40:00 AM |
| Dana Whitfield dana@logpac-demo.com | Operations manager | Dispatch | active | 9/21/2026, 8:12:00 AM |
| Ana Reyes ana@logpac-demo.com | Coordinator | Dispatch | active | 9/21/2026, 7:55:00 AM |
| Bo Chen bo@logpac-demo.com | Coordinator | Reefer | active | 9/20/2026, 4:30:00 PM |
| Priya Raman priya@logpac-demo.com | Billing | Settlements | active | 9/21/2026, 6:20:00 AM |
| Marcus Hale marcus@logpac-demo.com | Administrator | IT | active | 9/19/2026, 11:05:00 AM |
| Jordan Blake jordan@logpac-demo.com | Viewer | — | invited | — |
| LogStat Agent operations@logpac-demo.com | AI agent | — | active | 9/21/2026, 8:44:00 AM |
Teams route work; roles grant permission. They are not the same thing, which is why a coordinator on the Reefer team and one on Dispatch hold identical permissions and see different queues.
What each role can do
Two columns are highlighted. Verifying a sender and enabling autonomy are the only acts in this system that widen what the agent may disclose without a person, so they sit with the operations manager rather than the administrator — both are judgement calls about a counterparty, which is an operations judgement and not an IT one. An administrator can hand themselves either by changing their own role, and that appears in the audit log. Silently holding them would not.
| Permission | Owner | Administrator | Operations | Coordinator | Billing | Viewer | AI |
|---|---|---|---|---|---|---|---|
| tenant:manage | ● | · | · | · | · | · | · |
| users:manage | ● | ● | · | · | · | · | · |
| integrations:manage | ● | ● | · | · | · | · | · |
| intents:manage | ● | ● | · | · | · | · | · |
| templates:manage | ● | ● | · | · | · | · | · |
| senders:verify | ● | · | ● | · | · | · | · |
| autonomy:manage | ● | · | ● | · | · | · | · |
| tasks:view | ● | ● | ● | ● | ● | ● | ● |
| tasks:view_all | ● | ● | ● | · | · | ● | · |
| tasks:assign | ● | ● | ● | · | · | · | · |
| tasks:resolve | ● | ● | ● | ● | ● | · | · |
| replies:send | ● | ● | ● | ● | ● | · | ● |
| documents:view | ● | ● | ● | ● | ● | ● | ● |
| documents:write_tms | ● | · | ● | · | ● | · | · |
| rates:view | ● | · | ● | · | ● | · | · |
| audit:view | ● | ● | ● | · | · | ● | · |
Owner
Everything, including billing and deleting the organization.
Administrator
Users, integrations, intents and templates. Cannot verify senders or enable autonomy — those are held separately on purpose.
Operations manager
Sees every task, assigns work, and is the role that verifies senders and opens autonomy for an intent.
Coordinator
Works the queue: reviews drafts, sends replies, resolves the tasks they own.
Billing
Documents, invoices and remittance, plus the rate visibility that requires. No task assignment.
Viewer
Read-only, including the audit trail. Sends nothing.
AI agent
The agent itself. Deliberately narrower than every human role: it cannot verify a sender, enable its own autonomy, or write to the TMS.
The agent appears in this list on purpose. It is a principal with its own permission set, strictly narrower than any human’s — it cannot verify a sender, enable its own autonomy, write to the TMS, or assign work. Modelling it as a role rather than as the absence of a user is what makes those limits checkable rather than incidental.
Inviting, editing and suspending need the user table applied. Roles are enforced today by can() and covered by the tenancy test suite; nothing on this page writes.