How to Triage New Front Conversations into Monday Tickets with AI Priority Scoring

Build a Spojit workflow that polls Front for new conversations on a schedule, uses an Agent-mode Connector node to classify each one into a category, urgency, and a 1-5 priority score, then routes by score and opens a Monday.com ticket with the score and a link back to the Front conversation.

What This Integration Does

Support teams that live in Front often need a second system of record for work that has to be tracked, assigned, and reported on, and Monday.com boards are a common home for that. Copying conversations across by hand is slow and inconsistent, and the most urgent issues are easy to miss in a busy inbox. This workflow watches Front for newly created conversations, asks the agent to read each one and assign a category, an urgency, and a numeric priority from 1 to 5, then creates a Monday.com item on the correct board with those fields mapped into columns and a direct link back to the original Front conversation.

The workflow runs on a Spojit Schedule trigger, so it polls Front at a fixed cadence (for example every five minutes during business hours). On each run it lists conversations created since the previous poll, scores each one with a Connector node in Agent mode, branches on the score with a Condition node, and writes a Monday.com item. Because the workflow only creates tickets and never edits Front, re-runs are safe to the extent that you track which conversations you have already processed: the Tips section below shows how to keep a high-water mark so the same conversation is never ticketed twice.

Prerequisites

A Front connection in Spojit with an API token. See the Front connector article and Setting Up an API Key Connection.
A Monday.com connection in Spojit with an API token that can create items on the target board. See the Monday.com connector article.
The Monday.com boardId for your support board, plus the column IDs you want to populate (for example a Status column, a numeric Priority column, and a Link or Text column for the Front URL). You can read these with the get-board tool before you build the mapping.
Optional but recommended: a column or board to record the last poll time, or use a Spojit workflow variable strategy as described in Tips, so you only ticket conversations created since the previous run.

Step 1: Start with a Schedule trigger

Add a Trigger node and set its type to Schedule. Schedules use a 5-field Unix cron expression plus an IANA timezone. To poll every five minutes on weekdays from 8am to 6pm in Sydney, use:

*/5 8-18 * * 1-5

Set the timezone to Australia/Sydney. A single Schedule trigger can hold multiple schedules if you want different cadences. The trigger output is {{ scheduledAt }}, the time the run fired, which you will use as the upper bound when deciding which conversations are new. For a deeper walkthrough of cron fields, see Setting Up a Schedule Trigger.

Step 2: List new conversations from Front

Add a Connector node on the Front connector in Direct mode and choose the list-conversations tool. This tool accepts an optional q search query and an optional page_token for pagination. Use the q field to narrow results to an inbox and a recency window, for example:

inbox:support after:{{ lastPolledAt }}

The tool returns an envelope containing a list of conversation resources. Each conversation includes id, subject, status (one of unassigned, assigned, archived, deleted, spam), created_at as a Unix timestamp, tags, and last_message. If more pages exist, the envelope exposes a pagination token; pass it back into page_token on a follow-up call (a Loop node in While mode is a clean way to drain all pages). Keep the result in a variable such as {{ conversations }}.

Step 3: Loop over each conversation and score it with Agent mode

Add a Loop node in ForEach mode over the conversation list (for example {{ conversations.result._results }}, adjusting to the field name you see in the run output). Inside the loop, add a Connector node in Agent mode and give the agent a prompt that classifies the current conversation. Agent mode supports a Response Schema that forces the output into structured JSON, which is what makes the score reliable to branch on. Set the prompt to something like:

Read this support conversation and classify it.
Subject: {{ conversation.subject }}
Latest message: {{ conversation.last_message }}
Return a category, an urgency level, and a priority
score from 1 (lowest) to 5 (highest).

Define the Response Schema so the node always returns the same shape:

{
  "type": "object",
  "properties": {
    "category": { "type": "string" },
    "urgency":  { "type": "string", "enum": ["low", "medium", "high"] },
    "priority": { "type": "integer", "minimum": 1, "maximum": 5 },
    "reason":   { "type": "string" }
  },
  "required": ["category", "urgency", "priority"]
}

Store the result in a variable such as {{ score }}. Agent mode costs AI credits per call; if you only need classification and not multi-tool reasoning, this single scoped prompt keeps the cost low. To understand when to reach for Agent mode versus Direct mode, see How to Choose Between Agent Mode and Direct Mode.

