How to Route Emailed Support Requests into Front Conversations with a Mailhook

Give your support team a dedicated intake address that turns every inbound email into a tagged Front conversation, with a Slack heads-up for urgent ones.

What This Integration Does

Many teams want a single forwarding address that customers, vendors, or internal systems can email so that requests land in one tidy place instead of scattered inboxes. This Spojit workflow gives you that address: a Mailhook trigger generates a unique intake email, and any message sent to it becomes a fresh conversation in your Front account. Each conversation is tagged automatically (for example, a triage tag plus a category tag) so teammates can filter, route, and report without manual sorting. You can also fan out a short notice to a Slack channel when a request looks high priority.

The workflow is push driven: the moment an email reaches the mailhook address, Spojit starts a run within seconds with no mailbox or polling involved. The email payload is exposed as {{ input }}, with fields such as {{ input.from }}, {{ input.subject }}, and {{ input.text }}. The run creates one Front conversation, applies tags, optionally posts to Slack, and then finishes. Mailhook runs are always asynchronous, so the sender gets no automatic reply unless you add a Send Email node; runs are deduplicated per message, so a forwarded duplicate of the same email does not create two conversations.

Prerequisites

A Front connection added in Spojit under Connections with a valid API token. See the Front connector article for setup.
At least one email-capable channel in Front, plus its channel ID. You will use it as the channelId when creating conversations.
The tag IDs you want to apply. Run the Front list-tags tool once (or check Front's tag settings) to capture the IDs for tags such as a triage tag and a category tag.
A Slack connection (optional) if you want urgent-request alerts, plus the target channel ID or name.
Permission in your Spojit workspace to create workflows and generate a mailhook address.

Step 1: Add the Mailhook trigger and generate the intake address

Create a new workflow, open the Trigger node, and set Trigger Type to Mailhook. Optionally set an Address prefix (1-24 characters, default mh); a value like support makes the address easy to recognize. Click Generate email address to mint a unique address of the form support-1a2b3c4d5e6f7g8h@mailhook.spojit.com, then copy it. Point your intake at this address: set up a forwarding rule from your existing support inbox, or share it directly with the systems that should reach the team. The trigger fires whether the address appears in To, Cc, or Bcc.

Step 2: Filter out noise before a conversation is created

Still in the Mailhook trigger, use the optional From allowlist and Subject regex filters so only real support mail starts a run. For an internal forwarding setup you might allow only your company domain; for a public address you can leave the allowlist open and instead use a subject pattern to skip auto-replies, for example a regex that excludes out of office or delivery status notification. Filtered emails are dropped before any node runs, which keeps your Front inbox and AI credits clean.

Step 3: Classify the request with a Connector node in Agent mode

Add a Connector node and switch it to Agent mode so Miraxa, the intelligent layer across your automation, can read the email and decide a category and urgency. In the prompt, hand it the message contents and ask for a structured verdict. Attach a Response Schema so the output is reliable JSON you can branch on. A prompt and schema like this work well:

Read this inbound support email and classify it.
From: {{ input.from }}
Subject: {{ input.subject }}
Body: {{ input.text }}

Return category (one of: billing, technical, sales, other)
and urgency (low, normal, high).

{
  "type": "object",
  "properties": {
    "category": { "type": "string", "enum": ["billing", "technical", "sales", "other"] },
    "urgency": { "type": "string", "enum": ["low", "normal", "high"] }
  },
  "required": ["category", "urgency"]
}

Save the result to an output variable such as triage so later steps can read {{ triage.category }} and {{ triage.urgency }}. If you prefer a deterministic, no-AI path, you can skip this step and tag every conversation the same way instead.

Step 4: Create the Front conversation with a Connector node in Direct mode

Add a Connector node, select your Front connection, and in Direct mode pick the send-message tool. Sending a message from a channel opens a new conversation in that channel's inbox. Map the fields:

channelId: the ID of your support email channel.
to: the original sender, as a single-item list, so replies thread back to them, for example ["{{ input.from }}"].
subject: reuse the incoming subject, such as {{ input.subject }}.
body: the email contents. HTML is supported, so you can pass {{ input.html }}, or fall back to {{ input.text }} for plain messages.

Save the response to a variable like conversation. The created conversation's ID is available downstream for tagging, for example {{ conversation.id }}.

Step 5: Apply tags to the new conversation

Add another Connector node on the Front connection in Direct mode and choose the add-tag tool. Map conversationId to the ID from the previous step (for example {{ conversation.id }}) and pass tag_ids as a list of the tag IDs you captured earlier. To apply both a fixed triage tag and a dynamic category tag, build the list from your triage output, for example:

["tag_triage_id", "{{ triage.category_tag_id }}"]

If you prefer to keep the mapping simple, store a small lookup of category-to-tag IDs in a Transform node and feed its result into tag_ids. Tags now show up in Front for filtering and reporting.

Step 6: Alert Slack when a request is urgent

Add a Condition node that checks {{ triage.urgency }} equals high. On the true branch, add a Connector node on your Slack connection in Direct mode using the send-message tool. Set the target channel and a short, templated message so the team can jump in quickly:

:rotating_light: Urgent support request from {{ input.from }}
Subject: {{ input.subject }}
Category: {{ triage.category }}

The false branch can simply end the workflow. If you would rather notify by email instead of Slack, drop in a Send Email node and address it to your team; remember external recipients must be on your org allowlist under Settings > General > Email recipients.

Tips

Use a recognizable Address prefix like support so the mailhook address is easy to spot in forwarding rules and logs.
If the same vendor address needs different handling, keep one mailhook workflow per intake purpose rather than overloading a single address with complex subject regexes.
Ask Miraxa to scaffold the canvas for you with a prompt like "Build a workflow that watches a mailhook, creates a Front conversation from the email, and posts urgent ones to Slack," then fine-tune each node in the properties panel.
Tag IDs are stable but tag names can change in Front; reference tags by ID in add-tag so renames do not break your workflow.

Common Pitfalls

Passing tag names instead of tag IDs to add-tag. The tag_ids field expects IDs; fetch them with list-tags first.
Forgetting that the mailhook is asynchronous. The sender receives no reply by default, so add a Send Email node addressed to {{ input.replyTo }} if you want to acknowledge receipt.
Wrapping the recipient incorrectly. The Front send-message to field expects a list, so use ["{{ input.from }}"], not a bare string.
Regenerating the address by accident. Regenerate address rotates the mailhook and the old address dies instantly, so any forwarding rule pointed at the old value stops delivering.

Testing

Before forwarding live support mail, send a single test email to the generated mailhook address from an allowed sender and watch the run appear in your execution history within a few seconds. Confirm that one Front conversation was created in the right inbox, that it shows the expected triage and category tags, and that an urgent test subject produced a Slack message while a normal one did not. Inspect {{ input }} in the run details to verify the fields you mapped, then point a single forwarding rule at the address and process a handful of real emails before turning the rule on for the whole inbox.