How to Centralize Fan Community Messages from Front into a Slack Channel

Build a scheduled Spojit workflow that pulls your open fan conversations from Front, has an agent summarize the themes and flag anything urgent, and posts a tidy digest to a Slack community channel so you triage your whole inbox in one glance.

What This Integration Does

As a creator your fan messages, brand questions, and support requests land in a shared Front inbox, and it is easy to lose the thread when dozens of conversations pile up between studio sessions. This workflow watches that inbox on a schedule, gathers every open conversation, and turns the raw list into a short readable digest: the top themes fans are talking about, how many threads are still open, and a short list of anything that looks urgent or time-sensitive. Instead of scrolling Front yourself, you get a single Slack post that tells you where to spend the next ten minutes.

The workflow runs on a Schedule trigger (for example twice a day on weekdays), so there is nothing to click. On each run it lists open conversations from your Front inbox with the front connector, a Transform node trims that list to just the fields the agent needs, an Agent-mode Connector node reads the trimmed list and produces a structured summary, and the slack connector posts the digest into your community channel. Each run is read-only against Front (it does not change or close any conversation), so re-runs are safe: the worst case of running twice is two digests. State lives only in Front and Slack; Spojit keeps the execution history of each digest so you can look back at what was reported.

Prerequisites

A front connection in Spojit (API token) with access to the inbox that holds your fan conversations. See the Front connector reference.
A slack connection in Spojit authorized for the workspace and able to post to your community channel. See the Slack connector reference.
The exact Slack channel name or ID you want the digest posted to (for example #fan-community).
AI credits available, since the summary step runs in Agent mode. See Managing Credits.
Optional: knowing your Front search syntax (it supports filters like is:open) so you can scope which conversations get pulled.

Step 1: Add a Schedule trigger

Start a new workflow and set the Trigger node type to Schedule. The Schedule trigger uses a 5-field Unix cron expression plus an IANA timezone. For a twice-daily weekday digest at 9am and 4pm, add two schedules:

0 9 * * 1-5    Australia/Sydney
0 16 * * 1-5   Australia/Sydney

A single trigger can hold multiple schedules, so both entries fire the same workflow. The trigger output is {{ scheduledAt }}, which you can reference later if you want the digest to show the run time.

Step 2: List open fan conversations from Front

Add a Connector node in Direct mode on the front connector and choose the list-conversations tool. This is a deterministic, single-tool call (no AI cost), which is exactly what you want for fetching a list. Set the search field q to scope the pull to open threads:

q: "is:open"

Front returns conversations along with a pagination token at _pagination.next. If your inbox is busy and one page is not enough, use the page_token input on a follow-up list-conversations call (inside a Loop node) to page through, or keep it to the first page for a lightweight digest. Name this node's output something clear like conversations so you can reference {{ conversations }} downstream.

Step 3: Trim the list with a Transform node

Add a Transform node to reshape the Front response into a compact list before it reaches the agent. Sending the full conversation objects wastes AI credits, so keep only the fields that matter for a digest: subject, status, last-message time, and assignee. Produce an array like this:

[
  { "subject": "{{ item.subject }}",
    "status": "{{ item.status }}",
    "updated": "{{ item.last_message.created_at }}",
    "assignee": "{{ item.assignee.username }}" }
]

Name the output trimmed. This step also gives you a clean count: the length of {{ trimmed }} is your "open conversations" number for the digest header.

Step 4: Summarize and flag urgency with an Agent-mode Connector node

Add a Connector node in Agent mode. This is the AI step that runs inside the workflow: the agent reads {{ trimmed }}, groups the conversations into themes, and decides which ones look urgent. Give it a clear prompt:

You are triaging a creator's fan inbox. Here is the list of open
conversations: {{ trimmed }}.
Group them into 3-5 themes with a count each. List any conversation
that looks time-sensitive (refunds, shipping problems, brand-deal
deadlines, anything angry) under "urgent". Keep it short.

Turn on a Response Schema so the output is reliable JSON you can drop straight into Slack, for example:

{
  "type": "object",
  "properties": {
    "themes": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "label": { "type": "string" },
          "count": { "type": "integer" }
        }
      }
    },
    "urgent": { "type": "array", "items": { "type": "string" } },
    "headline": { "type": "string" }
  }
}

Name the output digest. Tip: you can scaffold this whole workflow by describing it to Miraxa, the intelligent layer across your automation, then fine-tune the prompt and schema here in the properties panel.

Step 5: Post the digest to your Slack community channel

Add a Connector node in Direct mode on the slack connector and choose the send-message tool. Set the channel to your community channel and build the message text from the agent's structured output. A simple templated body looks like this:

channel: "#fan-community"
text: |
  *Fan inbox digest - {{ scheduledAt }}*
  {{ digest.headline }}

  Open themes:
  {{ digest.themes }}

  Needs attention:
  {{ digest.urgent }}

Because send-message is a Direct-mode call, posting is deterministic and costs no AI credits. If you want richer formatting you can loop over {{ digest.themes }} with a Loop node and build the lines yourself, but a single message is usually all a creator needs.

Step 6: Optionally email yourself the same digest

If you also want the summary in your inbox (handy when you are away from Slack), add a Send Email node after the Slack step. It sends from Spojit's built-in mail service with no extra connection. Set Recipients to your own address, a templated Subject like Fan inbox digest - {{ scheduledAt }}, and put {{ digest.headline }} and {{ digest.urgent }} in the Body. Note that recipients must be on your org allowlist under Settings > General > Email recipients, and the send counts toward your monthly email allowance. To send from your own creator domain instead, swap in a Connector node on the resend or smtp connector with send-email.

Tips

Keep the agent input small. The Transform node in Step 3 is what keeps AI cost low: feed the agent a short list of subjects and statuses, not the full Front payload.
Tune the schedule to your rhythm. A single Schedule trigger can hold several cron entries, so you can add a Monday-morning catch-up run without building a second workflow.
Use the Response Schema. Forcing structured JSON from the Agent-mode node means your Slack template never breaks on free-form text, and you can reuse the same digest object for both Slack and email.
If your inbox is large, page through with page_token inside a Loop node so the digest reflects every open thread, not just the first page.

Common Pitfalls

Wrong timezone. The Schedule trigger uses IANA timezones, so set Australia/Sydney (or your zone) explicitly; leaving it at a default can post the digest at the wrong hour.
Front search scope. If q: "is:open" returns more or fewer threads than expected, check that the Front connection has access to the right inbox and that your search syntax matches what Front shows in its own search bar.
Slack channel reference. The send-message call needs a channel the Slack connection can post to; a private channel the connection has not been invited to will fail. Invite the connection to the channel first.
Email allowlist. A Send Email step silently goes nowhere if the recipient is not on the org allowlist, so add your address under Settings > General > Email recipients before relying on it.

Testing

Before turning on the schedule, validate the flow on a small scope. Temporarily point the Slack step at a private test channel and narrow the Front pull (for example add a stricter q filter so only a handful of conversations come back), then run the workflow with the Run button and watch the execution history. Confirm the Front list looks right, the Transform output is the trimmed array you expect, the Agent-mode node returns JSON matching your Response Schema, and the Slack post renders cleanly. Once the test channel looks good, switch the channel back to your real community channel and let the Schedule trigger take over. If a run ever looks off, ask Miraxa "Why did my last run fail?" to investigate it in context.