Agent Visibility in Team Workspaces

Last updated July 29, 2026

Agent Visibility in Team Workspaces

When an agency has more than one person, each agent should see their own pipeline — not the whole agency's. Owners and admins still see everything so they can manage the team, but agents get a focused view of just their trips, tasks, leads, and commissions.

This article explains exactly what each role sees, how "unassigned" records behave, and where the rules are enforced.

Who sees what, at a glance

RoleTrips / Tasks / LeadsBookings, Invoices, PaymentsCommissionsTeam payouts
OwnerAll in workspaceAll in workspaceAll in workspaceAll
AdminAll in workspaceAll in workspaceAll in workspaceAll
AssistantAll in workspaceAll in workspaceAll in workspaceAll
AgentOnly trips assigned to them + unassignedOnly linked to their tripsOnly tied to their bookingsOnly their own
Solo owner (one-person workspace)Everything, alwaysEverythingEverythingN/A

"Unassigned" means the assigned_to field on a trip is empty. Unassigned trips stay visible to every agent so the team can pick them up — this is how lead triage and the shared inbox work.

The one thing owners and admins don't see: Watches

Price watches and flight watches run the other way. A watch is the advisor's own working note on their own booking, so it belongs to whoever created it and to nobody else — including the owner and admins of the workspace. There's no role that widens it, and no setting to turn it on.

RoleTheir own watchesOther members' watches
OwnerYesNever
AdminYesNever
AgentYesNever

That covers the watch itself, its price history, the alert emails and reminders (which have only ever gone to the advisor who owns the watch), and the savings total on the Watches page.

The deliberate exception is publication: an advisor who turns on Feature on website widget for a cruise watch is choosing to put that sailing on the agency's public sailings widget.

See Price Watches for the advisor-facing version of this.

Your forms and automations belong to you

Two more things follow the same "yours, not the agency's" rule as watches. Both changed on 29 July 2026 — if you used to see a colleague's automations or forms in your own list, this is why you don't anymore.

Forms

What you madeWho sees itWho can edit it
A form you builtYouYou
A form you cloned from the libraryYouYou
An agency form (made by an owner or admin)Everyone in the agencyOwner/admin, or anyone — unless it's locked

Cloning from the shared library gives you your own private copy. The library is where sharing comes from; your copy is yours. Before this change, a cloned form was published to the whole workspace, which in large host agencies meant hundreds of advisors found other people's forms in their list and sometimes deleted them as clutter.

Locking an agency form. An owner or admin can lock a shared form so only owners and admins can change it. Worth doing on any form that feeds a live integration — a Zapier webhook, a website embed, a Kajabi booking page — because deactivating that form silently breaks the integration.

Automations

VisibilityWho sees itWho can edit or delete it
Personal (the default)Only youOnly you, plus owners/admins
AgencyEveryone in the agencyOnly its author, plus owners/admins

Sharing an automation with the agency lets your colleagues use it. It does not hand over the pen — an agency-shared automation is still yours to change. This matters because automations send email to clients on your behalf.

Support tickets

A support ticket is visible to whoever raised it, whoever it's assigned to, and the agency's owners and admins. Colleagues can't read each other's tickets — they often describe a specific client's situation.

What this affects

Role-based scoping applies everywhere the data is agent-specific:

  • Dashboard — active trip count, upcoming tasks, recent payments, revenue widgets
  • Trips list and calendar
  • Tasks and the task panel on trip detail
  • Clients (via the trips they're on)
  • Leads — agents see leads assigned to them or unassigned
  • Proposals, itineraries, invoices, payments
  • Inbox — email threads assigned to the agent plus unlinked inbound emails so triage still works
  • Commissions — only tied to bookings on the agent's trips
  • Agent payout batches — an agent sees only their own pay cycles

Reports and the agency-wide analytics page remain owner/admin only.

What agents do not see

An agent in a team workspace does not see:

  • Other agents' trips, tasks, leads, clients, bookings, proposals, invoices, or payments
  • Workspace-wide totals that include other agents' activity
  • Other agents' commission entries or payouts
  • Other agents' email threads (unless assigned to them or unlinked)
  • Other agents' forms, or the forms they've cloned from the library
  • Other agents' automations, unless shared with the agency
  • Other agents' support tickets

Public share links (proposal URLs, published itinerary tokens, client portal links) work independently of role — anyone with the link can view them as intended.

Unassigned records

Records with no assigned_to stay visible to every agent. That covers:

  • A trip created from an imported lead before anyone's claimed it
  • An inbound email that hasn't been linked to a trip yet
  • Tasks created on an unassigned trip

This matches how the inbox triage page and the leads queue already work. Once an agent claims a trip (sets assigned_to), it disappears from other agents' views.

How it works under the hood

Agent visibility is enforced at two layers:

  1. Application layer — the dashboard pre-filters widgets to the current agent's trip IDs, so queries stay small and fast.
  2. Database layer (RLS) — Postgres row-level-security policies on every agent-scoped table block anything the app layer misses. Even a future server-action bug that forgets to filter by assigned_to cannot leak another agent's data.

The DB-layer enforcement was added in migration 256_role_aware_agent_rls.sql. Tables covered:

trips, tasks, leads, email_threads, bookings, payments, invoices, proposals_v2, itineraries, promotion_applications, inbound_emails, commission_entries, commission_submissions, agent_payout_batches.

Migration 865_lock_peripheral_tables_to_owner.sql extended the same treatment to three tables that had been left workspace-wide: journeys (read, update and delete), support_tickets (read), and commission_submission_audit_log (read, which now simply follows whatever submission it belongs to).

Reassigning a trip

When an owner or admin reassigns a trip from one agent to another, every agent-scoped record linked to that trip (bookings, tasks, invoices, payments, commissions) follows automatically — there's no separate reassignment step per record.

The previous agent loses visibility into the trip the moment the new assigned_to is saved. The new agent sees it on their next page load.

For owners who also take trips

Owners who want to work their own pipeline can set assigned_to = themselves on their trips. Their role still gives them full-workspace visibility, so the assigned_to field acts as a personal filter for the owner's dashboard without hiding anything from them.

Questions this answers

"Why is my dashboard showing numbers different from my colleague's?" You're each seeing your own pipeline. That's by design.

"I can see an unassigned trip — should I?" Yes. Unassigned trips are shared so the team can claim them. Once you claim it (or someone else does), it becomes scoped to that agent.

"I was made an admin — do I see more now?" Yes. Admins see the full workspace. If you're an admin and a widget still looks scoped, log out and back in so your session picks up the new role.

"Can an agent accidentally edit another agent's trip?" No. Visibility prevents reading, and write permissions are governed separately — an agent cannot edit a trip they can't see.

Write access is being tightened table by table rather than all at once. Automations and forms were done on 29 July 2026; a few peripheral tables (AI usage records, custom domains, tag assignments) are still workspace-wide and are a planned follow-up. None of them hold client or financial data.

"My colleague's automations disappeared from my list — is something broken?" No. As of 29 July 2026 automations are personal unless their author sets them to Agency. Ask the author to share it, or ask an owner/admin — they can still see everything.

"I shared an automation with the agency. Can my colleagues change it?" No. Sharing makes it usable by the team, not editable by them. Only you and the agency's owners/admins can change it.