SupportCandy Workflows - WordPress Plugin

How to Configure and Use SupportCandy Workflows

SupportCandy Workflows is not just another screen in the WordPress admin. Its real purpose is to remove repetitive work from ticket handling: assigning an owner, changing status, adding an internal note, updating a field, or letting a support agent launch a manual workflow. In this guide, we will look at how to set it up without creating chaos: what to check before installation, how the "trigger - condition - action" chain works, where automated workflows make sense, and where a manual trigger is the safer option.

This guide is written for a site owner, support administrator, webmaster, or manager who already understands the basic purpose of SupportCandy: receiving requests through WordPress and managing them as tickets. You will not find a reworded marketing overview here. Instead, we will walk through a practical rollout plan: preparing statuses and fields, setting up agent permissions, building a real escalation scenario, verifying the outcome, reviewing common mistakes, and looking at alternatives.

The main rule of ticket automation is simple: define your support process first, then map it into the plugin. If you start with the Add Workflow button, it is easy to end up with rules that change the status too early, assign the wrong agent, or send the customer an inappropriate reply. That is why this guide moves from process logic to settings, not the other way around.

What Ticket Automation Solves in SupportCandy

In a typical support operation, a large share of time goes into more than just replying to customers. An agent opens a ticket, reads the subject, checks the category, changes the priority, assigns the ticket, writes an internal note, sends a standard reply, and either closes it or moves it to the next stage. When ticket volume is low, manual handling is manageable. Once the queue starts growing, those repetitive tasks begin to consume more time than the actual troubleshooting.

SupportCandy Workflows is built specifically for that layer between ticket intake and human decision-making. According to the official documentation, a workflow can consist of conditions and actions, while the automatic version runs on ticket lifecycle events. In practice, that means part of your routine can become a predictable rule: a new high-priority ticket gets assigned, a request in the "Billing" category goes to the right team, an internal note is created when the status changes, and the agent sees a manual workflow only when the ticket matches the required conditions.

It is important to understand the boundary. The plugin does not replace your support lead and it does not make complex decisions for the team. What it does is standardize operational tasks: assign, flag, update, add internal text, and prepare the ticket for the next step. Complex disputes, legal questions, refunds, difficult customers, and technical investigations should still stay under human control.

Where Workflows Is Especially Useful

In practice, automation works best when the rule can be described in a short sentence and verified against ticket fields. For example: "if priority is high and the category is technical, assign the senior team"; "if the status changes to resolved, add an internal note with the verification checklist"; "if the agent selects the manual escalation workflow, switch the status to in progress and add a private explanation." Rules like these are easy to test, and the outcome is clear.

• Ecommerce support, where tickets need to be routed by orders, payments, shipping, and technical issues.
• A service website with multiple agents, where incoming requests need to reach the right team quickly.
• A training project or private community, where course, access, and account requests follow different paths.
• An agency serving clients through a single portal and looking to reduce manual ticket triage.
• Product support, where statuses, priorities, and internal notes need to stay consistent across all agents.

When It Is Better to Delay Automation

If your support process has not been defined yet, Workflows can lock in confusion instead of structure. First, the team needs agreement on which statuses are used, who owns which categories, which fields are required, when a ticket is considered resolved, and who is allowed to launch manual workflows. Without that, automation will change values based on formal signals alone, and the team will start working around the rules manually.

Practical check: if you cannot explain the rule in one sentence and name the expected result, it is too early to turn it into an automated workflow.

What to Check Before Installation and First Use

SupportCandy Workflows is an extension within the SupportCandy ecosystem, so before installing it, you should verify not only the ZIP file itself but also the core support configuration. Automation works with what already exists in the system: statuses, categories, priorities, agents, roles, custom fields, ticket widgets, and notifications. If those pieces are set up randomly, your workflows will inherit the same disorder.

Core SupportCandy and Support Pages

Start by confirming that the main SupportCandy plugin is installed, activated, and displaying a working support portal. The core documentation includes shortcodes for rendering the SupportCandy panel, the new ticket form, and existing ticket views. This matters for Workflows for a simple reason: automation should run against real tickets, not a test admin page with no actual user flow behind it.

