Controlling Ticket Visibility From a Type Mapping

A user's role normally decides how many tickets they can see - their own, their site's, or the whole company's. A type mapping can override that, and can also restrict which boards and which ticket statuses they see at all.

These controls live in a section that is collapsed by default, which is why most partners never find them. They are also the one part of a type mapping that can make a user see less than their role allows, so it is worth understanding before you use them.

• Where the Controls Are
• Override Visible Tickets
• How Visibility Is Actually Decided
• Restricting by Status
• Restricting by Board
• When a Contact Matches More Than One Type
• Checking the Result on a User
• Removing an Override

Where the Controls Are

1. Go to Partner > Settings and select Type Mappings. It is listed under Configuration on the right of the Settings page, and once open it is a tab beside Setup.
2. Open a mapping, or select Add Mapping.
3. Expand Advanced Settings at the bottom of the panel.

Advanced Settings holds Override Visible Tickets for this User?, Ticket Status Overrides and Ticket Board Overrides. The Visible Tickets choice (Personal / Site / Company) only appears once you tick the override, so tick it before you look for it.

All three are disabled unless Sync with CloudRadial? is checked on the mapping. A mapping that doesn't sync doesn't grant anything, including ticket settings.

Override Visible Tickets

Tick Override Visible Tickets for this User? and a Visible Tickets choice appears with three options:

• Personal - the user sees only tickets they are the contact on.
• Site - the user sees tickets for their site.
• Company - the user sees all of the client's tickets.

Leave the checkbox unticked and the mapping says nothing about ticket visibility; the user's roles decide it as normal.

How Visibility Is Actually Decided

This is the part worth reading twice, because the behaviour is not what most people assume.

When the override is set, it replaces the role-based answer. It does not add to it.

So a user with a role that would give them Company visibility, matched to a type mapping whose override says Personal, sees only their own tickets. The override wins, in both directions. It is not "the most permissive of the two."

When the override is not set, the user gets the most permissive visibility of all their roles. A user with two roles, one Personal and one Company, sees the whole company.

Two consequences in practice:

• Using an override to widen access works, but so does giving the user a role that already has the visibility you want. The role is usually the better tool, because it travels with the person rather than with their PSA type.
• Using an override to narrow access is the case the override is really for - a type whose members should be restricted regardless of what role they hold. Just be aware that when you do this, changing the user's role will not fix their visibility. Removing the override from the mapping is not enough either, because users who have already synced keep it; see Removing an Override.

Restricting by Status

Ticket Status Overrides restricts users of this type to tickets in the statuses you list. Add each status as a tag.

Leave it blank and the mapping applies no status restriction - the user sees whatever statuses they would otherwise see. Blank means "no opinion," not "no statuses."

Statuses have to match the names in your PSA.

Restricting by Board

Ticket Board Overrides restricts users of this type to the boards you list, in the same way.

This applies on ConnectWise, Autotask, Kaseya BMS and HaloPSA. On Syncro it has no effect - Syncro has no board concept, and any value entered here is ignored.

One thing to watch: a user's own board list, which this mapping sets, takes precedence over a board list configured at the client level - the two lists are not combined. A type mapping that sets a board list replaces the client's restriction rather than narrowing it further.

If you leave it blank, none of that happens and the client's settings apply as normal.

When a Contact Matches More Than One Type

If a contact carries several types and more than one mapping matches, the ticket settings are merged before anything else happens:

• Visible Tickets takes the most permissive value among the mappings that tick the override and set one. One matched mapping saying Personal and another saying Company gives Company. A mapping with the override unticked contributes nothing here, even if a Visible Tickets value was left on it.
• If any matched mapping has the override checked, the override applies to the merged result.
• Status and board restrictions are combined into a single list. A user matching two mappings that restrict to different boards sees both sets of boards, not the boards common to both.

Only mappings with Sync with CloudRadial? checked take part in this. The merged result is then applied to the user, replacing what their roles would have given them.

The net effect is that a second type usually leaves visibility the same or wider, but not always:

• A second mapping that ticks the override with Personal replaces the role-based answer outright, so the user can end up seeing less than before.
• A second mapping that sets a board or status list adds a restriction where there was none, because a blank list means no restriction.

After adding a type to a contact, check the result on the user.

Checking the Result on a User

Type mappings are applied by the PSA sync, so nothing changes until the next sync runs.

To see what a user ended up with, open Partner > Clients > Users > [user] and go to the Ticket Settings tab. The same controls are there, showing the values that were applied. On this tab the status and board overrides sit inside their own collapsed Advanced Settings section.

You can edit them there for an individual user, but whether the edit survives depends on their type mapping:

• If no matched mapping sets any of the three, your edit stays.
• If a matched mapping sets any of them, the sync re-applies the merged values and your edit is replaced on the next run. That includes a control the mapping leaves blank: a board list you typed by hand is cleared if the mapping only sets the override.

So per-user exceptions are only maintainable for users whose type mapping leaves Advanced Settings alone. If you need an exception for someone whose mapping does set these, give them their own type in the PSA rather than editing the user.

Removing an Override

Unticking Override Visible Tickets for this User? on a mapping stops the mapping applying it from then on, but it does not clear the override on users who have already synced. They keep it until it is unticked on their Ticket Settings tab, or removed in bulk.

To clear it for everyone at once, go to Partner > Account > Labs, find the Users list and select Remove Ticket Visibility Overrides. This unticks the override for every user in the portal, and each user then sees the tickets their role assignments allow. Labs features are marked use-at-your-own-risk, and this one needs full permission on the Partner Account.

The next sync re-applies the override to any user whose type mapping still ticks it, so fix the mapping first.

Related

• Type Mapping: Mapping PSA Types to CloudRadial Roles - every control on a mapping, and how multiple types combine
• Where a User's Roles Came From - confirming which mapping applied to a user
• Understanding Security Roles - the ticket visibility each role carries

If you are still having trouble, we're here to help!

Submit a ticket here for assistance, and don't forget to check our status page to ensure there are no outages in your area.