HaloPSA

HaloPSA Guides

Documentation to assist with the setup and configuration of the HaloPSA platform

Guides > Configuring HaloPSA for a Co-Managed Support Setup

Configuring HaloPSA for a Co-Managed Support Setup

In this guide we will cover:

- Permissions

- Allocating Tickets to their Respective Teams

- Granting Access to Certain Actions

- A Summary of the Setup

- Agent-Level Client Restrictions Tab



Associated Admin Guides:

Associated Guides:

If you are looking to configure HaloPSA to suit a co-managed support model, then you should consider the following:

  1. Access levels/permissions for third party agents.
  2. Should the 3rd party require their own teams/area to work from?

Permissions

You will want to begin by creating a new role for the third party agents who will be servicing their customer(s). Head to Configuration > Teams & Agents > Roles and create a new Role.


Some notable points to observe include:


  • Departments & Teams - Within the configuration of your Roles, you will find a Departments & Teams tab. This tab allows you to specify the Teams that Agents with this Role will be a member of. When adding Teams here, you will see a series of options around the level of access to the team (Fig 1).

Fig 1. Options available when adding Team membership to Roles


If you are adding third party agents to your existing support team(s), you may well want to consider giving them limited access to tickets. 


You may also want to consider creating a new team entirely for this purpose, as this will maximise flexibility around what third party agents can see within their team, without granting them access to information they are not permitted to access.


  • It is important to ensure that these agents do not have access to areas of the system they should not see, so think about the permissions you grant them via the 'Permissions' tab within this role. They should not be an Administrator, nor have access to their preferences. There are two sections of the permissions which are of particular use for setting up a Co-Managed model: Ticket Groups & Client restrictions. Add to the 'Client Restrictions' list the clients for which this third party Service Provider supports - this ensures that your third party agents will only see information relating to their customers. Ticket Group restrictions will allow you to set exactly the groups that include ticket types of tickets that these agents need to see.

Note: Co-Managed Agents cannot search using filters or create new Lists and Filters.


Customer Group Overrides

  • Customer group overrides can be set in the permissions tab also (Fig 2). By selecting the customer they support in here, they will only be able to see other agents with the same customer set, thus preventing agents from seeing other agents in the system erroneously.

Fig 2. Customer Group Override


Allocating Tickets to their Respective Teams

Once you have created your new Teams & Role for your third party Agents, you will want to ensure two points have been checked:


  1. This new team is available in your existing ticket area(s)
  2. Tickets logged for respective customers are assigned to their correct support team(s)


For point 1, simply head to Configuration > Tickets > Areas and make sure that, if you are imposing team filters in your Ticket Areas, the new team are added to this list.


Point 2 can be addressed in multiple ways, but for this purpose we will make use of Ticket Rules. Head to Configuration > Tickets > Rules and create a new ticket rule with the following configuration:


UseNew Tickets
Stop matching other rules when matchedNo
CriteriaCustomer Includes{The customer(s) that your 3rd party agents support}
OutcomeTeam equals {newly created team}


Granting Access to Certain Actions

You may want to consider creating new actions available on your tickets which are only applicable to your third party support team (Like an escalation action, for example). This can be done via heading to Configuration > Tickets > Workflows, editing a step inside of a workflow and enabling 'Restrict access to this action' (Fig 3).

Fig 3. Restricting Access to actions from within a workflow


While this step is not crucial, it can be handy to know when thinking about how agent from different agents may be interacting with tickets.


Summary

To handle a Co-Managed support model in HaloPSA:


Create a new Team for these agents to be placed in. Ensure this team is available within your existing ticket area(s) via the filters tab in Config > Tickets > Areas.


Create a new Role to allocate to these agents. Via this Role, give them membership to the team created in step 1. Ensure their permissions are restricted (limited access to features) and that the client(s) they support have been added to the client restrictions table.


Create a ticket rule that assigns tickets logged from this client to your new team automatically.


There is a general setting in Configuration > Tickets > General Settings. Fig 4. Agents using Co-managed functionality cannot re-assign Tickets from non Co-managed Agents setting


When this setting is turned on, any Agents that are under the Co-Managed section, i.e. acting on behalf of a separate corporate entity, cannot alter the assigned Agent on Tickets that belong to regular Agents.


Agent-Level Client Restrictions Tab

The above configuration is one way to set up a Co-Managed model in HaloPSA. Another solution (one that may perhaps be more straightforward) is to head to the Co-Managed Agent in HaloPSA, and then to the Client Restrictions tab:


Fig 4. Client Restrictions Tab for Agent


This tab has two options:


  1. Co-Managed IT - This option is a single select, returning a list of Customers. When a Customer is selected in here, The Agent in question will only be able to see other Agents who have the same option selected in the Co-Managed IT dropdown.
  2. Allow Use of All Customers - When this is selected as 'No', a table will appear below. You can then add Customer records into this table & will be the only customer records that agent has access to (this also applies to other entities related to a Customer e.g Tickets, the search bar)

So with this setup, the agents that are i.e. working as 1st line support for the customer of the MSP, will only be able to see other agents that are in the Customer Group Override, and they will only see tickets, etc from the Customers in the table. In this below example, James only has access to Customer 1.


Fig 5. Customer Group Override on an Agent


Popular Guides