Check the page where you use the main shortcode [supportcandy]. Create a test ticket, open it as an agent, and make sure you can see the status, category, priority, ticket fields, message history, and internal notes. If the main portal is not working, it is too early to move on to Workflows.

Statuses, Categories, and Priorities

An automated workflow usually depends on ticket fields. That is why it helps to clean up the values you plan to use in conditions ahead of time. You do not need dozens of statuses "for later." A practical set is enough: new, in progress, waiting on customer, resolved, closed. Categories should reflect routing logic, not marketing labels copied from your site navigation.

Be careful with priorities. If the user can mark a ticket as high priority in the form, automatic assignment to the senior team can become a way to jump the queue. In that case, it is safer to use a manual agent workflow or add another condition: category, customer type, order field, or an internal flag set after initial review.

Agents, Roles, and Permission to Launch Workflows

The official SupportCandy documentation describes a separate Trigger Workflow permission in the agent role settings. This is an important security control. Manual workflows should not be visible to everyone: an agent with a basic role may be allowed to reply to tickets, but that does not automatically mean they should be able to launch escalations, change internal fields, or reassign tickets between teams.

Before installing Workflows, decide which roles can only view tickets, which can change fields, which can assign agents, and which will receive permission to launch manual workflows. In a small team those permissions often overlap, but on a site with multiple agents it is better to separate them from the start.

Email, Notifications, and Caching

Workflows can change statuses, assignments, and fields. Those changes are often tied to notifications. Before building any workflows, confirm that SupportCandy emails are already being delivered correctly and that the site uses a reliable SMTP plugin or the hosting provider's mail transport. If email delivery is broken before automation, Workflows will not fix it.

Caching matters too. The SupportCandy admin area and pages with the ticket form should not be cached so aggressively that users see stale data. In most cases, excluding the support portal pages from full-page caching and testing the form as a normal user is enough.

Installing the Extension and Running the First Check in WordPress

Installing SupportCandy Workflows should not turn into an experiment on a live support queue. The best sequence is to make a backup, verify that core SupportCandy works, install the extension, create one safe test workflow, and only then move on to real rules. On a site where support is already active, it is best to do the setup during a low-traffic period or on a site copy first.

General Installation Flow

If you already have the extension as a ZIP file, use the standard WordPress flow: Plugins, then Add New, then Upload Plugin. After uploading it, activate the extension and return to the SupportCandy section. The automation documentation points to Support - Settings - Workflow. That is where you should expect to configure automated workflows.

1. Confirm that core SupportCandy is active and opens without errors.
2. Upload the extension ZIP through the standard WordPress plugin installation screen.
3. Activate the extension and refresh the admin page.
4. Open the SupportCandy settings and locate the Workflow section.
5. Create a test ticket with a neutral category and low priority.
6. Make sure existing tickets did not change after the extension was activated.

At this stage, do not create a rule that closes, deletes, or mass-updates tickets. Even if the action list includes status changes or deletion, your first test should be reversible. For example, you can add a private note to a test ticket or update a test field created specifically for validation.

The First Safe Test

For initial validation, it is best to create an automated workflow with a narrow condition: it should fire only for a test category or a test custom field. That way, real tickets remain untouched. If the condition fails, you can fix the rule without side effects. If it works, the private note or updated test field gives you clear proof that the chain executed.

Mini-summary after installation: the extension is active, the Workflow section is visible, a test ticket exists, a safe rule has been validated, and the team knows where to look for the result. Only after that does it make sense to configure real workflows.

The "Trigger - Condition - Action" Logic Without the Magic

It helps to think of Workflows as a small logical engine. It does not "understand" ticket content the way a human does; it simply checks specific events and fields. In automatic mode, an event happens first, then the workflow evaluates the conditions, and then it performs the actions. In manual mode, the agent launches the workflow through a widget, but the conditions still determine whether it can apply to that ticket.

Triggers: What Starts an Automated Workflow

The documentation lists the events that can start an automated workflow: creating a new ticket, adding a reply, adding a private note, changing the subject, category, priority, status, assignee, ticket fields, agent fields, and receiving a rating. That gives you a lot of flexibility, but it also demands discipline. The more often the event occurs, the more precise your conditions should be.

