SupportCandy Agentgroups - WordPress Plugin

How to Configure SupportCandy Agentgroups for Team-Based Ticket Handling

SupportCandy Agentgroups is not just for neatly grouping staff members in a list. Its real purpose is to make ticket distribution across support teams more manageable. In this guide, we will walk through how to prepare your site, create agent groups, understand the difference between members and supervisors, connect groups to ticket assignment and email notifications, and then verify that the queue actually works the way you intended.

This guide is designed for cases where the core SupportCandy plugin is already being used as a WordPress ticketing system, and the team has grown into multiple areas such as sales, technical support, billing, partner support, WooCommerce order support, or an internal IT help desk. If ticket volume is low and one person handles everything, Agentgroups may be an unnecessary extra layer. But if it matters that a ticket first goes to a team and only then to a specific specialist, this add-on is built for exactly that workflow.

You will not find instructions here on purchasing, payment, or bypassing licensing. This guide focuses on practical use of a product you already have: preparation, installation, group setup, a real usage scenario, result verification, common mistakes, limitations, and comparable solutions.

What Problem Agent Grouping Solves in SupportCandy

In a typical small support setup, a ticket is often assigned directly to one staff member. That works well as long as all agents are generalists and ticket volume stays low. Once you have departments, support tiers, and different areas of responsibility, assigning tickets directly to individuals starts to create problems: the staff member may be unavailable, the category may be chosen incorrectly, and the team lead loses visibility into the shared queue.

Agentgroups adds an intermediate layer between the ticket and the individual agent. You can think of a group as a team: it contains members, and one or more of those members are designated as supervisors. The official documentation describes an agentgroup as a group of agents organized by category, department, or another separation criterion. That distinction matters: a group does not replace agent roles and is not a separate WordPress role. It helps route tickets inside SupportCandy.

In practice, the logic works like this: a ticket is assigned to a group, the supervisor sees it, and then assigns it to one of the members. If the integration with assignment rules is enabled, the ticket can go not only to the group but directly to one of its members based on availability or workload logic. For a support manager, this creates a controlled queue. For the agents doing the work, it means a cleaner task list without unrelated tickets.

When It Makes More Sense to Assign Tickets to a Group Instead of a Specific Agent

Group-based assignment is useful when initial routing matters more than instantly choosing the final assignee. For example, all payment-related questions should first go to the billing team, but the exact specialist inside that team is chosen by a senior staff member. Or all technical requests first go to first-line support, while complex cases are later escalated to second-line support. In those scenarios, Agentgroups helps keep the process orderly: the ticket does not get lost, but it also does not land with a random agent who lacks the right context.

There is an opposite case as well. If you already have precise automatic assignment set up for specific staff members based on categories, schedules, and workload, adding another group layer may make the process less transparent. In that case, use Agentgroups only where you need shared team oversight, not across every category by default.

How Groups Differ from Agent Roles

Agent roles in SupportCandy control permissions: what an agent can view, edit, and do inside the system. The documentation lists permissions for viewing tickets, replying, adding private notes, assigning agents, changing status, editing fields, viewing logs, and other actions. Agentgroups, by contrast, controls team membership and ticket routing. These two concepts work together, but they solve different problems.

The right model is this: first decide what permissions people need in their role, then group specific agents based on workflow. For example, the "Agent" role may allow a person to reply only to tickets assigned to them, while the "Billing" group determines which tickets enter the billing queue. If you mix up these concepts, it becomes easy to create a bad setup: someone belongs to the group, but their role does not allow the action they need to perform on the ticket.

Who This Add-On Is For, and When It Is Unnecessary

SupportCandy Agentgroups is especially useful for sites where support is already split into clear areas. That can include an online store, a WordPress-based SaaS product, an education platform, an agency with a client portal, a service company, or an internal IT team. In all of those cases, tickets are rarely all the same: some require technical expertise, others involve billing, and others relate to access, accounts, refunds, or service configuration.

The main selection criterion is not site size but routing complexity. If you often catch yourself asking, "Who should this go to?", groups will almost certainly help. If all agents see all tickets and calmly work through them in order, the add-on may just add an unnecessary management layer.

For an agency or online store, a typical starting structure might look like this: "Support", "Billing", "Technical", "VIP Clients". But do not copy someone else's model blindly. First look at your real ticket categories and at who actually decides where a ticket goes. A group should represent a working queue, not an org chart created just to keep the admin panel tidy.

