Outcome. A rep only sees the tickets that belong to their own team's queue in their default views, with the actual visibility restriction enforced by permissions, not by a workflow.
Workflow map
Enrollment, branches and actions at a glance
tickets-sla-050
flowchart TD
A[Ticket owner becomes known] --> B{Ticket Team matches owner's default Team?}
B -->|yes| C[Set team_assignment_flag = false]
B -->|no, mismatch or blank| D[Set team_assignment_flag = true, notify support ops]
When to use it, when not to
- UseUse it once Teams and permission sets are already configured (Enterprise), and you want each queue's reps to only see their own team's tickets by default, reducing noise and preventing a rep from accidentally working a ticket outside their scope.
- UseUse it as the honest version of this idea: the actual restriction is a permission configuration, not a workflow. In Settings > Users & Teams > Permission Sets (or the classic Teams object-access setting), set ticket record access to "Team only" or the equivalent restricted scope for the relevant permission set(s) (check in your portal: exact setting name and location, Enterprise permission models have changed over time). What follows is the one piece a workflow can genuinely help with: making sure a ticket's Team is set correctly, since permission-based visibility depends on that association being accurate.
- SkipDo not use it expecting a workflow to restrict who can see a record; HubSpot's object-level and record-level permission scoping is a user/Team/permission-set configuration, not a workflow action, no workflow can substitute for that setting existing and being correctly assigned to each user [VERIFY].
- SkipDo not use it if all reps already need to see all tickets regardless of queue, for example a small team where cross-coverage is normal; permission restriction in that case works against how the team actually operates.
The preview ends here. Six sections are in the library.
counted, not blurred
PrerequisitesEvery property with its label, internal name, type and options, plus the assets the workflow needs before you start.4 items
EnrollmentThe trigger, the criteria exactly as they are ticked in the UI, the re-enrollment rule and the suppression list.4 parts
StepsEach action in order with its parameters, its branches and its delays, written as you tick them.4 numbered actions
Known pitfallsTraps seen in production, each with what breaks and what to do instead.4 pitfalls
Test plan, variants and build specHow to prove it works in a test portal, where to look when it does not, the variants for other objects or tiers, and the YAML build spec.3 variants, 3 sections
FilesThe properties JSON creates the fields in one API call, the workflow JSON documents the build.PDF, Markdown, JSON
Install1 click. The installer creates the properties this spec declares and the workflow itself, switched off, then opens a task for the prerequisites that are assets rather than properties, such as a team, a static list or a marketing email. What it created is listed on the install page.1 click, switched off
Unlock the full library,
149 EUR
or the tickets and sla pack, 39 EUR
One-time, excl. VAT. 30-day refund, no questions asked. Founding prices until 31 October, then 199 and 59 EUR. Includes every spec added later, up to the full 500, and the one-click installer on the full library. Building on client portals? The agency licence at 449 EUR covers unlimited client portals.
