Email subscription service with n8n forms, Airtable and AI
This n8n template shows how anyone can build a simple newsletter-like subscription service where users can enrol themselves to receive messages/content on a regular basis. It uses n8n forms for data capture, Airtable for database, AI for content generation and Gmail for email sending. How it works An n8n form is setup up to allow users to subscribe with a desired topic and interval of which to recieve messages via n8n forms which is then added to the Airtable. A scheduled trigger is executed every morning and searches for subscribers to send messages for based on their desired intervals. Once found, Subscribers are sent to a subworkflow which performs the text content generation via an AI agent and also uses a vision model to generate an image. Both are attached to an email which is sent to the subscriber. This email also includes an unsubscribe link. The unsubscribe flow works similarly via n8n form interface which when submitted disables further scheduled emails to the user. How to use Make a copy of sample Airtable here: https://airtable.com/appL3dptT6ZTSzY9v/shrLukHafy5bwDRfD Make sure the workflow is "activated" and the forms are available and reachable by your audience. Requirements Airtable for Database OpenAI for LLM (but compatible with others) Gmail for Email (but can be replaced with others) Customising this workflow This simple use can be extended to deliver any types of content such as your company newsletter, promotions, social media posts etc. Doesn't have to be limited to just email - try social messaging, Whatsapp, Telegram and others.
By JimleukCreate a new member, update the infromation, create a note and post in Orbit
No description available.
By Harshil AgrawalAI-powered Zendesk support responses with RAG, OpenAI, and Supabase knowledge base
⚡ How it works This workflow automates first responses to new Zendesk tickets with the help of AI and your internal knowledge base. Webhook trigger fires whenever a new ticket is created in Zendesk. Ticket details (subject, description, requester info) are extracted. Knowledge base retrieval – the workflow searches a Supabase vector store (with OpenAI embeddings) for the most relevant KB articles. AI assistant (RAG agent) drafts a professional reply using the retrieved KB and conversation memory stored in Postgres. Decision logic: If no relevant KB info is found (or if it’s a sensitive query like KYC, refunds, or account deletion), the workflow sends a fallback response and tags the ticket for human review. Otherwise, it posts the AI-generated reply and tags the ticket with ai_reply. Logging & context memory ensure future ticket updates are aware of past interactions. ------ 🔧 Set up steps This workflow takes about 15–30 minutes to set up. Connect credentials for Zendesk, OpenAI, Supabase, and Postgres. Prepare your knowledge base: store support content in Supabase (documents table) and embed it using the provided Embeddings node. Set up Postgres memory table (zendesktickethistories) to store conversation history. Update your Zendesk domain in the HTTP Request nodes (<YOURZENDESKDOMAIN>). Deploy the webhook URL in Zendesk triggers so new tickets flow into n8n. Test by creating a sample ticket and verifying: AI replies appear in Zendesk Correct tags (aireply or humanrequested) are applied Logs are written to Postgres
By Md Sagor KhanAutomate B2B SaaS renewal risk management with CRM, support & usage data
Description This workflow is designed for B2B/SaaS teams who want to secure renewals before it’s too late. It runs every day, identifies all accounts whose licenses are up for renewal in J–30, enriches them with CRM, product usage and support data, computes an internal churn risk level, and then triggers the appropriate playbook: HIGH risk → full escalation (tasks, alerts, emails) MEDIUM risk → proactive follow-up by Customer Success LOW risk → light renewal touchpoint / monitoring Everything is logged into a database table so that you can build dashboards, run analysis, or plug additional automations on top. --- How it works Daily detection (J–30 renewals) A scheduled trigger runs every morning and queries your database (Postgres / Supabase) to fetch all active subscriptions expiring in 30 days. Each row includes the account identifier, name, renewal date and basic commercial data. Data enrichment across tools For each account, the workflow calls several business systems to collect context: HubSpot → engagement history Salesforce → account profile and segment Pipedrive → deal activities and associated products Analytics API → product feature usage and activity trends Zendesk → recent support tickets and potential friction signals All of this is merged into a single, unified item. Churn scoring & routing An internal scoring step evaluates the risk for each account based on multiple signals (engagement, usage, support, timing). The workflow then categorizes each account into one of three risk levels: HIGH – strong churn signals → needs immediate attention MEDIUM – some warning signs → needs proactive follow-up LOW – looks healthy → light renewal reminder A Switch node routes each account to the relevant playbook. Automated playbooks 🔴 HIGH risk Create a Trello card on a dedicated “High-Risk Renewals” board/list Create a Jira ticket for the CS / AM team Send a Slack alert in a designated channel Send a detailed email to the CSM and/or account manager 🟠 MEDIUM risk Create a Trello card in a “Renewals – Follow-up” list Send a contextual email to the CSM to recommend a proactive check-in 🟢 LOW risk Send a soft renewal email / internal note to keep the account on the radar Logging & daily reporting For every processed account, the workflow prepares a structured log record (account, renewal date, risk level, basic context). A Postgres node is used to insert the data into a churn_logs table. At the end of each run, all processed accounts are aggregated and a daily summary email is sent (for example to the Customer Success leadership team), listing the renewals and their risk levels. --- Requirements Database A table named churn_logs (or equivalent) to store workflow decisions and history. Example fields: accountid, accountname, enddate, riskScore, riskLevel, playbook, trellolink, jira_link, timestamp. External APIs HubSpot (engagement data) Salesforce (account profile) Pipedrive (deals & products) Zendesk (support tickets) Optional: product analytics API for usage metrics Communication & task tools Gmail (emails to CSM / AM / summary recipients) Slack (alert channel for high-risk cases) Trello (task creation for CS follow-up) Jira (escalation tickets for high-risk renewals) Configuration variables Thresholds are configured in the Init config & thresholds node: daysbeforerenewal churnthresholdhigh churnthresholdmedium These parameters let you adapt the detection window and risk sensitivity to your own business rules. --- Typical use cases Customer Success teams who want a daily churn watchlist without exporting spreadsheets. RevOps teams looking to standardize renewal playbooks across tools. SaaS companies who need to prioritize renewals based on real risk signals rather than gut feeling. Product-led organizations that want to combine usage data + CRM + support into one automated process. Tutorial video Watch the Youtube Tutorial video About me : I’m Yassin a Project & Product Manager Scaling tech products with data-driven project management. 📬 Feel free to connect with me on Linkedin
By Yassin Zehar