How to Triage Support Tickets Against a Persistent Troubleshooting Manual
Build a Spojit workflow that reads each incoming support ticket, queries a persistent troubleshooting manual in a Knowledge collection for the right fix, then tags the conversation in Front and posts a suggested resolution to the team in Slack.
What This Integration Does
Support teams answer the same handful of problems over and over, and the canonical answers usually live in a troubleshooting manual that nobody has time to search mid-shift. This workflow closes that gap. When a new ticket lands, Spojit pulls the customer's question, queries your Knowledge collection for the matching troubleshooting steps, and hands the agent a ready-made draft of what to do and where to route it. The persistent collection means the manual is embedded once and reused by every run forever, so you are not re-uploading documents on each ticket.
The run is triggered by an Email trigger watching your support mailbox. Each matching message starts one execution: Spojit queries the persistent collection with the ticket text, uses a Front connector node in Agent mode to find the conversation and tag it, and sends the suggested resolution to a Slack channel with send-message. Nothing about the customer-facing reply is sent automatically, so this is safe to leave running: it only enriches and routes, leaving a human to send the final answer. Re-runs are independent, and because the Knowledge query is read-only, replaying a ticket produces the same suggestion without side effects beyond a duplicate tag or Slack post.
Prerequisites
- A persistent Knowledge collection containing your troubleshooting manual. Create it under the Knowledge section in the sidebar with New Collection, then open it and use Upload Document followed by Upload & Embed for each manual file (PDF, Word, Markdown, and so on). Note the embedding model chosen at creation.
- A connected mailbox for the Email trigger. Add it under Connections → Add connection → Gmail (trigger) or Outlook (trigger) (OAuth, read-only is enough).
- A Front connection with API access to read and tag conversations.
- A Slack connection with permission to post to your triage channel, and the target channel ID or name.
- At least one Front tag created for triage outcomes (for example
kb-suggested), and the inbox or team you route to.
Step 1: Trigger on incoming support email
Add a Trigger node and set its type to Email. Pick the connected Gmail or Outlook mailbox, choose the folder that receives support tickets, and set a poll interval (1 to 60 minutes, default 2). To avoid noise, set the optional Subject regex or a From allowlist so only genuine tickets start a run. The trigger output gives you the fields you need downstream, including {{ subject }}, {{ textBody }}, {{ from }}, and {{ conversationId }}. The conversationId is what links this email to its Front conversation.
Step 2: Query the troubleshooting manual
Add a Knowledge node and set its mode to Query. In Collection, select your persistent troubleshooting collection (not Transient: you want the long-lived manual). Set Prompt to a template that feeds in the ticket text, choose a Model for synthesis, and leave Result Count at the default 5. To get a clean, machine-usable answer, supply a Response Schema so the output is structured rather than prose. A workable prompt and schema:
Prompt:
A customer raised this support ticket. Find the matching
troubleshooting procedure in the manual and summarise the
resolution steps. Suggest which team should handle it.
Subject: {{ subject }}
Body: {{ textBody }}
Response Schema:
{
"type": "object",
"properties": {
"summary": { "type": "string" },
"resolutionSteps":{ "type": "array", "items": { "type": "string" } },
"suggestedTeam": { "type": "string" },
"confidence": { "type": "string", "enum": ["high","medium","low"] }
},
"required": ["summary","resolutionSteps","suggestedTeam","confidence"]
}
Set Output Variable to triage. Downstream you can read {{ triage.summary }}, {{ triage.resolutionSteps }}, {{ triage.suggestedTeam }}, and {{ triage.confidence }}.
Step 3: Branch on confidence
Add a Condition node that checks whether the Knowledge query was confident enough to act on. Set the condition to test {{ triage.confidence }} equals high or medium. Wire the true branch to the tagging and notification steps below. Send the false branch to a Slack node that posts a short "no confident match, needs manual review" message, so low-confidence tickets are flagged for a human rather than silently mis-routed.
Step 4: Tag and locate the conversation in Front (Agent mode)
On the true branch, add a Connector node, choose the Front connector, and switch it to Agent mode. Agent mode lets the intelligent layer pick and chain the right Front tools rather than you wiring each call by hand: it can use get-conversation to confirm the ticket, list-tags to find the correct tag, and add-tag to apply it. Give it a focused prompt and a Response Schema so the result is structured:
Find the Front conversation for ticket {{ conversationId }}.
Apply the tag named "kb-suggested" to it. If the suggested team
is "{{ triage.suggestedTeam }}", also apply a tag matching that
team name if one exists. Return the conversation id and the tags
you applied.
Set the node's Output Variable to front. Keep the instruction explicit and name the exact tag text so the agent does not guess. If you prefer fully deterministic behaviour, you can instead use a Connector node in Direct mode with the add-tag tool and map the conversation and tag inputs yourself.
Step 5: Post the suggested resolution to Slack
Add a Connector node for the Slack connector in Direct mode and select the send-message tool. Set the channel to your triage channel and build a message from the Knowledge output so an agent can act without re-reading the ticket:
:ticket: *New support ticket triaged*
*From:* {{ from }}
*Subject:* {{ subject }}
*Suggested team:* {{ triage.suggestedTeam }} (confidence: {{ triage.confidence }})
*Summary:* {{ triage.summary }}
*Resolution steps:*
{{ triage.resolutionSteps }}
Tagged in Front: {{ front.conversationId }}
If you want to @-mention the owning agent, add a Slack node first with lookup-user-by-email to resolve a teammate email into a Slack user, then reference that user in the message.
Step 6: Optionally notify the customer that you are on it
If your team likes to acknowledge tickets fast, add a Send Email node after the Slack post. It sends from Spojit's built-in mail service with no connection needed. Set Recipients to {{ from }}, a friendly Subject, and a Body confirming the ticket was received and is being worked. Keep this acknowledgment-only: do not paste the internal {{ triage.resolutionSteps }} to the customer. External recipients must be on your org allowlist under Settings → General → Email recipients.
Step 7: Save, name, and enable
Give the workflow a clear name such as "Triage tickets against troubleshooting manual", save it, and enable it so the Email trigger begins polling. You can ask Miraxa, the intelligent layer across your automation, to scaffold any missing node for you with a prompt like "Add a Knowledge Query node against my troubleshooting collection that reads the ticket subject and body and returns structured resolution steps", then fine-tune the fields in the properties panel.
Tips
- Use the same embedding model for querying that you used to embed the manual. The collection's model is fixed at creation, so the Query node matches it automatically when you select that collection.
- Keep the manual fresh: when procedures change, re-upload the document with the same file name so the new version overwrites the old chunks. The persistent collection is readable by any workflow in your workspace.
- Lower Result Count to 3 for short manuals to cut tokens, or raise it for large, varied manuals where the right procedure might be buried.
- Front tag names must match exactly. Use
list-tagsonce to confirm the spelling before hard-coding tag text in the Agent mode prompt.
Common Pitfalls
- If
{{ triage.suggestedTeam }}comes back empty, your Response Schema likely was not enforced. Confirm the schema is set on the Knowledge node and markssuggestedTeamas required. - An Email trigger with no Subject regex or From allowlist will fire on autoresponders and newsletters. Filter at the trigger so you do not waste AI credits triaging spam.
- The Email trigger polls, so there is up to one poll-interval of delay before a ticket is picked up. Lower the interval if you need faster triage, but mind the minimum of 1 minute.
- If Front cannot find the conversation, the
conversationIdfrom the mailbox may differ from Front's own conversation id. Have the Agent mode prompt fall back to searching by subject or sender withlist-conversationsbefore tagging. - Slack rejects posts to channels the connection has not joined. Invite the connection to the triage channel, or post to a channel it already belongs to.
Testing
Before enabling the live trigger, validate the core path on a single ticket. Send yourself a test email that matches a known problem in the manual, then temporarily run the workflow and inspect the execution log. Confirm the Knowledge Query node returned a sensible triage.summary with non-empty resolutionSteps, that the Front node applied the expected tag, and that the Slack message rendered the variables correctly. Once one ticket flows end to end and the confidence branching behaves, point the trigger at your real support folder and enable the workflow.