How to Send Customer Satisfaction Surveys After a Front Conversation Closes

When a Front conversation is resolved, this Spojit workflow looks up the contact and sends a personalized CSAT survey email through Resend within seconds.

What This Integration Does

Customer satisfaction surveys land best when they arrive right after the support interaction ends, while the experience is fresh. This workflow watches Front for conversations that move into an archived (resolved) state, pulls the full conversation and the contact behind it, then emails that customer a short CSAT survey from your own domain through Resend. You get consistent, timely feedback collection without anyone on the team remembering to send a survey by hand.

The run model is event-driven. Front posts a webhook to Spojit each time a conversation is updated; a Webhook trigger receives the payload, a Condition node confirms the conversation actually closed, and only then does the workflow fetch details and send mail. Each resolved conversation produces exactly one survey email. The workflow leaves no state behind in Spojit beyond the execution record, so re-runs are safe as long as you guard against duplicate webhook deliveries (covered under Common Pitfalls).

Prerequisites

A Front connection in Spojit (Connections -> Add connection -> Front) with access to read conversations and contacts.
A Resend connection with a verified sending domain and a default from address configured on the connection (for example Support <support@yourdomain.com>).
A rule in Front (Settings -> Rules) that sends a webhook to your Spojit workflow URL when a conversation is archived or its status changes.
A signing connection for the Webhook trigger so deliveries are verified by HMAC. Use the Custom scheme with the shared secret you set on the Front rule.
The CSAT survey destination: a hosted survey link or a set of rating links you want to embed in the email body.

Step 1: Receive the Front webhook

Add a Trigger node and set its type to Webhook. Copy the generated workflow URL into your Front rule so Front posts conversation events to it. Under the trigger's signing connection, pick the Custom scheme and reference the secret shared with Front so each delivery is verified by HMAC before the workflow runs. The trigger output is the parsed JSON body, available downstream as {{ input }}. A typical Front conversation event looks like this:

{
  "type": "archive",
  "conversation": {
    "id": "cnv_55c8c149",
    "status": "archived",
    "subject": "Refund question",
    "recipient": { "handle": "jordan@example.com" }
  }
}

The shape of Front's payload varies by event type, so do not rely on every field being present. The two values this workflow needs are the conversation id and the status.

Step 2: Confirm the conversation actually closed

Add a Condition node so the survey only fires for genuinely resolved conversations. Configure the condition to check that {{ input.conversation.status }} equals archived (Front's resolved state). Route the true branch into the rest of the workflow and leave the false branch empty so reopened, assigned, or spam updates are ignored. This single gate keeps you from emailing a customer mid-thread every time Front touches the conversation.

Step 3: Fetch the full conversation from Front

Add a Connector node in Direct mode, choose the Front connector, and select the get-conversation tool. Map its id input to {{ input.conversation.id }}. Direct mode is the right choice here because this is a single, predictable lookup with no AI cost. Store the result in an output variable such as conversation. The response gives you the conversation subject, status, recipient handle, and related metadata you will reference when composing the survey.

Step 4: Look up the contact

Front's contacts hold the customer's name and email handle, which you need for personalization. Add a second Connector node in Direct mode on the Front connector. If your Front payload includes a contact id, use get-contact with its id input. If you only have the recipient email handle, use list-contacts instead and pass the handle to the q search input:

{
  "q": "{{ conversation.data.recipient.handle }}"
}

Save the result to a variable such as contact. From there you can read the contact's name for the greeting and the email handle for the recipient address. If a conversation has no contact on file, fall back to the recipient handle from Step 3.

Step 5: Build the personalized survey email

Add a Transform node to assemble the values the email needs in one place: the recipient address, a friendly first name, the conversation subject, and the survey link with the conversation id appended for tracking. Keeping this in a Transform node makes the Resend step clean and easy to read. Produce an object like:

{
  "to": "{{ conversation.data.recipient.handle }}",
  "firstName": "{{ contact.data.name }}",
  "subject": "How did we do? Your recent support request",
  "surveyUrl": "https://survey.yourdomain.com/csat?ref={{ input.conversation.id }}"
}

Store the result in a variable such as survey. If you prefer, Miraxa, the intelligent layer across your automation, can scaffold this Transform node for you from a sentence describing the fields you want, then you fine-tune it in the properties panel.

Step 6: Send the survey through Resend

Add a Connector node in Direct mode, choose the Resend connector, and select the send-email tool. Map the inputs from your survey variable. Leave from blank to use the default from address on the Resend connection, or set it explicitly to send from a specific address on your verified domain. Provide both an html body and a text body so every mail client renders cleanly, and set reply_to to your support address so replies land back in Front.

{
  "to": "{{ survey.to }}",
  "subject": "{{ survey.subject }}",
  "html": "<p>Hi {{ survey.firstName }},</p><p>Thanks for reaching out about \"{{ conversation.data.subject }}\". How did we do?</p><p><a href=\"{{ survey.surveyUrl }}\">Rate your experience</a></p>",
  "text": "Hi {{ survey.firstName }},\n\nThanks for reaching out. Rate your experience: {{ survey.surveyUrl }}",
  "reply_to": "support@yourdomain.com"
}

Resend returns a confirmation containing the sent email id, which you can keep in an output variable for your records. Sending through the Resend connector (rather than the built-in Send Email node) is what lets the survey go out from your own domain with your branding and deliverability reputation.

Tips

Front rules can be scoped to specific inboxes or teams. Point the rule at only the inboxes that should trigger surveys so internal or automated conversations never generate one.
Add the conversation id to the survey URL (as shown) so each response ties back to a specific interaction when you analyze results later.
Use a custom signing connection secret on the Webhook trigger that matches the secret on the Front rule. HMAC verification rejects any payload that is not genuinely from Front.
If you want to skip surveys for very short or auto-closed conversations, add a second Condition after Step 3 that checks the conversation has at least one inbound message before sending.

Common Pitfalls

Webhook replays. Front may deliver the same archive event more than once. Enable opt-in dedup on the Webhook trigger using an event-id header so a single resolved conversation does not send two surveys.
Status assumptions. Not every Front update is a close. Without the Condition gate in Step 2, the workflow would email customers on assignment, tagging, and reopen events too.
Missing contact data. A conversation may have no contact record or a blank name. Always provide a fallback greeting and fall back to the recipient handle for the address so the email still sends.
Unverified Resend domain. If the Resend sending domain is not verified, sends fail. Verify the domain in Resend and confirm a default from address is configured on the connection before going live.

Testing

Before enabling the rule for all inboxes, scope the Front rule to a single test inbox and resolve one test conversation addressed to your own email. Watch the run in Spojit's execution history: confirm the Condition took the true branch, that get-conversation and the contact lookup returned the expected fields, and that the Transform output matches what you want in the email. Verify the survey lands in your inbox, renders correctly, and that the survey link carries the right conversation id. Once a handful of test sends look right, widen the Front rule to the inboxes you want covered.