What to Check Before Installation and Initial Activation

Agentgroups is an extension for SupportCandy, so the first thing to check is the core ticketing system. The main SupportCandy plugin must be installed and active, your support pages must exist, agents must already be added, and agent roles must reflect real responsibilities. If the base queue is not working yet, grouping agents will only hide the original problem.

Basic WordPress Dependencies

The official Agentgroups page lists the minimum WordPress and PHP requirements, as well as the current add-on version. Do not treat those numbers as part of an "install it and forget it" strategy. Compatibility should be rechecked before updates, especially if the site uses an older theme, custom user roles, admin-side caching, or several paid SupportCandy extensions.

Before installation, confirm the following:

• The core SupportCandy plugin is installed, active, and opens correctly in the WordPress admin panel.
• A support page with the [supportcandy] shortcode, or separate pages with [wpsc_create_ticket] and [wpsc_open_ticket], are already configured.
• The users who will act as agents already exist in WordPress.
• Agents have been added to SupportCandy through Support - Support Agents - Agents.
• Agent roles allow the required actions: viewing, replying, assigning, changing status, and adding private notes.
• Email notifications are enabled only after SMTP has been configured, because the documentation explicitly states that an active SMTP plugin is required for actual email delivery.

A Safety Check Before Changing Routing Logic

If the site is already handling real customer requests, do not change the assignment model in the middle of the workday without preparation. Create a test category, test agents, or at least agree on a short testing window. Groups affect ticket visibility for supervisors and members, so a mistake in group composition can look like "the tickets disappeared" when in reality they were simply assigned to the wrong place.

Safe rollout logic: first create one test group, assign one test ticket to it, verify visibility for the supervisor and a member, and only then connect automatic assignment rules.

Installing the Extension and Running the First Admin-Side Check

Technically, installing a premium add-on in SupportCandy is similar to installing a regular WordPress plugin by uploading a ZIP archive. This guide does not cover purchasing or entering a license key, but the order matters: the core plugin should be installed from the WordPress repository first, and the extension is then added on top of it as a separate add-on.

After activation, a section related to Agentgroups should appear in the admin panel. The documentation points to the path Support - Support Agents - Agentgroups. If that menu item is missing, do not start building assignment rules yet. First make sure the extension is active, the main SupportCandy plugin has been updated to a compatible version, and the current administrator has access to SupportCandy settings.

First Steps After Activation

1. Open Support in the admin panel and confirm that the main SupportCandy screen loads without errors.
2. Go to Support Agents and review the agent list.
3. Open Agentgroups and confirm that you can create a new group.
4. Check the roles of your future supervisors: they need permission to view and assign tickets within your workflow.
5. Create a test group with a neutral name, such as Test Support, so you can verify the mechanics without risking production queues.

At this stage, do not rush to move all live tickets into the new groups. The first priority is understanding how visibility works for different users. The Agentgroups documentation makes an important clarification: group members do not see tickets assigned to another member, and they also do not see group-assigned tickets until a supervisor distributes them. That is not a bug. It is part of the access model.

How to Create Groups: Name, Members, and Supervisors

Creating a group starts not with the interface but with a decision about the boundary of responsibility. The documentation says that a group name is usually chosen based on specialization, category, skill, or department. That may sound simple, but it shapes the quality of the entire setup. A group that is too broad, like "Support", changes very little. Groups that are too granular, such as "Billing Refunds EU Small Accounts", quickly turn routing into a manual puzzle.

The Group Name as a Working Filter

A good name answers one question: "Which tickets should land here first?" For a small project, three or four teams are usually enough. For a larger portal, it makes more sense to start with the areas where routing mistakes are most expensive: billing, access issues, technical incidents, VIP customers, and integrations.

Examples of practical group names:

• Billing - payment issues, invoices, refunds, and subscriptions.
• Technical Support - technical errors, configuration, conflicts, and troubleshooting.
• WooCommerce Orders - requests about orders, shipping, and products if SupportCandy is used alongside a store.
• Partner Support - tickets from partners, contractors, or internal clients.

Do not use names that make sense only to one administrator. A month later, someone else may be assigning tickets, and the group should still be obvious without a separate cheat sheet.

Group Members

The Agents field defines who belongs to the team. The documentation highlights an important detail: supervisors must also be included in the group's member list. If you add someone only as a supervisor but not as a member, you can end up with visibility and assignment behavior that feels unpredictable to users.

