Detecting Candidate Intent with the If Node
The workflow begins when a chat webhook receives a new message from a candidate. The Detect Intent node uses an if condition to evaluate the incoming text. A common approach is to inspect specific keywords or phrases that indicate the applicant's goal. For example, if the message contains the word "resume" or "CV", the condition routes to the resume‑handling branch. If the message mentions "schedule" or "interview", it follows a different path. This branching happens immediately after the webhook trigger, ensuring that every incoming chat is classified before any further processing occurs.
At a glance
- Built for: recruiters
- Difficulty: beginner
- Starts with: Chat Webhook Trigger (webhook)
- Steps: 5 nodes
- Tools: n8n, HTTP request service, Chat platform API
When the if condition evaluates to true for a particular intent, the workflow proceeds to the next node. If none of the defined patterns match, the false branch can direct the message to a fallback response or a human reviewer. The if node does not alter the message content; it only decides which subsequent node will execute. This design keeps the logic explicit and makes it easy to add new intent patterns without restructuring the entire flow.
Routing to the Correct API Based on Intent
Once the intent is identified, the Route to API node is called to perform the required action. This HTTP request node sends a POST or GET call to an external service, depending on what the recruiter needs. For a resume‑related intent, the request might target a candidate‑profile API to store or update a CV. For a scheduling intent, the request could hit a calendar‑integration endpoint to propose available time slots.
The HTTP Request node is configured with the appropriate endpoint URL, headers, and body. Often the body includes dynamic values extracted from the original chat message, such as the candidate’s name or email address. The response from the API is then passed forward to the next node. If the external service returns an error, the workflow can follow a separate path to log the failure or notify the recruiter. This step ensures that the correct system of record is updated for each type of candidate interaction.
Formatting the Response for the Chat Platform
After the API call completes, the Format Response node prepares a structured payload that the chat platform can display. The Set node constructs a JSON object with fields such as "type", "content", and any quick‑reply buttons the recruiter wants to offer. For instance, if the API returned a list of open positions, the Set node might format that list into a concise markdown string.
The formatting step also handles conditional text. If the API returned no results, the node can insert a polite message like "No matching profiles found at this time." The node’s output is a plain object that the final Respond to Webhook step will consume. Keeping the response format consistent across all intents makes the chatbot behavior predictable for both the recruiter and the applicant.
Replying to the Chat Channel
The final step in the core workflow is Reply to Chat, which sends the formatted payload back to the original chat platform. The Respond to Webhook node takes the output from the Set node and transmits it as a message in the same conversation thread. This closes the loop: the candidate receives a relevant reply without any manual intervention from the recruiter.
If the workflow encounters an unexpected situation—such as the API being unreachable— the Respond to Webhook node can output a default message like "We’re having trouble processing your request right now. Please try again later." This ensures that every incoming message gets a response, even when things go wrong.
Extending the Workflow
Add a CRM branch – Insert an additional if condition after the intent check to detect when a candidate expresses interest in a specific role. Route that branch to an HTTP Request node that updates a CRM record with the candidate’s ID and preferred job title. The Set node then appends a tag to the chat response, such as "Noted interest in Senior Engineer role."
Move API logic into a sub‑workflow – If the routing logic becomes complex, extract the Route to API and Format Response steps into a separate sub‑workflow. The main flow calls the sub‑workflow via the Execute Workflow node, passing the intent type as a parameter. This keeps the primary diagram clean and allows the API‑specific steps to be version‑controlled independently.
Swap the messaging service – Replace the Respond to Webhook node with a different chat integration, such as a Slack or Microsoft Teams node. Configure the new node with the same structured payload, ensuring the channel ID and formatting match the target platform. The rest of the workflow remains unchanged, only the delivery endpoint shifts.
Key takeaways
- The if node classifies every incoming message before any action is taken.
- The HTTP request node updates the correct system of record based on the detected intent.
- The Set and Respond to Webhook nodes ensure a consistent reply is sent back to the candidate.
Before you import it
- A running n8n instance (cloud or self-hosted).
- n8n account
- Chat platform credentials
- API endpoint access
- Sample data to test with, before pointing it at real records.
Get the free workflow
The importable JSON for Recruitment Intent Router is free to download: https://lanexbuilds.com/entry?id=recruitment-intent-router
This workflow was generated with AI assistance. Test it with sample data before using it on real data.
Cover photo by kirill_makes_pics on Pixabay
Top comments (0)