For example, the new ticket trigger works well for initial routing. The status change trigger fits stage-based actions: add a note, update an internal field, prepare a notification. The reply-added trigger should be used with care because it may fire frequently and create unnecessary changes during active back-and-forth conversations.

Conditions: Your Filter Against Accidental Matches

Conditions determine which tickets a workflow applies to. The documentation mentions ticket fields, custom fields, agent fields, and operators such as Equal to, Matches, and Has word. The more precise the condition, the lower the risk. If you use only the status "Open," the rule may affect too many tickets. If you add category, priority, and an internal field, the workflow becomes much safer.

The best SupportCandy Workflows setups usually begin with narrow conditions. Start with one category or one test field. Once the rule is validated, you can expand it. The reverse approach is worse: a broad rule may already have changed dozens of tickets before you notice the mistake.

Actions: What Actually Changes in the Ticket

Actions are the most sensitive part of the setup. The documentation describes adding a reply, adding a private note, changing the subject, status, category, priority, assignee, additional recipients, ticket fields, agent fields, and customer fields. The changelog also mentions a ticket deletion action, so you should treat the action list as a living set that can grow over time.

For your first workflows, choose actions that are easy to verify and easy to roll back: a private note, agent assignment, or a test field update. An automatic public reply should only be added after the team approves the text, because the customer will see it immediately. Deletion, mass reassignment, and ticket closure should be the last actions you adopt, and only after careful testing.

Automated Workflows for Repeatable Events

An automated workflow works best when both the event and the conditions are reliable enough. Because it runs on its own, a logic mistake will surface faster than it would in a manual workflow. On the other hand, automation is where you save the most time: the agent does not need to open every new ticket just to assign it or add a routine internal note.

Routing a New Ticket

The clearest scenario is initial assignment. A new ticket is created, Workflows checks the category and priority, then changes the assignee and adds a private note. In this setup, vague conditions are the main risk. If the "Technical Support" category is used for both minor questions and critical failures, add a separate field or priority rule so the workflow does not route everything to the senior team.

A solid structure for an automatic rule looks like this:

1. Trigger: a new ticket is created.
2. Conditions: the category is technical, the priority is high, and the "customer type" field matches the required support tier.
3. Action: assign the senior team or a specific agent.
4. Action: add a private note explaining why the ticket was assigned that way.
5. Validation: the test ticket received the correct assignee and did not land in the wrong queue.

Responding to a Status Change

A status change often signals a move to a new stage. For example, when an agent sets a ticket to waiting on customer, you can add an internal note reminding them what information was requested and when the ticket should be revisited. When a ticket is marked resolved, you can update an internal field or add a verification checklist. The key is not to let an automated status stand in for actual response quality.

If a ticket changes status multiple times, think about protecting against repeats. The documentation does not mention a universal "run once" flag, so at the process level it is better to use a more precise condition: a dedicated agent field, a specific category, or a manual workflow instead of an automatic one. That reduces the risk of the same action firing more than once.

Auto-Replies Without Annoying the Customer

The add reply action can be useful, but it is easy to overuse. Customers do not need a stream of template messages every time a field changes. An auto-reply is justified when it addresses a specific expectation: confirming receipt of a ticket, letting the customer know the issue was routed to the right team, or requesting missing information for a narrow type of request. The message should be short, calm, and honest.

Safe principle: if the message would look awkward when sent more than once, do not use it as an automatic reply without additional safeguards.

Manual Workflows and the Ticket Page Widget

Manual workflows operate differently. They do not have a predefined system trigger; instead, an agent launches them through a widget on the ticket page. The documentation specifically notes that the widget displays available workflows when the conditions match, and the right to launch them is controlled by the agent role settings. That makes the manual option especially useful for actions that require human judgment.

When a Manual Workflow Is Better Than an Automatic One

A manual workflow is useful when the conditions can be checked formally, but the final decision still depends on context. Examples include escalation to the senior team, moving a ticket to waiting on customer, adding an internal note about a complicated case, or assigning a specific group after the request has been reviewed. The agent sees the ticket, makes the decision, and launches the prepared sequence of actions with one click.

