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:
Workflow shows “Success” status in execution logs
No error messages in recent executions
Posts remain with status=“Scheduled” in Base44 (never change to “Published”)
Zero posts published across all platforms
Fast execution times (200-350ms) suggesting workflow exits early
What I’ve Already Fixed
Base44 API query parameter filtering (now filtering in JavaScript) Status field mismatch between UI and database Time format conversion (12-hour to 24-hour) Timezone handling (EST conversion) 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.
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
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?
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)?
Silent Failures: Why would a workflow show “Succeeded” status but skip posting nodes without error messages? How can I enable more detailed logging?
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
Workflow audit to identify why posting nodes aren’t receiving data
Execution analysis of successful runs to see actual data flow
Guidance on testing nodes within loop context
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 exécutions vertes et rien en direct signifie presque toujours que les nœuds de publication n’ont jamais vu d’élément. Ce n’est pas LinkedIn qui supprime les posts. Exécution vide, succès quand même.
Épingler une exécution.
Regarde les compteurs d’éléments après Base44, puis après le filtre. Ces exécutions de 200-350ms se démarquent. Si les deux compteurs sont à zéro, je n’ouvrirais même pas les logs oauth pour l’instant. Rien n’a atteint les APIs.
Ma théorie c’est le filtre. Orthographe du statut, fuseau horaire de la date, ou la comparaison de temps. Un espace à la fin dans Scheduled m’a eu une fois. Ça m’a pris embarrassamment longtemps.
Si le filtre crache des éléments, seulement là tu tapes Expand to Platforms. Ne teste pas ce nœud seul en le sortant du milieu du canvas. Ça paraît vide quand rien n’arrive. Épingle une vraie ligne Scheduled et surveille 3 éléments avec targetPlatform configuré.
Avant le switch, jette targetPlatform dans un Set. linkedin vs LinkedIn envoie tout au défaut. Piège facile. J’ai supposé que c’était oauth aussi la première fois.
Seulement après qu’un élément frappe clairement un nœud create-post j’irais lire le corps de la réponse. Le vert peut juste vouloir dire requête acceptée. Écris id + réponse brute dans Base44, puis bascule Published. Des lignes bloquées sur Scheduled pour toujours ? publish n’a probablement jamais tourné.
Une dernière chose : le média est toujours public au moment du déclenchement. Les URLs signées qui marchent à la programmation et qui crèvent l’après-midi c’est relou.
Répare le filtre en premier. Sérieusement. Ne touche pas à oauth tant que le filtre ne marche pas.
Une fois qu’un réseau poste réellement et écrit le statut, l’expansion multi-plateforme devient beaucoup moins cursed. Si plus tard la douleur c’est une ligne vers plein de réseaux avec retries, ce qui a marché pour moi c’est l’intake dans n8n et blotato sur le dernier saut. Pas le bug que tu as aujourd’hui cependant.
Le temps d’exécution de 200 à 350 ms est la réponse, et il vaut la peine d’expliquer pourquoi : rien en aval n’a été exécuté. Dans n8n, un nœud qui reçoit zéro élément ne génère pas d’erreur, il ne s’exécute tout simplement pas, et l’exécution se termine quand même en tant que Succès. 183 exécutions vertes qui n’ont rien publié signifie que quelque chose en amont émet zéro élément et tout ce qui suit est ignoré silencieusement.
Donc ne déboguez pas les nœuds de publication. Trouvez où les éléments disparaissent, dans cet ordre.
Ouvrez l’une des exécutions réussies et lisez le nombre d’éléments sur chaque nœud, de gauche à droite. Le premier nœud avec 0 éléments en sortie est votre bug ; tout ce qui se trouve à sa droite est innocent. Une minute, et les suppositions prennent fin.
Vérifiez le câblage de la boucle, car vos symptômes le désignent clairement. Split In Batches (« Process One at a Time ») a deux sorties : loop et done. Le corps doit être connecté à la sortie loop, et le dernier nœud du corps doit se reconnecter AU nœud Split In Batches. Si Expand to Platforms est câblé à done au lieu de loop, le corps ne s’exécute jamais, le flux de travail se termine instantanément, et il signale Succès. Cela correspond à la fois aux temps d’exécution rapides et à « les nœuds de publication affichent Aucune donnée d’entrée ».
Puis le filtre. Si votre comparaison de date s’exécute dans un fuseau horaire différent de celui dans lequel vous raisonnez (le serveur peut être en Europe/Berlin tandis que vous pensez en EST), scheduled_date === today peut être faux pour chaque ligne après une certaine heure, et le filtre retourne honnêtement rien. Enregistrez la longueur du tableau juste avant de retourner, plus une scheduled_date brute, pour voir ce qui est réellement comparé.
Expand to Platforms utilise $input.item.json, qui ne se comporte comme prévu que lorsque le nœud Code est défini sur « Run Once for Each Item ». Sur le défaut « Run Once for All Items », ce n’est pas ce que vous pensez. Changez le mode ou réécrivez-le avec $input.all().
Votre fallback Switch est la raison pour laquelle une non-correspondance est invisible : tout ce qui n’est pas LinkedIn/Facebook/Instagram va à la sortie 3, et si la sortie 3 n’est pas connectée, l’élément disparaît sans laisser de trace. Connectez le fallback à quelque chose qui vous alerte, même un simple nœud email disant « plateforme non routée : {{$json.targetPlatform}} ». Une branche par défaut silencieuse, c’est ainsi qu’un flux de travail vous ment.
La correction structurelle, et la raison pour laquelle cela s’est exécuté 183 fois sans être remarqué : un flux de travail dont le travail est de publier ne doit pas être autorisé à signaler Succès tout en publiant zéro message. Ajoutez une vérification explicite à la fin : si le nombre de publications est 0, levez une exception ou alertez. Et écrivez status=Published dans Base44 uniquement après que le nœud de plateforme retourne un identifiant de message, jamais avant, pour que la base de données ne puisse pas contredire la réalité.
Un Error Workflow vaut toujours la peine d’être ajouté pour tout le reste, mais notez qu’il ne capturera pas ce cas, car zéro élément n’est pas une erreur. C’est précisément pourquoi la garde zéro-publication doit être explicite.