When building the member list, check three things. First, each person must already be a SupportCandy agent, not just a regular WordPress user. Second, their role must allow the actions they need to perform. Third, do not add people to the group "just in case" if they should not see or receive those tickets.

Group Supervisors

A supervisor is a member with extra authority within the group's queue. The documentation explains that when a ticket is assigned to an agentgroup, supervisors can see it and assign it to members. If every member is supposed to manage the shared queue themselves, you can make all members supervisors, but that should be a deliberate decision. That setup may work for a small team, but in a larger department it can bring back the same chaos you were trying to solve: everyone sees everything, but no one owns the first routing step.

Access Logic: What the Group, Supervisor, and Member Can See

The most common confusion around Agentgroups is not group creation but visibility expectations. A user creates a ticket, the administrator assigns it to a team, and a regular group member says the ticket is missing. In Agentgroups, that is normal if the ticket is assigned only to the group and has not yet been passed to a specific member.

The official explanation is straightforward: when a ticket is assigned to an agentgroup, supervisors can see it and assign it to one of the members. Tickets assigned to the group are not visible to members until they are assigned to one of them. Members also do not see tickets assigned to other members. This model protects the queue from unnecessary noise and helps the senior staff member control distribution.

Why the Supervisor Should Not Remove the Group Too Early

The product page includes an important warning: if a supervisor needs to assign a ticket to someone else, they should leave the ticket assigned to the group, otherwise they may lose access to it. In practical terms, that means the following: when a ticket first enters the team queue, you should not immediately replace the group with an individual agent if team oversight is still needed. A "group plus member" model is usually better when your chosen assignment method supports it.

If the supervisor hands off the ticket to a member and removes the group itself, the ticket can disappear from the team-level view. That is not always a mistake, but it should be part of your intentional process. For tickets that require senior oversight until closure, keep the group assignment in place.

How to Explain This to the Support Team

Before enabling Agentgroups, it is worth giving the team a short internal explanation. For example:

• Tickets in the "assigned to group" state are visible to the supervisor, who distributes them further.
• A regular agent sees the tickets assigned specifically to them.
• If a ticket requires team oversight, the group stays in the assignment even after the assignee is chosen.
• If a ticket has been fully handed over to one assignee and no longer requires team-level review, the group can be removed according to your internal process.

A simple note like this reduces false "the ticket disappeared" complaints and helps the team quickly distinguish an access problem from normal queue behavior.

Connecting Agentgroups to Assignment Rules and Team Workload

Agentgroups becomes especially useful when paired with the Assign Agent Rules extension. The assignment rules documentation explains that conditions can be built around custom fields and ticket properties such as status, category, subject, customer, and other fields. If Agentgroups is active, a rule can assign a ticket to an agentgroup or to one of its members.

The important thing here is not to mix up two levels of automation. The rule conditions decide which tickets match a route. The assignment option decides whether the ticket goes only to the group or directly to a member within that group. For a more complex support operation, it is usually best to start with the simpler approach: assign the ticket to the group first, let the supervisor work the queue manually for a while, and only then automate distribution within the group.

Three Assignment Modes for Agentgroups

The Assign Rules documentation describes three options that appear when Agentgroups is active:

• Assign group only - the ticket is assigned to the group, and the supervisor manually chooses the assignee.
• Assign group and one of its members including supervisors - the ticket is assigned to the group and one member, and supervisors are also eligible to be selected.
• Assign group and one of its members excluding supervisors - the ticket is assigned to the group and one member, but supervisors are excluded from assignee selection.

For most teams, the safest place to start is the first mode. It is slower, but much easier to control. The second mode works well if supervisors also reply to tickets regularly and should share the workload. The third mode is useful when the supervisor is meant to function primarily as a dispatcher and controller rather than a regular assignee.

Availability and Lowest Workload

If the rule selects one member from several candidates, SupportCandy can use logic based on the nearest working hours or the lowest workload. That is not magic. It is an algorithmic suggestion that should be checked against real data. If working hours are incomplete or the team distributes work in an unusual way, automatic selection may look odd from a support manager's perspective.

The practical rule is simple: first verify the quality of the underlying data - categories, working hours, roles, member lists - and only then rely on automatic assignment. If agents do not manage tickets consistently inside the system, the minimum-workload mode will not compensate for poor operational discipline.

Example Condition for a Billing Team

