by System Admin
Tagged with: , , , ,
by System Admin
Tagged with: , , , ,
by System Admin
Tagged with: , , , ,
by System Admin
Tagged with: , , , ,
by System Admin
Tagged with: , , , ,
by System Admin
Tagged with: , , , ,
by System Admin
No description available
by Jan Oberhauser
When set as "Error Workflow" on other workflow which does fail will it send an Email with information about which workflow did fail and what went wrong.
by Guy
General principles This template automates the management of marketing campaign from a CRM based on Airtable, using Brevo for sending and tracking emails. It is based on two main steps: Sending emails to targeted companies in Airtable, creating an interaction record for each sent email. Real-time tracking of events (email delivered / opened / clicked, unsubscribe request) via a n8n webhook, updating the corresponding interaction or company record. This workflow provides precise tracking of marketing actions and facilitates the history of interactions with prospects or clients. Prerequisites Airtable with at least 3 tables: Company: Contains information about your clients or prospects. Interaction: Log of exchanges and events. Campaign: Information about the ongoing campaign. Brevo: A predefined email template, which can include a link to a form. API access for sending and tracking emails. Step-by-step description Part 1: Sending Emails Selecting targeted companies The workflow queries the Company table in Airtable, filtering on a tag or a specific field related to the campaign (e.g., Campaign = "1"). Preparing data for Brevo For each company, retrieves the necessary information: email address. Sending the email via Brevo Uses a Brevo Send Template node with a predefined template. Brevo returns a unique identifier for each email sent. Creating an interaction in Airtable A record is added to the Interaction table containing: Company Date and time of interaction Media = email Brevo email identifier Part 2: Tracking Events Receiving Brevo events Brevo triggers a webhook to n8n for each event: Delivered Opened Clicked Unsubscribed Matching with the interaction Based on the Brevo identifier received, the workflow finds the corresponding Interaction in Airtable. Updating the interaction The interaction status is updated based on the event (e.g., "Opened" with date and time). Managing unsubscribes In case of an unsubscribe: The workflow finds the Company associated via the interaction. A specific field in the Company table (e.g., Opt-in) is updated to "No" in order to exclude this company from future campaigns. ✅ Benefits of this template Automated sending and real-time tracking. Interaction history stored in the CRM. RGPD (European regulations) compliance through automatic unsubscribe management. Clear view of campaign effectiveness (open rates, clicks, etc.).
by Davide
This workflow automates the process of validating email addresses stored in a Google Sheets file by using the Anymail Finder API. Key Advantages ✅ Automated Lead Validation No need for manual copy-paste or bulk uploads emails are verified directly inside your existing Google Sheets. 🔎 Improved Data Quality Ensures your CRM or outreach campaigns only target valid and deliverable email addresses, reducing bounce rates. 🔄 Real-Time Updates Results are automatically updated in the spreadsheet, making it easy for your team to see which leads are safe to contact. 📈 Improves lead quality for outreach, reduces bounce rates Of course. Here is a description of the provided n8n workflow. Workflow Description: Verify Leads Email Address with Anymail Finder This workflow automates the process of checking the validity of email addresses from a Google Sheets list using the Anymail Finder API and writing the results back to the sheet. How It Works The workflow operates in a loop to process a list of leads from a Google Sheet one by one. Manual Trigger: The workflow is started manually by a user within n8n. Get Leads: The "Get Leads" node reads data from a specified Google Sheet. It is configured with a filter to only fetch rows where the "VERIFY" column is empty, ensuring it only processes new leads that haven't been checked yet. Loop Over Items: The "Split In Batches" node is used to iterate over each row (lead) retrieved from the Google Sheet. This sends each lead individually to the next node for processing. Check Email Status: For each lead, the "HTTP Request" node sends a POST request to the Anymail Finder API (/v5.1/verify-email). The email address from the current sheet row ($json["EMAIL "]) is sent in the request body. Update Email Status: The response from Anymail Finder (which contains the verification status) is received. The "Update email status" node then takes this result and writes it back to the "VERIFY" column of the original Google Sheet. It uses the row_number to identify the correct row to update, ensuring data is placed accurately. Set Up Steps To use this workflow, you need to configure the following credentials and nodes: Google Sheets Credentials: Create a credential named "Google Sheets account" of type OAuth2. Follow n8n's guide to authenticate with Google Sheets. This will give the workflow permission to read from and write to your spreadsheet. Anymail Finder Credentials: Create a credential named "Anymail Finder" of type HTTP Header Auth. In the "Name" field, enter Authorization (or the header name required by Anymail Finder's API documentation). In the "Value" field, enter your Anymail Finder API key (in the format YOUR_API_KEY). Configure Google Sheet: Ensure your Google Sheet has at least the following columns: COMPANY NAME, EMAIL (note the space), and VERIFY. The "VERIFY" column must be empty for rows you want to verify. The "Get Leads" node is filtered to only process rows where this column is blank. Activate and Execute: Once the credentials are set and the sheet ID is configured, activate the workflow. Click on the "Manual Trigger" node and execute the workflow. It will begin processing all leads with an empty "VERIFY" field. Need help customizing? Contact me for consulting and support or add me on Linkedin.
by Alexander Schnabl
Report stale pages in Confluence This workflow generates a stale page report for Confluence spaces, helping teams keep documentation accurate, relevant, and actively maintained. What it does Identifies Confluence pages not updated within a defined cutoff period (in days). Supports both: Confluence REST API v1 (CQL search), and Confluence REST API v2 (spaces + pages). Produces a clean, aggregated report including: Page title Page status Last updated date Days overdue Direct page URL Ideal for content audits, documentation hygiene, and ownership reviews. How it works The workflow starts via a Manual Trigger. A Set Variables node defines: Atlassian domain Space keys to scan Cutoff age (in days) API version toggle (v1 or v2) Two execution paths are supported: API v1: Uses CQL search to fetch outdated pages directly. API v2: Fetches spaces → pages → filters pages by last modified date. All pages are normalized into a consistent format. Results are aggregated into a single stalePages array for easy reuse in downstream steps. Setup Configure the Set Variables node: atlassianDomain → your Confluence base URL spaceKeys → comma-separated space keys (e.g. DOCS, ENG) cutoffDateDays → age threshold (e.g. 90) apiV2 → true (recommended) or false for legacy CQL Create an HTTP Basic Auth credential: Atlassian email + API token Assign it to all HTTP Request nodes Optional: Extend the workflow with email notifications, Slack alerts, or CSV exports. Notes API v2 is recommended** and future-proof; API v1 is included for legacy compatibility. Pagination limits are set to 50 items per request — increase if your spaces contain many pages. If no results are returned: Verify space keys Check cutoff logic Confirm API permissions for the token Tested against Confluence Cloud.
by Alexander Schnabl
Scan Confluence pages for inactive page owners This workflow scans selected Confluence spaces, resolves page ownership and filters pages with inactive owners, helping teams maintain clear ownership and prevent orphaned documentation. What it does Scans Confluence pages across selected spaces. Resolves page owners and checks their account status**. Filters pages where the owner is inactive** (owner.accountStatus !== active). Uses Confluence REST API v2 to fetch spaces, pages, and user data. Resolves page owners efficiently via the users-bulk API. Produces a consolidated report containing: Page title Owner email Owner account status Last updated date Direct page URL Useful for documentation governance, ownership audits, and cleanup initiatives. How it works A Set Variables node defines: Atlassian domain Space keys to scan Get Spaces (v2)** retrieves matching spaces and extracts their IDs. Get Pages (v2)** fetches all pages from the selected spaces. Unique page ownerIds are collected and resolved using Bulk User Lookup (v2). Page metadata is merged with user account data (ownerId ↔ accountId). Pages are filtered to include only those with inactive owners. Setup Configure the Set Variables node: atlassianDomain → your Confluence base URL spaceKeys → comma-separated list of space keys (e.g. ENG, HR) Create an HTTP Basic Auth credential: Atlassian email + API token Assign it to all HTTP Request nodes Optional enhancements: Add pagination if spaces contain many pages. Extend the workflow with email notifications, Slack alerts, or CSV export. Notes Requires permission to read Confluence spaces, pages, and users. Pages are flagged when owner.accountStatus !== active. Current page fetch limit is 50 items per request.