How to Draft Personalized Customer Replies from a Knowledge Base and Hold for Approval

Build a Spojit workflow that catches an inbound support email, drafts an accurate reply grounded in your own knowledge collection, pauses for a human approver, then sends the answer from your own domain over SMTP.

What This Integration Does

Support teams want fast replies that are also correct. A draft written from memory can contradict your refund policy or quote the wrong shipping window. This workflow keeps answers grounded by querying a persistent Knowledge collection (your help docs, policies, and FAQs) before composing a single word, so every reply is built from the source of truth you embedded. Because a teammate approves each draft before it leaves, you keep a human in the loop while still removing the slow part of the work: research and first-draft writing.

The workflow runs once per inbound email. An Email trigger polls your connected mailbox and starts a run when a new message lands. Spojit pulls the relevant passages from your collection, an Agent-mode Connector node drafts a reply that cites only what was retrieved, and the run then pauses at a Human node. Nothing is sent until an approver acts. When approved, a Connector node sends the reply over the SMTP connector from your real support address. Each inbound email is a separate run, so re-running one message never resends another, and a rejected draft halts that run without sending anything.

Prerequisites

A connected Gmail (trigger) or Outlook (trigger) mailbox for your support inbox, added under Connections → Add connection. Read-only access is enough for this workflow.
An SMTP connection configured with your outbound mail server host, port, and credentials, so replies send from your own support address.
A persistent Knowledge collection that already holds your support content (policies, FAQs, product docs). Create it in the Knowledge section of the sidebar and upload documents before you build this workflow. Note which embedding model the collection uses.
At least one teammate, role, or team to assign as an approver in the Human node.
If your support address sends to external recipients, confirm outbound is allowed by your SMTP provider for that from-address.

Step 1: Start the workflow with an Email trigger

Add a Trigger node and set its type to Email. Pick your connected support mailbox, choose the folder to watch (typically the inbox), and set a poll interval between 1 and 60 minutes (default is 2). To avoid drafting replies to noise, add an optional From allowlist or a Subject regex so only genuine customer mail starts a run. The trigger output gives you the fields you will template downstream, including {{ subject }}, {{ from }}, {{ textBody }}, and {{ conversationId }}. Leave any after-processing actions (mark read or move) off for now while you test.

Step 2: Query your knowledge collection for grounding

Add a Knowledge node set to Query mode. In Collection, pick your persistent support collection (not Transient: you want the long-lived archive that every workflow can read). For Prompt, pass the customer's question so the retrieval targets their actual issue:

The customer wrote:
Subject: {{ subject }}
{{ textBody }}

Find the policies and FAQ passages needed to answer this accurately.

Set Result Count to about 5 (raise it for broad questions, lower it for crisp ones), choose the Model that synthesizes the answer, and assign an Output Variable, for example kb. The node returns an answer grounded in the retrieved chunks, available downstream as {{ kb }}. Make sure this collection was embedded with the same embedding model it now queries with, or retrieval quality drops.

Step 3: Draft the reply with an Agent-mode Connector node

Add a Connector node in Agent mode so the agent can compose a polished, on-brand reply from the grounded answer. Give it a Response Schema to force clean JSON you can template later, for example fields subject and body. Use a prompt that hard-bounds the draft to what the knowledge query returned:

Write a friendly, concise reply to this customer.
Use ONLY the facts in the grounded answer below. If the answer
is not covered, say a teammate will follow up; do not guess.

Customer subject: {{ subject }}
Customer message: {{ textBody }}

Grounded answer from our knowledge base:
{{ kb }}

Assign an Output Variable such as draft. You will reference {{ draft.subject }} and {{ draft.body }} in the approval message and the send step. Keeping the draft strictly bounded to {{ kb }} is what prevents confident but wrong answers.

Step 4: Pause for a human approver

Add a Human node so no reply leaves without sign-off. Set a clear Label (for example Approve support reply) and a Message that shows the approver exactly what will be sent, using upstream variables:

Reply to {{ from }} re: {{ subject }}

{{ draft.body }}

Set Urgency to Normal or High, and add a Timeout (minutes) if you do not want drafts waiting indefinitely (leave blank for no timeout). Fill in Approval slots (the only required field): add a slot and place a User, Role, or Team atom in it. Any atom satisfies its slot, and approval completes when every slot is satisfied. Turn on Email approvers if you want the first ten approvers emailed directly. Approvers act in the Approvals inbox at /approvals. On approval the run continues; on rejection or timeout it halts and nothing is sent, so this node is your safety gate. Branching to a different path on rejection is not supported: a reject simply stops the run.

Step 5: Send the approved reply over SMTP

Add a Connector node in Direct mode, choose your SMTP connection, and pick the send-email tool. Map the inputs from the customer email and the approved draft so the reply goes back to the original sender from your own domain:

to:      {{ from }}
subject: Re: {{ subject }}
body:    {{ draft.body }}

Because this runs only after the Human node approves, every message that reaches send-email has been reviewed. Using the SMTP connector (rather than the built-in Send Email node) means the reply is sent from your real support address, which keeps the conversation threaded in the customer's mailbox and matches your branding. If you would rather route the answer back through your shared inbox tool instead of plain SMTP, use a Front connector node with the send-message tool, mapping to, body, and subject onto the relevant channel.

Step 6: Confirm delivery before exposing the run more widely

Add a final Connector node in Direct mode on the SMTP connection using the verify-connection tool the first time you build, so you confirm the outbound server accepts your credentials before any customer sees a reply. Once verified, you can remove this step or keep it as a periodic health check in a separate test workflow. With delivery confirmed, return to the Email trigger and, if you want processed mail marked or moved, enable that after-processing option (it requires read-and-modify access on the mailbox connection).

Tips

Keep the knowledge collection and its query on the same embedding model. Mixing models silently degrades retrieval, so the draft loses accuracy.
Raise Result Count for multi-part questions and lower it for simple ones. More chunks help coverage but can dilute focus.
Put the full draft in the Human node Message so approvers can decide without leaving the Approvals inbox.
If you want approvers nudged immediately, enable Email approvers and set Urgency to High for time-sensitive queues.

Common Pitfalls

Forgetting the From allowlist or Subject regex on the trigger means newsletters and auto-replies start runs and burn approver attention. Filter at the trigger.
A rejected or timed-out approval halts the run with no send and no alternate branch. Do not design a "rejected" path: reject means stop.
Letting the draft step pull from general knowledge instead of {{ kb }} reintroduces guesswork. Bind the agent prompt strictly to the grounded answer.
Sending to external recipients can be blocked by your outbound mail server policy. Verify your SMTP from-address is permitted before going live.

Testing

Before enabling the workflow, send a test email to your support mailbox that matches your trigger filters and asks a question your collection clearly covers. Watch the run pause at the Human node, open the Approvals inbox at /approvals, and read the drafted reply in the message. Check that it cites only facts present in your knowledge collection. Approve it and confirm the email arrives from your support address with the correct Re: subject and threaded into the original conversation. Then reject a second test draft to confirm the run halts and no email is sent. Once both paths behave, widen the trigger filters and turn on after-processing.