Suppose your ticket form includes a Billing category. In Assign Agent Rule, you can create a condition that checks the ticket category and assigns that request to the Billing group. At the beginning, choose Assign group only so the supervisor can distribute requests manually. Once the team is comfortable with the queue, you can move to a "group plus one member" model if you want to speed up first response.

Post-rule check: create a test ticket with the target category, open it as an administrator, then as the group supervisor, and then as a regular member. That shows you not only that the assignment happened, but also what each role can actually see.

Email Notifications for Groups and Supervisors

Ticket routing is pointless if the team never learns about new events. In SupportCandy, notifications should not be assumed to be active automatically. The documentation explicitly says that email notifications are not enabled by default, and that an active SMTP plugin is required for actual email delivery. That means Agentgroups should always be tested together with notifications, not separately.

The ticket notifications documentation lists events for which templates can be created: ticket creation, reply, status change, category change, priority change, assigned agent change, subject change, field change, private note, feedback, SLA breach, and ticket deletion. Among the available recipients, the general options include Agent Group Members and Agent Group Supervisors. That is a key detail for Agentgroups: a notification can be sent not just to the "assigned agent" but specifically to the members or supervisors of the assigned group.

Who Should Be Notified at Different Stages

Do not enable every notification for every member. Your team will quickly start ignoring the emails. It is better to separate events by purpose:

• New ticket assigned to a group: notify supervisors.
• Assigned agent changed: notify the new assignee and, if needed, the supervisors.
• Customer replies on a ticket that is still in the group queue: notify supervisors so they do not miss an active conversation.
• Private note: send it only to the people actually involved in handling the ticket, so internal comments are not exposed unnecessarily.
• SLA breach: if the SLA extension is in use, notify the supervisor or responsible manager.

How to Test Email Without Reaching the Wrong Conclusion

If an email does not arrive, do not start by blaming Agentgroups. First verify the basic chain: is the notification template enabled, is the correct recipient selected, is SMTP configured, does the agent have a valid working email address, did the message land in spam, and is email sending disabled at the hosting level? Only after that should you check whether the ticket is assigned to a group and whether the chosen recipient type matches the assignment model.

Pay especially close attention to assignee-change events. The Agentgroups changelog includes a fix related to notifications for previously assigned groups. That does not mean your site will necessarily have the same issue, but it does show that group-based email scenarios are worth testing again after updates.

Practical Scenario: A Technical Support Queue with Supervisor Control

Let us look at a scenario that often appears on sites offering product or service support. There are three first-line agents, one senior specialist, and a separate Technical issue ticket category. The goal is for all technical requests to enter the team first, for the supervisor to see the queue, and then to assign each request to a specific assignee. Some tickets may stay in the group queue until more details are clarified.

Goal

Create a manageable "Technical Support" queue where a ticket does not get lost between agents, and where the supervisor can see every request assigned to the team. Regular agents should see only the tickets they personally receive.

Preparation

Before you begin, make sure SupportCandy already includes the first-line agents and the senior specialist. Check the supervisor's role: they need permission to view tickets and assign agents. Make sure the Technical issue category exists either in the ticket form or in ticket settings. If you use a separate ticket creation page, verify that the user can actually choose that category.

Configuration Steps

1. Go to Support - Support Agents - Agentgroups.
2. Create the Technical Support group.
3. In the Agents field, add all three first-line agents and the senior specialist.
4. In the Supervisors field, add the senior specialist. If the team is small and everyone should see the shared queue, you can add all members, but that should be an agreed workflow rule.
5. Save the group and create a test ticket in the Technical issue category.
6. Assign the ticket to the group manually, or configure a rule in Support - Settings - Assign Agent Rule - Assign Rules.
7. For the first test, choose Assign group only mode.
8. Open the ticket as the supervisor and confirm that they can see it.
9. Assign the ticket to one of the members and verify that the member can now see it in their own list.

Expected Result

The test ticket should enter the team queue. The supervisor should see it and be able to pass it to a member. The member should see the ticket after it is assigned to them. Another member should not see someone else's ticket unless the role settings or access model explicitly give them broader visibility.

The Detail That Causes the Most Trouble

If the supervisor assigns the ticket to an agent and removes the group assignment, they may lose access to that ticket within the group logic. Because of that, decide in advance which cases require the group to stay assigned until closure and which tickets should move fully to one assignee. For team oversight, it is often better to keep the group assigned as long as the request is active.

How to Design Your Team Map Before a Full Rollout

