Social Media Autoposter - Workflow Shows Success But Posts Not Publishing (Loop Data Flow Issue)

Problem Summary

My automated social media posting workflow executes successfully (green checkmarks, no errors in logs) but zero posts are actually publishing to LinkedIn, Facebook, or Instagram. The workflow has completed 183 “successful” executions, yet all posts remain with status=“Scheduled” in my Base44 database and nothing appears on social media platforms.

Workflow Setup

Purpose: Automated social media posting system that retrieves scheduled posts from Base44 database, filters by date/time, routes to appropriate platforms, and publishes content automatically.

Key Components:

  • Schedule trigger: Every 30 minutes (7am-8pm EST)
  • Base44 API: GET posts from SocialPost entity
  • JavaScript filter: Filters posts by status=“Scheduled”, scheduled_date=today, scheduled_time<=current_time
  • Loop structure: “Process One at a Time” loop
  • Expand to Platforms: Creates 3 items (LinkedIn, Facebook, Instagram) with targetPlatform field
  • Route by Platform: Switch/Expression node routes based on targetPlatform
  • Platform-specific posting nodes: LinkedIn Create Post, Facebook Create Post, Instagram Publish

The Core Issue

Symptoms:

  1. Workflow shows “Success” status in execution logs :white_check_mark:
  2. No error messages in recent executions
  3. Posts remain with status=“Scheduled” in Base44 (never change to “Published”)
  4. Zero posts published across all platforms
  5. Fast execution times (200-350ms) suggesting workflow exits early

What I’ve Already Fixed

:white_check_mark: Base44 API query parameter filtering (now filtering in JavaScript)
:white_check_mark: Status field mismatch between UI and database
:white_check_mark: Time format conversion (12-hour to 24-hour)
:white_check_mark: Timezone handling (EST conversion)
:white_check_mark: JavaScript syntax errors in filter code

Data Flow Observation

When testing individual nodes:

  • “Expand to Platforms” shows “No input data” when tested individually
  • “Route by Platform” shows “No output data” when tested individually
  • Posting nodes (LinkedIn/Facebook/Instagram) show “No input data”

But when running the full workflow, it shows “Success” without actually posting.

Route by Platform Configuration

Expression mode:

{{ $json.targetPlatform === 'LinkedIn' ? 0 : $json.targetPlatform === 'Facebook' ? 1 : $json.targetPlatform === 'Instagram' ? 2 : 3 }}

Routes to:

  • Output 0 → LinkedIn path
  • Output 1 → Facebook path
  • Output 2 → Instagram path
  • Output 3 → Default

Expand to Platforms Code

const post = $input.item.json;
let platforms = [];

if (post.platform.includes('All')) {
  platforms = ['LinkedIn', 'Facebook', 'Instagram'];
} else {
  if (post.platform.includes('LinkedIn')) platforms.push('LinkedIn');
  if (post.platform.includes('Facebook')) platforms.push('Facebook');
  if (post.platform.includes('Instagram')) platforms.push('Instagram');
}

return platforms.map(p => {
  let caption;
  
  if (p === 'LinkedIn') {
    caption = post.caption_linkedin || post.caption_master || post.caption || '';
  } else if (p === 'Facebook') {
    caption = post.caption_facebook || post.caption_master || post.caption || '';
  } else {
    caption = post.caption_instagram || post.caption_master || post.caption || '';
  }
  
  return {
    json: {
      ...post,
      targetPlatform: p,
      caption: caption
    }
  };
});

Questions

  1. Loop Context: In a “Process One at a Time” loop, why would downstream nodes show “No input data” when tested individually if the full workflow succeeds?

  2. Route by Platform: Is my expression syntax correct for routing based on the targetPlatform field? Should I use a different approach (Switch node vs IF nodes)?

  3. Silent Failures: Why would a workflow show “Succeeded” status but skip posting nodes without error messages? How can I enable more detailed logging?

  4. Data Flow: How can I verify that data is actually flowing through “Expand to Platforms” → “Route by Platform” → posting nodes?

Environment

  • Timezone: EST/New York (server may be Europe/Berlin)
  • External Services: Base44 API, LinkedIn API, Facebook API, Instagram API
  • Workflow Schedule: Every 30 minutes, 7am-8pm EST
  • Expected: 9-12 posts per day across 3 platforms

What I Need

  1. Workflow audit to identify why posting nodes aren’t receiving data
  2. Execution analysis of successful runs to see actual data flow
  3. Guidance on testing nodes within loop context
  4. Best practices for error handling and debugging in complex loop workflows