This approach reduces risk. If the customer selected the wrong category or used a word that accidentally matches a Has word condition, an automatic workflow could fire incorrectly. A manual launch keeps the final check in human hands.

The Workflows Widget and Ticket Screen Layout

SupportCandy lets you manage individual ticket widgets under Support - Settings - Ticket Widgets. In the widget list, the documentation mentions Workflows, along with the ability to enable, disable, rename, and reorder widgets. For a support team, this is not cosmetic; it is part of the actual workflow.

If the workflows widget sits too low on the page, agents will forget about it. If it is placed above more important fields, the screen becomes noisy. A good position is next to the main internal blocks, where the agent is already reviewing status, assignee, ticket fields, and internal notes. After configuration, ask one agent to walk through a real test ticket and identify the point where they naturally expect to see a manual action.

Launch Permissions and Reducing Mistakes

The Trigger Workflow permission should be granted intentionally. A junior agent role can still allow replies and private notes without allowing workflows that change assignment, status, or customer fields. For a senior agent or support administrator, manual workflows can become a core standardization tool: every complex case gets handled with the same action set.

Practical Example: Escalating an Urgent Technical Ticket

Now let us build a concrete scenario that can be adapted for a real site. The goal is to speed up urgent technical requests without letting every customer jump into the senior queue just by selecting a high priority. To do that, we split the process into two parts: an automated initial flag and a manual escalation after the agent reviews the ticket.

Scenario Goal

We want a new ticket in the technical category with high priority to immediately receive an internal flag and enter the team's line of sight. But the final reassignment to the senior support team should still be launched by an agent after reading the request. This approach works well on sites where users can choose their own priority, and the team does not want blind automatic escalation.

Preparation

Before configuring anything, make sure SupportCandy already has a category for technical issues, a "High" priority or its local equivalent, an agent role for senior support, and the Trigger Workflow permission for the agents who will launch the manual workflow. If you use a separate "issue type" field, prepare its values in advance.

Automatic Part

1. Open Support - Settings - Workflow - Automatic.
2. Create a workflow with a clear name, such as "Urgent technical ticket flag."
3. Select the new ticket created trigger.
4. Add conditions: category is technical, priority is high, and if needed, an extra field matches the required issue type.
5. Add a private note action: the agent should verify urgency and decide whether escalation is necessary.
6. If needed, add an action that assigns the ticket to the first-line team, but not directly to a senior specialist if human review is required.
7. Save the workflow and test it on a test ticket only.

Manual Part

1. Create a manual workflow called "Escalate to senior support."
2. Add the conditions under which it should appear: priority is high, category is technical, and the status is not closed.
3. Add the actions: assign the senior team, change the status to "in progress," and add a private note with the reason for escalation.
4. Check that the workflow appears in the widget only for agents who have launch permission.
5. Create a second test ticket that does not match the conditions and make sure the workflow does not appear.

Expected Result

After setup, a new urgent technical ticket gets an internal trail: a private note and, if you choose, an initial assignment. The agent opens the ticket, reads the context, launches the manual escalation, and the system performs the same set of actions every time. The result is a more predictable process without the risk of full blind automation.

A Common Obstacle

If the manual workflow does not appear in the widget, do not rush to reinstall the extension. Check three things first: do the conditions actually match the current ticket fields, is the Workflows widget enabled in the ticket widget settings, and does the agent role have the Trigger Workflow permission? In most cases, the problem sits in one of those three places rather than in the installation itself.

How to Verify the Result After Setup

Workflows should be tested as carefully as an order form or contact form. Automation changes real ticket data and may also send replies or notifications. That means it is not enough to see that the workflow saved successfully in the admin panel. You need to walk the whole path: create a test ticket, trigger the required event, verify the conditions, inspect the actions, and make sure unrelated tickets were not affected.

Test Matrix

For each workflow, create a small validation checklist. You do not need a separate tool; a simple table in your team document is enough. It should include a positive case, a negative case, and an edge case. The positive case should fire. The negative case should not. The edge case helps you see what happens when the conditions are close, but not an exact match.

Notification Checks