The most expensive mistake during an Agentgroups rollout is creating groups based on your internal company structure instead of your real ticket flow. A company may have sales, accounting, development, and service departments, but the user usually selects a problem, not a department: access was not received, payment is not working, they need advice, there is an error on the site, or there is a question about an order. If groups do not match the way tickets are created in the form, the supervisor will constantly reroute requests by hand.

Before creating production groups, it is helpful to review the last few dozen tickets and sort them by the reason for contact. You do not need to export personal data or read sensitive fields. It is enough to look at the category, subject, assigned agent, and the final team that actually resolved the issue. After a review like that, it often becomes clear that some planned groups are unnecessary, while one overloaded category really needs to be split.

The "Category - Group - Supervisor" Matrix

Build a simple matrix. In the first column, list the ticket category or signal. In the second, list the Agentgroups group. In the third, the supervisor. In the fourth, the assignment rule or manual process. This matrix does not have to live as a separate file on the site, but it should exist at least as an internal reference. Otherwise, a few weeks later no one will remember why the "General" category sometimes goes to technical support and sometimes to billing.

This kind of map helps not only with configuring Agentgroups but also with explaining the process to new staff members. If assignment rules are automated later, the matrix becomes a technical specification for Assign Agent Rules. If automation is not needed yet, it still establishes an orderly manual routing process.

Why You Should Not Create Too Many Groups

Highly granular groups look neat only at the moment you create them. In practice, they increase the number of decisions you need to make: which queue a ticket should enter, who the supervisor is, which notifications to enable, how to track reporting, and who owns bad assignments. The more groups you create, the higher the chance that two of them will end up solving almost the same problem.

Start with the smallest set that reflects real differences in handling. If two categories are handled by the same team, with the same supervisor and the same notification setup, separate groups may be unnecessary. If a category has its own SLA, dedicated specialists, and its own validation process, then a separate group is justified.

Practical check: if you cannot explain the difference between one group and the next in a single short sentence, it is probably too early to create it.

How to Connect Groups to Categories, Fields, and Workflow Statuses

Agentgroups does not choose a group by interpreting the meaning of a ticket's text. It needs an explicit route: either manual assignment by a supervisor or a rule that looks at ticket fields. That is why the quality of your ticket form directly affects the quality of your team queue. If the user selects an overly broad category and the subject is just free text, an automatic rule will not reliably send the ticket to the right team.

SupportCandy includes categories, statuses, priorities, custom fields, and agent-only fields. Not all of them need to be part of routing, but it is worth deciding in advance which signals truly direct a ticket. For Agentgroups, the most important ones are usually category, product, customer type, urgency, and sometimes the source of the request. The remaining fields are better used as context inside the ticket.

Category as the Main Route

The most understandable approach is routing by category. The user selects Billing, and the ticket goes to the billing group. The user selects Technical issue, and the ticket goes to technical support. That process is easy to test and easy to explain to the team. But it depends on category quality. If a category is called "Other", everything ambiguous will end up there, and the supervisor will have to sort through a mixed stream of unrelated tasks manually.

For categories, use wording that makes sense to the customer, not just to your agents. The internal group name might be L2 Technical, but in the public form it is better to use "Technical issue" or another label that is immediately clear. A user should not have to understand your department structure in order to submit the ticket correctly.

Fields for Clarification Inside the Group

If a single category still routes to different assignees, add one clarifying field. For example, in technical support you might ask for the product, the integration, or the site type. But do not overload the form: the more required fields you add, the higher the chance that the customer will pick random answers. It is better to start with one or two fields that actually change the routing decision.

Agent-only fields are useful for internal classification after the first review. A supervisor can mark the reason, difficulty level, or the need for escalation. Those fields should not be required for the customer, but they help you analyze which groups are overloaded and which topics need knowledge base coverage.

Statuses as Process Control, Not Group Routing

Statuses are best used for handling stages: open, waiting on customer, in progress, resolved, closed. Do not turn status into a replacement for group assignment. If you create statuses such as "Billing queue" and "Technical queue" while also keeping groups with the same names, the team will get confused about what actually defines responsibility. The group defines the team, while the status defines the stage of work.

A strong model looks like this: the category routes the ticket to the group, the supervisor or rule assigns the assignee, and the status shows the current stage. That makes reports and filters easier to read, and it also speeds up troubleshooting: if the ticket is in the wrong place, inspect the route; if the ticket is stalled, inspect the status and the assignee.