This is a production automation critical to our business operations. Any assistance would be greatly appreciated!

Would you consider sharing the full workflow with us to receive best possible assistance?
Also, what is the role of Base44 in your setup? Is it providing a frontend to put in the details of the posts?

Also, if you’re interested in a one on one call, send me a DM. I’ve built several content automation workflows in the past.

183 個綠色執行,幾乎沒有任何東西上線,通常表示發佈節點從未看到項目。不是 LinkedIn 吃掉貼文。空執行,仍然成功。

釘住一個執行。

查看 Base44 後的項目計數,然後查看篩選器後的計數。那些 200-350ms 的執行會跳出來。如果兩個計數都是零,我根本不會先打開 oauth 日誌。沒有任何東西到達 API。

我的猜測是篩選器。狀態拼寫、日期時區或時間比較。Scheduled 中的尾隨空格曾經抓住我。我花了尷尬地長時間。

如果篩選器吐出項目,只有那時才點擊展開到平台。不要從畫布中間單獨測試該節點。當沒有到達任何東西時,它看起來是空的。釘住一個真實的已排程行,並查看設定了 targetPlatform 的 3 個項目。

在切換之前,將 targetPlatform 轉儲到一個集合中。linkedin vs LinkedIn 將所有內容轉儲到預設值。很容易陷阱。我第一次假設它也是 oauth。

只有在項目明確進入建立貼文節點後,我才會讀取回應正文。綠色可能只是意味著請求已被接受。將 id + 原始回應寫回 Base44,然後翻轉已發佈。行卡在已排程永遠?發佈可能從未執行。

還有一件事:媒體在觸發時仍為公開。在排程時有效且到了下午就過期的已簽署 URL 很煩人。

先修復篩選器。認真的。在篩選器工作之前不要碰 oauth。

一旦一個網路實際發佈並寫入狀態,多平台展開就不那麼詛咒了。如果稍後痛點是一行到許多網路進行重試,對我有效的是 n8n 中的intake 和最後一跳上的 blotato。但不是你今天遇到的 bug。

200-350毫秒的執行時間就是答案,值得解釋為什麼:沒有任何下游節點執行。在n8n中,接收零個項目的節點不會出錯,它只是不執行,運行仍然以Success完成。183次發布沒有任何內容的綠色執行意味著上游某處發出零個項目,其後的所有內容都被默默跳過。

所以不要調試發佈節點。按此順序找出項目消失的位置。

  1. 打開其中一個成功的執行,從左到右讀取每個節點上的項目計數。第一個輸出為0個項目的節點就是你的bug;其右邊的所有內容都是無辜的。一分鐘內,猜測就結束了。
  2. 檢查循環連線,因為你的症狀直指它。Split In Batches(「Process One at a Time」)有兩個輸出:loop和done。主體必須從loop輸出開始,主體的最後一個節點必須連接回Split In Batches節點。如果Expand to Platforms連接到done而不是loop,主體永遠不會運行,工作流立即結束,並報告Success。這符合快速運行時間和「發佈節點顯示No input data」。
  3. 然後是篩選器。如果你的日期比較運行在與你推理不同的時區(伺服器可能是Europe/Berlin,而你想的是EST),scheduled_date === today在特定時間後對每一行都可能是false,篩選器會誠實地返回空值。記錄返回前的陣列長度,加上一個原始的scheduled_date,這樣你可以看到實際上在比較什麼。
  4. Expand to Platforms使用$input.item.json,只有當Code節點設置為「Run Once for Each Item」時才會如你預期的行為。在默認的「Run Once for All Items」上,那不是你想的那樣。切換模式或用$input.all()重寫它。
  5. 你的Switch後備選項就是為什麼不匹配是不可見的原因:不是LinkedIn/Facebook/Instagram的任何內容都轉到輸出3,如果輸出3未連接,項目會無聲地消失。將後備選項連接到能提醒你的東西,即使只是一個電子郵件節點說「unrouted platform: {{$json.targetPlatform}}」。無聲的預設分支是工作流欺騙你的方式。

結構性修復,以及為什麼這運行了183次而未被注意到的原因:一個工作的目的是發佈的工作流不應該被允許在發佈零篇文章時報告Success。在最後添加顯式檢查:如果發佈計數為0,拋出或警告。並且只在平台節點返回post id後才將status=Published寫入Base44,永遠不要之前,這樣資料庫就不能與現實不一致。

Error Workflow仍然值得為其他所有內容添加,但請注意它不會捕捉到這個情況,因為零個項目不是一個錯誤。這正是為什麼零發佈守衛必須是顯式的。