If the workflow changes the assignee, status, or adds a reply, verify email notifications. Create a test customer with a real mailbox, create a test agent, and walk through the workflow. You need to answer more than just "did an email arrive?" You also need to know "who received it," "how many emails were sent," "were there duplicates," and "did any private information leak to the customer?"

Permission Checks

Log in under different agent roles. A junior agent should not see workflows they are not allowed to use. A senior agent should see the manual workflow only on tickets where the conditions match. An administrator should be able to fix the rule if it turns out to be too broad. This kind of check takes little time, but it prevents mistakes in the live queue.

Mini-summary: a workflow is only ready after you validate the positive, negative, and edge cases. If you have tested only one successful example, the rule is not ready for live traffic.

How Workflows Connects to Fields, Widgets, and Neighboring Extensions

Workflows becomes much more useful when the underlying SupportCandy structure is set up carefully. Automation does not exist separately from fields and roles. It uses them as the language of rules. The better your ticket fields and agent permissions are defined, the more precise your workflows can be.

Ticket Fields as the Foundation of Conditions

The ticket field documentation explains that ticket fields can be system or custom, can appear in the new ticket form and the individual ticket widget, and can be editable after creation depending on agent permissions. For Workflows, that means custom fields can serve as more precise conditions: product type, source of the issue, customer tier, access required, or consent for diagnostics.

Do not turn the ticket form into a long questionnaire. It is better to add two or three fields that genuinely change the routing path than to collect ten parameters that nobody uses in conditions. If a field does not affect filtering, automation, or reporting, it may only get in the user's way.

Ticket Widgets as the Agent's Workspace

SupportCandy widgets display the current ticket state: status, customer, fields, assignee, additional recipients, tags, SLA, timer, Workflows, and other blocks. Widget configuration has a direct impact on agent speed. If workflows are buried too deep, agents will go back to manual actions. If the Workflows widget is enabled without role limits, people who do not need it will still see it.

After rolling out Workflows, it is worth doing a short review with the team: which widgets need to be on the first screen, which can sit lower, which workflows should stay manual, and which are better removed from the interface. This is not a minor technical detail; it is part of workspace design.

Neighboring Extensions and the Risk of Rule Overlap

The SupportCandy ecosystem includes extensions for auto assignment, SLA, auto close, timer, reports, WooCommerce, EDD, LMS, Slack, Webhooks, and other use cases. They can complement Workflows, but sometimes they overlap in meaning. For example, one extension may track service deadlines, another may close inactive tickets, while Workflows changes the status or assignee.

The safe approach is to avoid duplicating the same rule in different places. If a separate extension already handles assignment, do not build a parallel workflow with a similar condition. If SLA depends on ticket status, test carefully any workflows that change that status. The more automation you add, the more important it becomes to maintain a rule map.

Limits, Safety, and Ongoing Rule Maintenance

All automation ages. Statuses change, teams change, agent roles change, product structures change, ticket categories change, emails change, and customer expectations change. That is why Workflows needs more than initial setup; it needs maintenance. Otherwise, an old rule may continue running long after the team has already changed the process behind it.

Do Not Automate Deletion and Closure Without Separate Validation

The extension changelog shows that the action set evolves, including the addition of ticket deletion. That may be useful in some processes, but in a typical support environment those actions require special caution. Closing or deleting tickets affects conversation history, reporting, legal issues, and customer trust. If an action is irreversible or difficult to verify, replace it first with a private note or an internal field update.

Keep a Human-Readable Rule Log

Workflow names should explain the purpose, not just the technical trigger. Bad examples: "Rule 1," "High," "Auto status." Better examples: "Urgent technical ticket flag," "Manual escalation to senior support," "Private note when moved to waiting on customer." Once you have more workflows, names like these make it much easier to see which rule can be disabled.

It is also useful to keep a short external list: rule name, purpose, owner, last review date, fields involved, and what counts as a successful outcome. We do not use dates inside the HTML guide itself, but they are useful in the team's working document for ongoing maintenance.

Why This Guide Does Not Include a PHP Snippet

With Workflows, you should not invent hooks, classes, or internal functions unless they are confirmed in the developer's documentation. The official materials describe configuration through the interface, roles, widgets, conditions, and actions. That makes it safer to recommend configuration patterns, test matrices, roles, and cache exclusions instead of code that might break after an update.

