Browse 12,955 Workflows

By Oneclick AI Squad

Quick Overview This workflow accepts a task via webhook (or manual run) and uses Anthropic Claude as a supervisor to route work across specialist agents (researcher, coder, analyst, writer, reviewer). It iterates until completion, then synthesizes a final answer, returns it to the caller, and sends a WhatsApp summary. How it works Receives a POST request via an n8n webhook (or starts from a manual trigger) and normalizes the input into a task state with a step counter and work history. Validates that a non-empty task is provided and immediately returns a 400 webhook response if the request is invalid. Builds a supervisor prompt and calls the Anthropic Messages API (Claude) to decide the next specialist route and instruction, enforcing guardrails like max steps, loop detection, and error fallback. Routes to exactly one specialist Claude call (researcher with web search, coder, analyst, writer, or reviewer) and generates output based on the supervisor’s instruction. Records the specialist result into a shared work log, increments the step counter, and repeats the supervisor routing loop until the route is FINISH or a guardrail ends the run. Sends the accumulated specialist work to Claude for final synthesis, then returns the final answer and routing trace in the webhook response and sends a truncated summary via WhatsApp. Setup Create an Anthropic HTTP Header Auth credential (x-api-key) and select it on all Anthropic HTTP Request nodes (supervisor, five specialists, and synthesis). Add WhatsApp Business credentials for the WhatsApp node and set your WhatsApp phone number ID and recipient phone number in the configuration values. Update the configuration values for the Anthropic API URL and the supervisor/specialist models and step limits to match your desired defaults. Copy the webhook URL for the “agent-supervisor-task” endpoint and configure your client to POST JSON such as {"task":"…","context":"…","maxSteps":5}. An n8n automation workflow template by Oneclick AI Squad.

By Oneclick AI Squad

Quick overview This workflow provides persistent AI agent memory by combining Redis session history, PostgreSQL + pgvector long-term storage, Voyage AI embeddings, and Anthropic Claude for chat and memory extraction, with webhooks for chat and forgetting memories plus a daily maintenance schedule. How it works Receives a chat message via a webhook (or manual trigger), validates userId/sessionId/message, and loads configuration. Loads recent conversation turns from Redis and retrieves a cached query embedding from Redis or generates one via the Voyage AI embeddings API and stores it back in Redis. Runs a pgvector similarity search in PostgreSQL for the user’s stored memories, re-ranks results by similarity/importance/recency, and updates access statistics for retrieved memories. Sends the recent turns plus retrieved memory context to Anthropic Claude to generate a reply and returns the reply to the webhook caller. In the background, saves the updated session history to Redis, asks Anthropic Claude to extract new durable memories from the exchange, embeds them with Voyage AI, and upserts them into PostgreSQL while deduplicating near-duplicates. Runs once per day to decay the importance of unused memories and prune expired or low-importance stale memories from PostgreSQL. Receives a forget request via a webhook to delete one memory (by UUID) or all memories for a user in PostgreSQL and clears the corresponding Redis session. Setup Provide PostgreSQL credentials and enable the pgvector extension, then run the one-time schema setup described in the template notes to create the agent_memories table with the correct embedding vector dimension. Provide Redis credentials for storing per-user session history and the embedding cache. Add HTTP Header Auth credentials for Anthropic (x-api-key) and for the embeddings provider (Authorization: Bearer …), and select them in the Claude and embedding HTTP Request steps. Update the configuration values (models, embedding URL/model/dimensions, TTLs, retrieval thresholds, and dedupe similarity threshold) to match your providers and desired behavior. Copy the chat and forget webhook URLs and secure them (for example with header authentication) before connecting your client application, ensuring userId is supplied by a trusted caller. An n8n automation workflow template by Oneclick AI Squad.

By Oneclick AI Squad