Step 4: Shape the ticket payload with a Transform node

Add a Transform node to assemble exactly the fields Monday.com needs, so the create step stays clean. Build the Front conversation URL, the item name, and the column values map in one place. For example, produce an object like:

{
  "itemName": "[P{{ score.priority }}] {{ conversation.subject }}",
  "frontUrl": "https://app.frontapp.com/open/{{ conversation.id }}",
  "category": "{{ score.category }}",
  "priority": {{ score.priority }}
}

Keeping this in a Transform node means the next node only references clean variables such as {{ ticket.itemName }} and {{ ticket.frontUrl }}. For more on reshaping data between steps, see Using Transform Nodes (Structured Mode).

Step 5: Route by priority with a Condition node

Add a Condition node to branch on the score. A common split is to send high-priority work to an escalation group and everything else to the standard intake group. Set the condition to test the priority, for example:

{{ score.priority }} >= 4

The true branch handles urgent conversations (you might target a different Monday.com group or board, or add a Send Email node to alert a lead). The false branch handles the rest. Both branches then flow into a Monday.com create step in the next step. For more on branching, see Using Condition Nodes.

Step 6: Create the Monday.com ticket

On each branch, add a Connector node on the Monday.com connector in Direct mode and choose the create-item tool. Its inputs are boardId (required), name (the item name), an optional groupId to place the item in the right group, and columnValues, a structured object keyed by column ID. Map your scored fields into the columns you identified earlier:

boardId:  "1234567890"
name:     "{{ ticket.itemName }}"
groupId:  "topics"
columnValues: {
  "status":     { "label": "{{ score.urgency }}" },
  "numbers":    "{{ score.priority }}",
  "link":       { "url": "{{ ticket.frontUrl }}", "text": "Open in Front" },
  "text":       "{{ score.category }}"
}

Replace the keys (status, numbers, link, text) with your real column IDs from get-board. The tool returns the new item's id and name, which you can keep in a variable for logging. The high-priority branch can target a different boardId or groupId than the standard branch. For a related build, see How to Create Monday.com Tasks from Emails.

Step 7: Record what you processed

To avoid ticketing the same conversation on the next poll, end the run by recording the newest created_at you handled as your high-water mark, then use it as {{ lastPolledAt }} in the Step 2 query. A simple approach is to store this value where you can read it back at the start of the next run, such as a small Monday.com item, a row via the mysql or mongodb connector, or a dedicated tracking board. Whichever store you choose, write it at the end of the workflow so a failed run does not advance the marker past conversations you never ticketed.

Tips

Front timestamps are Unix epoch seconds. If you compare them, convert consistently using the date connector rather than mixing string and numeric comparisons.
Keep the Agent-mode prompt focused on a single conversation and rely on the Response Schema enum and minimum/maximum constraints so the score is always a valid 1-5 integer you can branch on.
If volume is high, drain pagination with a Loop in While mode that follows the page_token until no further token is returned, so you never miss conversations on busy mornings.
Ask Miraxa to scaffold the canvas for you, for example: "Add a Loop over the Front conversations, then a Connector node in Agent mode that returns a priority from 1 to 5, then a Condition that checks if the priority is at least 4." Then fine-tune the mapping in the properties panel.

Common Pitfalls

Forgetting the high-water mark means every poll re-lists the same recent conversations and creates duplicate Monday.com items. Always record and reuse {{ lastPolledAt }}.
Monday.com's columnValues must be keyed by column ID, not by the column's display label. Run get-board once to capture the real IDs; a wrong key silently leaves the column blank.
Status and dropdown columns expect a specific shape (for example { "label": "High" }) and the label must already exist on the board, or the create call will be rejected.
Schedule cron runs in the timezone you set, not the viewer's. A workflow with Australia/Sydney will not line up with a UTC mental model; double-check the hour range when business hours matter.

Testing

Before enabling the schedule, narrow the Step 2 q query to a single test inbox and a recent window so list-conversations returns just a handful of conversations. Run the workflow with the Run button and open the execution log to confirm the Agent-mode node returns a clean object with a valid priority, the Condition routes as expected, and a Monday.com item appears on the right board with the score and a working Front link in its columns. Once a single conversation flows end to end and the tracking marker advances correctly, widen the query and turn the schedule on. See Understanding Execution Logs for reading run output.