If you need a custom integration with an external system, look to documented SupportCandy capabilities, Webhooks, or the core product's REST API. Do not edit plugin files directly, and do not leave production logic in a random theme snippet without a rollback plan.

Practical Use Cases Without Overloading the System With Rules

After the first successful test, the temptation is to automate everything: every category, every status, every reply, and every assignment. That is almost always the wrong path. A good SupportCandy Workflows setup is not based on "how many rules can we create?" but on "which repetitive actions are actually slowing agents down?" Below are several scenarios that work well for gradual rollout and do not require imaginary features beyond the official trigger, condition, and action model.

Initial Triage by Category and Priority

This is the most obvious scenario, but it still needs care. If a new ticket comes in under the "Technical Support" category, you might add a private note with a short checklist: confirm the product version, ask for a screenshot, and clarify any recent changes on the site. If the priority is high, you might assign the on-duty agent or the first-response team. But it is usually better not to change the status to "in progress" automatically if that status implies an agent has already started working the ticket. Status should reflect reality, not an attempt to make the queue look shorter.

Testing this workflow is simple: create three test tickets with different categories and priorities. One should match the rule, and the other two should remain unchanged. If the rule touches an extra ticket, add another condition based on a custom field or make the action less aggressive: a private note instead of reassignment.

Internal Notes for Consistent Handling Standards

A private note is an underrated action. The customer never sees it, it does not change the public state of the ticket, and it works well for team enablement. For example, when a ticket is moved to waiting on customer, you can automatically remind the agent: "Make sure your reply includes the exact list of details needed for troubleshooting." When a ticket is moved to resolved, you can add a note for final verification: "Confirm that the customer received the solution and that the related internal checklist is complete."

This kind of workflow is especially useful when the team includes agents with different experience levels. The automatic note does not force extra clicks, but it gently standardizes the process. If, after a few weeks, the team no longer needs the reminder, the rule can be disabled or replaced with a narrower workflow that applies only to new agents.

Manual Escalation Without Assignment Chaos

Escalation often looks like a simple transfer to a "senior specialist," but in reality it should leave a clear trail: why the ticket was handed off, what has already been checked, which status was chosen, and who owns it now. A manual Workflows rule helps standardize that. The agent reads the ticket, confirms that it genuinely requires senior support, launches the workflow, and the plugin changes the status, assigns the correct team, and adds an internal note.

Here it is useful to add a condition that blocks escalation for closed tickets or requests in the wrong category. That way, the widget does not become a wall of buttons for every possible case. The agent sees only the manual actions that make sense for the current ticket.

Routing Paths for WooCommerce, EDD, or LMS Tickets

If your site uses neighboring SupportCandy integrations, you can design workflows around data that helps explain customer context: order, product, subscription, course, or another related entity. But do not promise more than your actual configuration provides. First, verify which fields really appear in the ticket and are available in conditions. Then build the rule around a confirmed field, not around an assumption that the integration "probably knows" the right information somewhere behind the scenes.

For example, if the ticket form includes a product selector or request type field, the workflow can add an internal note with the review path. If a WooCommerce widget is enabled, the agent may see order history, but the automated action should still depend on a field that is actually available in rules. That approach protects you from situations where the scenario makes sense on paper but has no reliable condition in the interface.

A Working Rule Map for the Team

To avoid drowning in rules, keep a workflow map. It only needs a few columns: name, launch type, event or manual launch, conditions, actions, owner, when it was last checked, and what to do if it fails. This map is not about bureaucracy; it is about maintainability. When an agent says "the ticket changed status on its own," the administrator should be able to find the responsible rule quickly.

If you are unsure whether a workflow should be automatic or manual, start with manual. After a week of real use, it becomes much clearer which actions agents keep launching in the same way every time. Those are the ones worth moving into automatic mode, because you already have proof that they are truly repeatable.

Common Problems When Configuring Workflows and How to Diagnose Them

Most SupportCandy Workflows issues are not caused by the installation itself, but by mismatched conditions, permissions, widgets, and expectations. Below is a diagnostic checklist worth going through before contacting support or rolling back the extension.