Quick overview This workflow ingests incidents from a schedule, an intake webhook, or a manual test trigger, gathers monitoring metrics and recent deploy history, uses Anthropic Claude to triage and plan remediation, posts approval requests and status updates to Slack, logs outcomes to an incident manager API, and sends a final digest. How it works Runs on a schedule, via an incident intake webhook, or from a manual trigger, and normalizes the incoming incident payload. Builds an incident processing queue either from the provided incident details or by fetching open incidents from an incident manager API. For each queued incident, retrieves a recent metrics snapshot from a monitoring API and recent deployment data from a CI/CD or deploy-history API. Sends the diagnostics to Anthropic Claude to generate a triage assessment, then asks Claude to propose a single runbook remediation action and risk level. If the proposed action is medium/high risk or exceeds the auto-remediation severity threshold, posts an approval request to Slack and marks the remediation as pending. If approval is not required, executes the runbook action via a runbook engine API and records the execution result. Uses Anthropic Claude to draft a stakeholder status update, posts it to Slack, logs the full incident outcome to the incident manager API, and repeats until the queue is empty before posting a final digest to Slack and returning it via the webhook response. Setup Add HTTP Header Auth credentials for your monitoring API, deploy-history API, incident manager API, Slack incoming webhooks, your runbook engine API, and the Anthropic API. Update the configuration values for monitoringMetricsUrl, deployHistoryUrl, openIncidentsUrl, incidentUpdateUrl, runbookExecuteUrl, Slack webhook URLs, and the Anthropic model to match your environment. Configure the schedule trigger interval and share the incident intake webhook URL with your alerting system if you want incidents pushed in. Share the approval callback webhook URL with your approval UI or Slack workflow so approvers can submit approved/declined decisions with incidentId, action, and approved status. Review and tune autoRemediateMaxSeverity and maxIncidentsPerRun to match your incident policy and desired per-run limits. An n8n automation workflow template by Oneclick AI Squad.

By Swapnil Mandloi

Quick overview Receives cold-chain excursion telemetry via webhook, enriches it via an external stability API, and uses OpenAI to extract facts and draft disposition rationales. It routes lots for release, review, quarantine, or disposal while archiving evidence to Google Drive, logging to Google Sheets, and alerting via Telegram and Gmail. How it works Receives a POST webhook with lot and sensor time-series readings for a cold-chain excursion. Sends the incoming payload to an external stability-envelope API to retrieve validated handling limits and supporting context. Uses OpenAI to extract evidence-backed excursion windows and handling anomalies from the combined record. Calculates a thermal-debt-based risk score from the temperature readings and assigns a disposition route (conditional release, QA review, or quarantine). If the risk score meets the quarantine threshold, creates a deviation/quality case in an external QMS API; otherwise waits 30 minutes to allow additional QA evidence to arrive. Uses OpenAI to draft a disposition rationale, then flags lots at or above the destroy threshold for leadership attention via Telegram and archives the final evidence JSON to Google Drive. Appends an audit row to a Google Sheets log and emails the full disposition package via Gmail. Setup Create the inbound webhook endpoint by activating the workflow and configure your IoT/telemetry source to POST to the generated /cold-chain-excursion URL. Add OpenAI credentials for the information extraction and rationale drafting steps (model is set to gpt-5-mini). Replace the placeholder API URLs (api.example.com) and configure authentication for your stability-envelope service and QMS/deviation system. Connect Google Drive and set the target folder ID, then connect Google Sheets and replace the spreadsheet ID (and ensure a “Cold Chain Dispositions” sheet exists). Connect Telegram and set the chat ID, then connect Gmail and update the recipient address used for the release package email. Requirements OpenAI API Key: Connect your OpenAI credentials to both the Provide Extraction Model and Provide Drafting Model nodes. QMS & Stability API Credentials: Provide Header Auth or API keys in the Fetch Stability Envelope and Create Quality Case HTTP Request nodes. Google Workspace Accounts: Connect Google Drive OAuth credentials for the Archive Excursion Evidence node and Google Sheets credentials for the Log Disposition Audit node. Notification Accounts: Set up Gmail OAuth credentials on the Email Release Package node and Telegram bot credentials on the Alert Quality Leadership node. Webhook Ingestion Source: An IoT gateway, data logger service, or test script configured to POST temperature telemetry JSON to the Receive Excursion Telemetry webhook endpoint. Customization Thermal Debt Calculation: Adjust the kinetic degradation formula, activation energy ($E_a$), and MKT thresholds inside the Compute Thermal Debt Score code node to match product stability data.Quarantine & Disposal Thresholds: Modify numerical cut-offs in the Check Immediate Quarantine and Check Destroy Threshold nodes based on your standard operating procedures (SOP).Investigation Hold Window: Adjust the duration in the Wait for QA Evidence Window node to align with internal deviation review timelines.Alternate Notification Channels: Replace Telegram and Gmail with Slack, Microsoft Teams, or PagerDuty for leadership alerts.Enterprise QMS Integration: Replace the sample REST endpoints with dedicated API connectors for platforms like Veeva Vault, TrackWise, or Jira. Additional info Built-in Resilience: External API, LLM, and cloud storage nodes are configured with 3 retries (2-second interval) and continue on fail to preserve evidence traces. Audit-First Design: Generates a structured audit trail across both Google Sheets and Google Drive, capturing raw telemetry alongside AI rationale. Deterministic Decision Guardrails: Immediate quarantine and destruction routing rely entirely on hard mathematical logic; AI models are strictly scoped to telemetry summarization and narrative drafting. Input Payload Format: Expects a JSON object containing lot metadata, lane details, and time-series sensor readings (lot_id, product_id, temperature_readings, etc.). An n8n automation workflow template by Swapnil Mandloi.