How to Verify the Result After Configuration

Testing Agentgroups should imitate the real life of a ticket. It is not enough to see that the group exists in the list. You need to confirm that the ticket enters the right queue, that the right people can see it, that notifications reach the intended recipients, and that members are not given unnecessary access.

Minimum Test Set

Create one test ticket for each live group. If you have groups such as Billing, Technical Support, and VIP, do not stop after a single test case. Each group needs its own validation. For every ticket, record the category, assignment, visibility, notification behavior, and final assignee.

• Check the ticket as a WordPress administrator.
• Check the same ticket as the group supervisor.
• Check it as a member who has not yet been assigned that ticket.
• Assign the ticket to a member and then check that member's list again.
• Send a test reply and confirm that notifications do not go to unnecessary recipients.
• Change the status and make sure the team understands who owns the next step.

What Counts as a Successful Setup

The setup is successful if the ticket lands in the expected group, the supervisor sees it before distribution, the assignee sees it after assignment, and unrelated members do not gain access to someone else's ticket. Email notifications should match your workflow: the supervisor gets alerted about a new group ticket, the assignee gets notified about assignment, and the customer receives the appropriate updates on their own ticket.

If you are using assignment rules, test not only the positive scenario but also category mistakes. Create a ticket with a different category and confirm that it does not land in the technical group. That kind of test protects you from overly broad conditions that quietly pollute the team queue.

Limitations, Security, and Careful Operation

Agentgroups does not make a support desk secure on its own. It helps manage the queue, but permissions are controlled by agent roles, SupportCandy settings, and the overall WordPress configuration. Because of that, group rollout should always be paired with a review of roles, email notifications, and internal ticket-handling rules.

Do Not Use Groups as a Replacement for Roles

If a person should not be allowed to view private notes, edit fields, delete tickets, or access logs, that must be controlled through the agent role. The group defines team membership and routing. If you give broad permissions to everyone in the group, you will not end up with a team queue. You will end up with a help desk that is too open.

Updates and Compatibility

The Agentgroups changelog shows fixes related to notifications, archiving, ticket deletion, translations, performance, and security. That is a strong argument for keeping it updated regularly, but it is still better to update a live system only after a basic check. That is especially true if you are also using Assign Agent Rules, Archive Tickets, Productivity Suite, email notifications, and custom agent roles.

After an update, test one ticket in every critical group. That is much faster than sorting out a situation where the team notices missing notifications or incorrect visibility only after a customer complaint.

Performance and Queue Hygiene

Simply having groups should not usually be the main source of system load. Ticket volume, the number of filters, notifications, custom fields, reports, and other add-ons have a much bigger impact. But a poor group structure can overload people: if every ticket immediately generates messages for multiple recipients, email and notifications turn into noise. Optimize not just the technical configuration, but also the workflow itself.

A useful operational habit is to review which groups are actually used once a month. If a group has not received tickets, or if all its tickets are manually moved to another team anyway, it is usually better to merge it, rename it, or remove it after reviewing the history.

Safe Improvements Without Editing Plugin Code

With Agentgroups, there is no reason to invent PHP hooks or edit extension files. The public documentation already gives you enough built-in tools: groups, agent roles, assignment rules, email notifications, support pages, and shortcodes. If you need to adjust the interface, it is safer to start with organizational changes and CSS tweaks without touching WordPress core, the main SupportCandy plugin, or the add-on itself.

A Short Internal Guide in Team Documentation

The most useful improvement for Agentgroups is often not code at all. Create an internal document for staff that explains which categories go to which groups, who the supervisor is, when the group stays assigned, when a ticket can be fully handed to one agent, and who receives notifications. That reduces mistakes more effectively than cosmetic interface changes.

A Careful CSS Tweak for the Support Page

Agentgroups mostly affects back-office ticket handling, not the public appearance of the form. But if you use a dedicated ticket creation page and want to visually highlight a note about choosing the right category, add it to the page content next to the shortcode instead of editing plugin files. A small CSS snippet can be placed in your theme settings or child theme.

.support-routing-note {
  margin: 16px 0;
  padding: 14px 16px;
  border-left: 4px solid #f1a501;
  background: #fff8e6;
  color: #2c2c2c;
  font-size: 15px;
  line-height: 1.55;
}