The Workflow Does Not Run After a Ticket Is Created

Symptom: the ticket was created, but the status, assignee, field, or private note did not change. A likely cause is the wrong trigger, a condition that does not match the actual field value, or a workflow that was saved but not activated.

What to Check

• Create a ticket with the exact values defined in the conditions.
• Make sure the category, priority, and custom fields match not just in meaning, but by the exact stored value.
• Temporarily reduce the workflow to a single private note action so you can confirm whether it fired at all.
• Make sure you are testing a new ticket if the trigger is configured for new ticket creation.

Start the fix with the simplest condition. If one condition works, add the others back one at a time. That makes it much easier to identify the field that is blocking the rule.

The Manual Workflow Is Not Visible to the Agent in the Widget

Symptom: the workflow exists, but the agent cannot see it in the Workflows widget on the ticket page. There are usually three causes here: the conditions do not match, the widget is disabled, or the agent role does not have the Trigger Workflow permission.

First, open the ticket as an administrator and check whether the workflow appears under the same field values. Then review Ticket Widgets and the agent role. If the workflow is visible to the administrator but not to the agent, the issue is almost certainly permissions or visibility settings.

The Rule Fires Too Broadly

Symptom: the workflow applied to tickets that should not have changed. A likely cause is a condition that is too broad: one status, one category, or a word-match operator with no additional filter.

In that case, it is best to disable the rule immediately, assess the affected tickets, and add tighter limits: category, priority, agent field, customer type, or a separate test marker. If the action was a public reply, prepare a short explanation for the customers who were affected by the mistake.

Emails Arrive Multiple Times or Do Not Reach the Expected People

Symptom: after the workflow runs, the agent or customer receives duplicate notifications, or the email does not arrive at all. Workflows can change fields that affect notifications, but email delivery still depends on your general mail setup, SupportCandy notifications, and SMTP.

Test the core notifications without Workflows first, then repeat the scenario on a test ticket. If duplicates appear only after automation is enabled, check whether multiple rules are firing on the same event and whether you are adding a public reply alongside a status change that also triggers a notification.

The Workflow Conflicts With SLA, Assignment, or Auto Close

Symptom: service deadlines, assignment, or ticket closure behave differently than expected. The cause may be overlap between multiple extensions or rules. For example, one mechanism changes status, another calculates SLA, and a third closes inactive tickets.

Make a list of all automations that touch the same status or field. Do not disable everything at once; disable one rule at a time on a test ticket. If the conflict appears only under a specific combination, separate responsibilities: one rule assigns, another tracks deadlines, a third adds a note, but they should not all modify the same field for no reason.

Action Behavior or the Interface Changed After an Update

Symptom: a workflow that used to work starts behaving differently after updating the core plugin or the extension. The official changelog shows that fixes and new actions are released regularly, so key workflows should be retested on test tickets after updates.

Do not automatically roll the update back. First, check which rules were affected, whether field values changed, whether a new action with similar meaning was added, and whether an old bug was fixed that your process had been relying on accidentally. If the problem is critical, disable only the specific workflow and keep the rest of the system operational.

When SupportCandy Workflows Is the Right Choice

SupportCandy Workflows is a strong fit if your support operation already runs on SupportCandy and the team keeps repeating the same ticket actions: assigning owners, changing statuses, adding internal notes, updating fields, and launching escalations. The extension is especially useful when the process can be described as rules and verified on test tickets.

Do not expect it to provide intelligent hands-off support management on its own. The best results come when you already have a clear structure of statuses, categories, roles, and fields. In that case, Workflows turns that structure into automated and manual workflows instead of trying to replace management decisions.

Before rollout, run one final short check: core SupportCandy works, agent roles are configured, the Workflows widget is enabled only where needed, your first rules are narrow and reversible, notifications have been tested, and each workflow has a test matrix. After that, you can download the SupportCandy Workflows package and test the extension on a site copy or during a safe maintenance window.

If the test shows that the rule genuinely saves time and does not create side effects, move it into the live process. If agents constantly need the workflow explained or keep correcting its results by hand, simplify the conditions, switch it to manual launch, or disable it for now. Good support automation should be boring in the best possible way: clear, testable, and predictable.