By Swapnil Mandloi

Quick overview This workflow monitors a Gmail label for donor screening questionnaire emails, extracts AABB-style risk flags with OpenAI, calculates the effective donor deferral and component release status via a linked sub-workflow, then logs the decision to an n8n Data Table and notifies a lab supervisor on Telegram. How it works Triggers when a new email arrives in Gmail under the DONOR_QUESTIONNAIRE label. Extracts donor_id, component_id, donation_type, questionnaire text, and a screening timestamp, then fetches the donor’s prior deferral history from an external donor registry API. Uses OpenAI (GPT-4.1-mini) to extract a structured list of predefined donor risk flags from the questionnaire text. Processes each extracted flag by calling a separate “Deferral Days Calculator” sub-workflow to determine deferral duration and whether the flag causes permanent deferral. Aggregates all flag results and computes the final deferral status (Permanent, Hold, or Eligible) using a longest-deferral-wins rule with permanent deferral taking priority. Sets the component action (quarantine vs. cleared pending standard testing), drafts a short donor notice with OpenAI, logs the outcome to an n8n Data Table, and sends a Telegram alert to the lab supervisor. Setup Connect credentials for Gmail, OpenAI, and Telegram, and ensure the Gmail trigger filters on the label you use for donor questionnaires. Provide authentication for the donor registry HTTP endpoint (https://donor-registry.example-bloodbank.org/...) and confirm the API returns deferral history for your donor_id format. Import the required “Deferral Days Calculator” sub-workflow and update the Execute Workflow node to point to its new workflow ID. Create an n8n Data Table for the quarantine/release ledger and replace the Data Table ID in the logging step. Set the Telegram chat ID for your lab supervisor in the Telegram notification step. Requirements OpenAI API Key: Connect your OpenAI credentials to both the Extractor Model and Notice Drafting Model node. Gmail Account: Connect a Gmail account with access to the donor screening intake inbox on the Receive Donor Screening Email trigger. Donor Registry Header Auth: Provide your registry endpoint API key in the Fetch Prior Deferral History HTTP Request node. Telegram Bot Token: Connect your Telegram bot credentials and set the supervisor chat ID in the Notify Lab Supervisor node. Sub-Workflow Dependency: Import the companion AABB Deferral Days Calculator sub-workflow (wf3b) and re-link its workflow ID inside the Calculate Flag Deferral Days node. Audit Data Table: Create an n8n Data Table (suggested columns: donor_id, component_id, deferral_status, component_action, deferral_end_date) and select it in the Log Quarantine/Release Ledger node. Customization Supervisory Approval Step: Insert a human-in-the-loop or "Send and Wait" approval node before the ledger step to require medical director sign-off on Permanent and Hold determinations. Notification Channels: Replace Telegram with Slack, Microsoft Teams, or an internal clinical paging system in the Notify Lab Supervisor node. Compliance Rules Table: Update the underlying deferral lookup table inside the sub-workflow to reflect facility-specific standard operating procedures or updated FDA/AABB guidance without editing this main workflow. Parallel Audit Sinks: Add a Google Sheets or PostgreSQL node alongside the n8n Data Table to maintain an external clinical audit archive. Intake Channel Adaptation: Swap the Gmail trigger for a webhook, webform submission, or direct EHR integration to capture intake responses from other platforms. Additional info Built-in Error Handling: External network, AI, sub-workflow, and database nodes feature automatic retry logic (3 attempts with a 2-second backoff) configured with continuous execution to prevent pipeline stalls on single-flag failures. Token & Cost Efficiency: Uses targeted prompts and temperature settings (0.1 for extraction, 0.3 for notice generation) across two concise model calls per intake to minimize operational API costs. Deterministic Decision Guardrail: All quarantine, release, and deferral status decisions are computed deterministically via code logic; the generative AI model is strictly restricted to extraction and compassionate notice drafting. PHI Minimization: Operates entirely on internal identifiers (donor_id, component_id) rather than personal names in prompts to maintain privacy best practices. An n8n automation workflow template by Swapnil Mandloi.

By Swapnil Mandloi

Quick overview This workflow receives a daily batch of golf course zone sensor readings, pulls a forecast from Open-Meteo, calculates per-zone irrigation runtimes, checks pesticide-label REI and water-hazard buffer rules with OpenAI, then posts the final schedule to an irrigation controller API and alerts staff via Telegram. How it works Receives a webhook POST containing course coordinates and an array of zone readings. Fetches the hourly weather forecast (including ET0 and precipitation probability) for the course location from the Open-Meteo API. Splits the incoming payload into one item per zone and calculates each zone’s soil-moisture deficit, ET-adjusted water need, and whether irrigation should be skipped due to high rain probability. For zones with a pesticide application within the last 5 days, uses OpenAI (GPT-4o-mini) to extract REI hours and required water-buffer distance from provided label text and determines whether the zone is still restricted. Sets irrigation minutes to zero for restricted zones, otherwise computes irrigation runtime minutes (or zeroes it when the rain forecast threshold is met). Aggregates all zones back into a single schedule, prioritizes zones by type, and builds a controller-ready payload including total runtime and compliance exceptions. Sends the schedule to the irrigation controller API and, if any zones were skipped, posts a Telegram message listing the affected zones and reasons. Setup Create an OpenAI credential and ensure the Information Extractor uses the GPT-4o-mini chat model. Configure HTTP Header Auth credentials for the irrigation controller API and replace the controller base URL with your real endpoint. Add Telegram bot credentials, set the GROUNDS_CREW_TELEGRAM_CHAT_ID, and ensure the bot is added to the target group/chat. Copy the production webhook URL for the webhook trigger and configure your sensor gateway to POST zone batches to it. Verify the incoming payload includes required fields (course_lat, course_lon, zones[].soil_moisture_pct, zone_type, days_since_pesticide_app, pesticide_applied_at, pesticide_product, label_text, distance_to_water_ft) and tune target moisture/crop coefficients and label-default behavior to match your agronomy and compliance rules. Requirements OpenAI API Key: Connect your OpenAI account to the GPT-4o-mini for Label Extraction node. Telegram Bot Credentials: Add your Telegram bot token to the Alert Grounds Crew – Restricted Zones node. Irrigation Controller Auth: Provide your controller's API URL and Header Auth credentials in the Push Schedule to Irrigation Controller node. Environment Variable: Set GROUNDS_CREW_TELEGRAM_CHAT_ID to your target Telegram group or channel ID. Incoming Webhook Source: Set up your field sensors or data gateway to send POST payloads to the /golf-zone-sensor-batch endpoint. Customization Turf Moisture Targets: Adjust target moisture percentages (default: greens 28%, fairways 22%, roughs 16%) in the Compute Soil Moisture Deficit node for your grass species. Product Label Source: Connect a database or inventory sheet to the Extract REI & Buffer Requirements node instead of sample text. Zone Run Priority: Modify run order and zone hierarchies (e.g., greens before fairways) inside the Build Irrigation Controller Payload node. Local Weather Source: Swap the free Open-Meteo API in the Fetch Today's Weather Forecast node for an on-site physical weather station. Notification Platform: Replace Telegram with Slack, Microsoft Teams, WhatsApp, or SMS in the Alert Grounds Crew – Restricted Zones node. Additional info Built-in Retry Logic: External API nodes include 3 automatic retries with a 2-second delay to handle temporary network dropouts. Token Cost Efficiency: The AI label extraction step only triggers for zones treated within the past 5 days. Expected Input Format: Expects a batch JSON object containing course coordinates and zone arrays: { "course_lat": , "course_lon": , "zones": [...] }. Platform Compatibility: Built and validated for n8n version 1.6x and newer. An n8n automation workflow template by Swapnil Mandloi.

By muhd dahlan

Quick overview This workflow receives inbound Twilio SMS replies, Twilio delivery callbacks, and Retell call analysis webhooks, then verifies signatures, handles opt-outs, qualifies candidates using rule-based criteria, books interviews in Google Calendar, queues and writes notes back to an ATS, notifies recruiters via Slack and Gmail, and logs eventsto Supabase. How it works Receives a POST webhook from Twilio (inbound SMS or status callback) or Retell (call_analyzed) and loads runtime settings from the config. Verifies the webhook signature for Twilio or Retell and rejects unsigned/untrusted requests unless running in preview mode. Normalizes the inbound payload into a single event shape, detects SMS intent (opt-out, interested, not interested, question, unclear), and ignores non-actionable events like delivery receipts or non-final Retell events. If the message is an opt-out, calls a Supabase RPC to stop all outreach for that phone number and (optionally) prepares a one-time confirmation message. Otherwise, evaluates the candidate against the configured QUALIFY rules (including Retell’s structured answers when present) to mark them as qualified, not qualified, needs review, or no answer. For qualified candidates, selects the job’s recruiter and proposes an interview slot, then creates a Google Calendar event when calendar booking is enabled and the workflow is running in live mode. Records the appointment and logs the inbound event in Supabase, queues and optionally writes an ATS note/status update, and notifies the recruiter via Slack webhook and/or Gmail before responding to Twilio/Retell with a fast acknowledgement. Setup Create a Supabase project, run the provided schema/seed SQL, and add your Supabase URL and service role key (or equivalent) to the config and Supabase HTTP Request nodes. Configure Twilio (Account SID/Auth Token, sending number or Messaging Service SID, and the status callback URL) and paste this workflow’s production webhook URL into Twilio and set the same value in TWILIO_STATUS_CALLBACK for signature verification. If using Retell, set your Retell API key, agent ID, and webhook signing secret, and configure Retell to send call_analyzed webhooks to this workflow’s webhook URL. Connect Google Calendar credentials (and set CALENDAR_PROVIDER to google) and connect Gmail credentials if you want recruiter email notifications. If you want ATS write-back, set the ATS base URL/token and confirm the candidate/job field mappings in ATS_FIELDS match your ATS. Review and adjust QUALIFY rules, quiet hours/booking windows, and set DEMO_MODE/TEST_RUN to false only when you are ready to send messages and write back to external systems. An n8n automation workflow template by muhd dahlan.

By muhd dahlan

Quick overview This workflow runs every 15 minutes to claim due outreach enrollments from Supabase, decide the next SMS or voice touch based on a sequence and quiet hours, send via Twilio (SMS) or Retell (voice), then write attempts and enrollment updates back to Supabase and optionally post a Slack summary. How it works Runs every 15 minutes (or manually) and loads configuration that controls the outreach sequence, quiet hours, caps, and provider settings. Claims a batch of due outreach attempts from Supabase via an RPC call, or falls back to a built-in sample queue when Supabase is not configured. Evaluates each due enrollment to choose the next ladder step, render the SMS body or voice-call variables, enforce candidate-local quiet hours/weekend rules and daily caps, and generate an idempotency key. If sending is enabled, routes each item to Twilio to send an SMS or to Retell to start an outbound voice call, otherwise outputs a preview of what would be sent. Classifies provider responses as sent, transient failure, or permanent failure (including carrier opt-outs), and determines whether to advance, retry later with backoff, or stop the enrollment. Writes contact attempts, enrollment state updates, and carrier-level opt-outs to Supabase when database writes are enabled. Builds a run summary and posts it to Slack via an incoming webhook when Slack is configured and there is something noteworthy to report. Setup Create and configure the required Supabase schema (RPC to claim due attempts, enrollments queue/view logic, contact_attempts and opt_outs tables, and uniqueness on the idempotency key) and set your Supabase URL and service role key in the config. Add your Twilio Account SID, Auth Token, and a From number or Messaging Service SID (and optionally a Twilio Status Callback URL) in the config to enable SMS sending. Add your Retell API key, agent ID, and from number in the config to enable voice outreach. Review and customize the outreach sequence templates, quiet hours/weekend rules, daily send cap, and permanent SMS error codes in the config node. (Optional) Set a Slack incoming webhook URL in the config to receive runner summaries, and switch from DEMO_MODE/preview to test/live sending when you are ready. An n8n automation workflow template by muhd dahlan.

By muhd dahlan

Quick overview This workflow receives a new job order from an ATS webhook, optionally extracts requirements using Anthropic, searches and scores matching candidates from the ATS, checks suppression rules and engagement history in Supabase, then upserts a campaign with scheduled enrollments and optionally posts a launch summary to Slack. How it works Receives a job order via webhook (or runs manually) and normalizes it into a consistent job spec using the configured ATS field mapping. If the job order is missing enough structured skills, calls Anthropic Messages API to extract required and preferred skills and merges them back into the job spec. Searches for candidates in the ATS via its API (or falls back to a built-in sample candidate pool if the ATS is not connected). Normalizes candidates (including E.164 phone formatting, status-based exclusions, and deduplication) and computes a transparent match score with human-readable reasons. Fetches opt-outs, recent touches, and active enrollments from Supabase (or uses demo/empty history when Supabase is not configured) and gates out ineligible candidates. Upserts the job order, campaign, and candidates into Supabase, links IDs, inserts enrollment rows with the first touch scheduled (not sent), and optionally posts a formatted launch summary to Slack. Setup Configure your ATS webhook subscription to send “job order created” events to the workflow webhook URL. In the config values, set your ATS vendor details and field mappings (ATS_FIELDS), plus thresholds like MIN_MATCH_SCORE and ENROLL_TOP_N. Add credentials and fill connection values for Supabase (project URL and service role key) and ensure your database has the required tables/RPC (including the engagement_history function) and appropriate RLS policies. If you want AI requirement extraction, add an Anthropic API key and choose the model settings in the config. If you want notifications, set a Slack incoming webhook URL in the config. Turn off DEMO_MODE and adjust TEST_RUN/TEST_PHONE once you are ready to persist real campaigns and enrollments. An n8n automation workflow template by muhd dahlan.

By SPIRIDON TSAKONAS

Quick overview This workflow monitors a list of URLs every 5 minutes, confirms downtime only after two consecutive failures, emails down/recovery alerts via SMTP, logs checks and incidents to n8n Data Tables, and sends a daily uptime and latency report at 08:00 with automatic data cleanup. How it works Runs every 5 minutes on a schedule to load recent incident history and recent check results from n8n Data Tables. Builds a per-URL check list (including expected page text and the previous state) and probes each site with an HTTP GET, retrying once after a short wait if the first attempt fails. Evaluates each probe result to detect confirmed downtime (two failed checks in a row) or recovery (first successful check after being down) and calculates downtime minutes. Records every check outcome (status code, response time, and reason) to the url_checks n8n Data Table. When a state change is detected, writes an incident entry to the url_incidents table and sends a single SMTP email alert for either DOWN or RECOVERED. Runs daily at 08:00 to aggregate the last 24 hours of checks (compared to the prior 24 hours), then emails an HTML uptime report with uptime %, average and p95 response times, and incidents per URL. Deletes url_checks rows older than 14 days to keep the monitoring dataset small. Setup Create two n8n Data Tables named url_checks (url, ok, status_code, response_ms, reason, checked_at) and url_incidents (url, status, reason, changed_at, downtime_minutes). Add an SMTP credential in n8n and select it in the DOWN alert, recovery alert, and daily report email steps. Update the sites list (URLs, expected text, and slow threshold) in the code step that defines SITES, and set the to/from email addresses in each email step. An n8n automation workflow template by SPIRIDON TSAKONAS.

By Tucker

Quick overview This workflow replies to incoming Telegram bot messages using an Ollama, OpenAI, or Anthropic chat model constrained by your business notes, and falls back to a predefined message when it can’t answer or the AI call fails. How it works Triggers when your Telegram bot receives a new message. Loads recent conversation turns for the Telegram chat from n8n’s workflow static data to provide context. Builds a provider-specific chat request (Ollama, OpenAI, or Anthropic) by injecting your business name, knowledge notes, conversation history, and the new message into a JSON-only prompt. Sends the request to the selected AI endpoint via HTTP. Parses the AI response as JSON and only uses the model’s reply when it marks the question as answerable, otherwise it uses your predefined fallback message. Sends the chosen reply back to the customer in Telegram and appends both the customer and bot messages to the stored chat log. If the AI request errors, sends the fallback message to Telegram so the customer still gets a response. Setup Create a Telegram bot with BotFather and connect your Telegram credentials in the Telegram Trigger and Telegram send-message nodes. In the Settings node, fill in business_name, knowledge (one fact per line), and optionally customize cannot_answer_message, ai_provider, and ai_model. If using Ollama, ensure Ollama is running and reachable at ollama_url and that the selected model is pulled locally. If using OpenAI or Anthropic, configure header-based authentication on the HTTP Request node with your API key credential and set ai_provider and ai_model accordingly. An n8n automation workflow template by Tucker.

By Michael Matthews

Quick overview This workflow runs daily and uses Twilio SMS to remind you about upcoming or overdue license and insurance renewals from a text list, with optional “Done” links via an n8n webhook to roll repeating items forward and stop one-time reminders. How it works Runs every day at 8:00 AM (or starts when you open a “Done” link webhook) and loads your renewal list and reminder settings. Parses each line into a tracked renewal item with a due date, optional repeat interval, and optional note, and validates phone numbers, time zone, and n8n base URL for links. On the daily run, determines which items are on a configured reminder offset, due today, overdue (optionally repeating every N days), and optionally compiles a monthly look-ahead for the next set number of days. Builds a single SMS message (including per-item “Done?” links when enabled) and skips sending if the workflow already ran that day. Sends the SMS through the Twilio REST API. If Twilio accepts it, the queued text is cleared; if not, the text is kept and goes out again with the next morning's run, for up to three days. When a “Done?” link is tapped, updates the item in workflow static data by rolling repeating items to the next due date or marking one-time items complete, then returns an HTML confirmation page with an Undo link. A used or out-of-date link changes nothing. Setup Add a Twilio API credential and select it in both Twilio HTTP Request steps used to look up your account and send SMS. Update “Your settings” with your Twilio phone number (From), your mobile number (To), your time zone, and your n8n base URL for the “Done?” links (or set done_links to false). Enter your renewal items in the provided name | due date | repeat | note format and adjust reminder offsets, overdue frequency, and monthly outlook settings as needed. Publish the workflow. The “Done?” links use its production webhook (/webhook/renewal-done), so your n8n must be reachable from your phone. The first text arrives the next morning at 8. Requirements A Twilio account and number that can text your own cell (in the US that means A2P 10DLC registration or a verified toll-free number) An n8n instance your phone can reach for the Done links (n8n Cloud, or self-hosted with a public URL). Set done_links to false if yours is not reachable No database or spreadsheet: the list lives in the Your settings node and the rolled dates in the workflow's static data Customization Add, change or remove lines in items, one per line: name | due date | repeat | note. Repeat takes yearly, monthly, quarterly, every 2 years, every 6 months, any "every N days, weeks, months or years", or none Change remind_days to choose how many days ahead you hear about each item (default 60, 30, 14, 7, 3, 1, 0) Change overdue_every_days to repeat overdue items every few days instead of daily, or set it to 0 to stop overdue repeats Set monthly_outlook to false to skip the look ahead on the 1st of the month, or change outlook_days to look further out (default 90) Change the send time on the Every morning at 8 node, and set the workflow time zone so 8 AM is your 8 AM To get the reminders by email instead, replace the Text you node and change the Went out? check to match the new node's output Additional info Tested live on n8n Cloud with a real Twilio number, plus 61 automated checks. Test notes and the texts it sends: https://github.com/mikematthewsai/n8n-renewal-reminders-sms. An n8n automation workflow template by Michael Matthews.