Guest Client role: a native client field — filterable and groupable like Assignee — with automatic scoped access
Sergio Sapuppo
Many teams — agencies, system integrators, consultancies — work on behalf of external clients. Today, there is no native concept of "client" in ClickUp. Giving a client visibility into their own tasks requires manually creating dedicated lists or spaces, configuring permissions per project, and maintaining that setup over time. Grouping or filtering work by client across the workspace is simply not possible natively.
The proposal
Introduce a new user type alongside the existing Guest: the Guest Client. The workflow would be simple:
- Invite an external user by company email and define them as Guest Client
- Associate that Guest Client to any task using a native field — similar to Assignee — selectable, filterable, and groupable across all views and dashboards
- When the Guest Client logs in, they automatically see only the tasks where they are associated — no manual filtering, no dedicated spaces, no permission configuration required
Why this matters
This is not a CRM request. It is a minimal extension of what already exists — the Guest user type — with a semantic distinction and a native field behavior. The infrastructure is already there; what is missing is a role that maps to a real-world actor (the external client) and that ClickUp can use as a first-class axis for filtering, grouping, and access scoping.
Without this, teams working for multiple clients are forced into workarounds: dropdown fields with hard 500-option limits, duplicated list structures, or manual permission management that breaks at scale. None of these solutions allow answering the simple question: "Show me everything we are doing for Client X."
Expected outcome
A Guest Client user type that: (1) can be assigned to tasks as a native field, filterable and groupable exactly like Assignee across views, dashboards, and reports; and (2) whose login experience is automatically scoped to their relevant work — turning ClickUp into a native client collaboration layer without adding complexity for the internal team.
Log In
Gabriele Vitale
Strongly supporting this. As a system integrator managing ERP implementations for multiple SMB clients simultaneously, this is one of the most tangible gaps we hit on a daily basis.
Right now our workaround is a combination of dropdown custom fields (which hit the 500-option ceiling faster than you'd expect), duplicated list structures per client, and permission configurations that someone has to babysit every time scope changes. It works until it doesn't, and it breaks exactly when you're most busy.
What makes this proposal compelling is precisely what the OP highlights: this isn't a CRM feature request. It's a semantic extension of an already-existing concept. The Guest user type exists. The assignee field behavior exists. The filtering and grouping infrastructure exists. The ask is to connect them around a real-world actor (the external client) that already shapes how service teams organize their work.
The "show me everything we're doing for Client X" query should be trivial. It isn't today. That's the gap.
A native Guest Client type that behaves as a first-class field axis filterable, groupable, dashboard-ready, and self-scoping on login would meaningfully change how agencies and integrators use ClickUp for client-facing delivery. No added complexity for the internal team. Just structure that reflects reality.
This gets a +1 from me without hesitation.