Then, before the [wpsc_create_ticket] shortcode, you can add a short HTML block with the support-routing-note class explaining that choosing the right category helps route the ticket to the right team faster. The validation is simple: open the page in incognito mode and make sure the note does not overlap the form or break the mobile layout. Rollback is just as simple: remove the CSS and the explanatory block from the page.

Do not add JavaScript to auto-switch categories or secretly assign teams unless you fully understand the SupportCandy API. That kind of customization can break tickets after an update and make support harder, not easier.

Why Groups May Not Work the Way You Expected

Agentgroups troubleshooting is best done as a chain: does the agent exist, does the group exist, who is the supervisor, how is the ticket assigned, what does the role allow, and are notifications configured correctly? Below are the most common symptoms that are specific to team-based routing in SupportCandy.

A Group Member Cannot See the Ticket

Symptom: the ticket is assigned to the group, the supervisor can see it, but the regular agent says nothing appears in their list.

Possible cause: the ticket is assigned only to the group and has not yet been passed to a specific member. In the Agentgroups model, members do not see tickets assigned to the group until the supervisor assigns them to one of the members.

What to check: open the ticket as an administrator, inspect the current assignment, and then check the same user behavior under a supervisor account and a member account.

How to fix it: assign the ticket to a member, or change the assignment rule to a "group plus one member" mode if that workflow is needed all the time.

The Supervisor Lost Access After Handing Off the Ticket

Symptom: the senior specialist assigned the ticket to an agent and then could no longer see it in the group's queue.

Possible cause: the group itself was removed during assignment. The product page specifically says that if a supervisor needs to assign the ticket to someone else, they should leave it assigned to the group, otherwise they may lose access.

What to check: the ticket's assignment history and current assignees. If the group is missing, the behavior is expected in a team-control model.

How to fix it: restore the group assignment for active team tickets and document an internal rule stating that the group remains until closure, or until the stage where team oversight is no longer needed.

Emails Do Not Reach Group Members or Supervisors

Symptom: the ticket is assigned correctly, but the group does not receive email notifications.

Possible cause: notifications are not enabled, the event template is turned off, a normal assignee was selected instead of Agent Group Members or Agent Group Supervisors, SMTP is not configured, or the email landed in spam.

What to check: notification status, the event type, the To, CC, and BCC fields, the SMTP log, the user's email address, and whether the ticket was actually assigned to the group.

How to fix it: enable the required template, choose the correct recipient type, and send a test ticket. If emails are not being sent at all, fix SMTP first, not Agentgroups.

An Automatic Rule Sends Tickets to the Wrong Team

Symptom: some billing requests end up in the technical group, or the reverse.

Possible cause: the rule condition is too broad, the form category is being selected inaccurately, the comparison operator is incorrect, or multiple rules are conflicting with one another.

What to check: the condition in Assign Rules, the rule order, test tickets with different categories, and the actual field value stored in the ticket.

How to fix it: narrow the condition, split the rules by category, temporarily return to manual group assignment, and test each route separately.

The Group Exists, but the Agentgroups Menu Item Is Missing

Symptom: the administrator expects to see the groups section, but it is not present in the SupportCandy menu.

Possible cause: the add-on is not active, the current user lacks the required permissions, the main SupportCandy plugin is not installed, or the extension is incompatible with the current configuration.

What to check: the WordPress plugin list, whether the core SupportCandy plugin is active, access to Support, the role of the current user, and any PHP errors in the hosting logs after an update.

How to fix it: activate the extension, verify administrator permissions, and update the core plugin and extensions through the standard process. If the error appeared after a PHP or WordPress update, record the exact error message before contacting support.

When SupportCandy Agentgroups Is the Right Choice

SupportCandy Agentgroups is a strong fit for teams that already use SupportCandy and want to move from individual ticket assignment to team-based queues. Its main strength is a clear model: a group, its members, its supervisors, assignment to the team, later handoff to a specific agent, and separate notification recipients for group members or supervisors.

Before rollout, it is worth assessing your support process honestly. If you do not have departments, supervisors, ticket categories, or a routing problem, start with the basic SupportCandy configuration. But if tickets regularly need to be routed to a team, monitored by a senior specialist, and then distributed among assignees, Agentgroups solves that problem without forcing you to migrate to a different help desk platform.

After validating a test scenario, you can get the WordPress version and roll it out to your live site in stages: one group, one route, one notification set, and only then expand the model to other departments. That approach lowers the risk of mistakes and helps the team adapt to the new logic without losing tickets.