Table of Contents
Service Groups Explained: Controlling What Contacts See
A service group is a named list of service types. You assign it to decide which service types a contact sees in the portal. This article explains how it works and why we designed it this way. It also explains why the older filter did not work out.
For the exact settings and steps, see our existing article on the override system [link].
The short version
- A service group is a list of service types.
- You assign it at the global, company or contact level.
- A more specific level overrides the broader one.
- Most teams only need the global level.
- What you assign is what the contact sees. There are no surprises.
How it works
You create a service group, add service types to it, and assign it.
Level | Purpose | How often you need it |
Global | The default for everyone | Almost always. Often this is all you need. |
Company | An exception for one company | Occasionally |
Contact | An exception for one person | Rarely. Worth it only for high-value contacts, such as a VIP. |
The most specific assignment wins. A company-level group overrides the global group for that company. A contact-level group overrides both the global and the company group for that contact.
This is the same override behaviour you may already know from other settings.
Why we designed it this way
Most teams only need one global group
Our design assumes that, in most cases, one global service group is enough. The company level is for exceptions. The contact level is rare.
You don't need to micromanage a dedicated list for every person. If some service types are only for managers, you can include them in the group under a category called "Manager only". Contacts who shouldn't use it will ignore it, and the company's managers will use it.
You might say the strict list prevents misuse. Consider what happens next. The manager goes on holiday and appoints someone else. Or a manager delegates one task to a person who is not a manager. Will you adjust the list each time? Every one of those changes is a running cost. A small, shared list with a clear category costs less to run than a precise list that is always out of date.
What you see is what you get
With a service group, you can look at the group assigned to a contact and know what they see. There is no hidden calculation. This is the main benefit: visibility.
Why override and not addition
We chose override over addition for two reasons.
- It controls the size of a group. If assignments were added together, a contact's list would grow with every level, and it would be hard to know how many service types they would see. A short list is better for contacts. See Why a Small Service Catalogue Works Better.
- Addition can't remove anything. Adding service types is the common case. But sometimes a company or a contact should not see certain service types. Addition cannot do that. Override covers both adding and removing, because the more specific group simply lists exactly what that company or contact should see.
A replacement for the older filter had to cover every case, including removal. Override does.
What about the older filter?
Before service groups, each service type had a filter. It is now obsolete and not recommended, but the history explains why service groups exist.
How the filter worked
For each service type, you chose whether it was open to everyone or closed by default. Then you added exceptions at the company level, and further exceptions at the contact level.
For example:
- Open to all, except companies A and B, and contacts C and D.
- For company A, except contact E.
Advantages
- Easy to start. You work on one service type at a time, so it is quick to learn.
- Flexible. It can describe many different rules.
Disadvantages
- Hard to master. The rules are set on each service type. To know what one person sees, you have to check every service type and combine their rules. That is very hard to picture.
- Hard to predict. Exceptions on exceptions make the result unclear.
- Complex to run. The queries behind it are complicated.
- It has limits. Each filter can hold only a limited number of companies and contacts.
The design did not match how people used it
The filter was designed for exceptions. We expected people to list only a few exclusions, and exceptions to the exceptions to be even rarer.
In practice, many people used it as an allow list. They closed the service type to everyone and then added companies and contacts one by one. Some added over a thousand contacts to a single service type. This is the opposite of the design goal, and it hit the limits quickly.
Service groups remove that problem. You decide the list for a company or a contact once, in one place.
Practical advice
- Start with one global group. See Quick Setup.
- Add a company group only for a real exception.
- Use a contact group only for high-value contacts. Don't create one for each person.
- Use categories such as "Manager only" instead of separate lists.
- Keep each group short. See Build a Small, High-Value Service Catalogue.
Contact groups are different
Contact groups let a team share tickets. You can also assign a service group to a contact group, but this was added later and is not the purpose of contact groups. See Contact Groups: Shared Tickets for Teams.
