PlacidWay content, turned into a safe daily Facebook post, automatically.

Runs once a day on a schedule. Also supports a manual run for testing.

• A Schedule Trigger fires daily at 09:00, using the workflow's own timezone (Asia/Manila).
• A header-secured webhook starts a manual run. The admin panel here calls it, with optional mode, content-type and dry-run overrides.

Collect content: title, URL, summary or body, and featured image if available. Justify the method.

• All four PlacidWay content types, each from its own public sitemap: blog articles (≈5,100), treatment packages (≈3,900), clinic profiles (≈1,350) and patient Q&A (≈4,500). One request returns every URL with its last-modified date.
• Then a single HTML fetch of the chosen page. Open Graph meta gives title, summary and a 1200×630 image. JSON-LD gives structured Article, Product and FAQ data. Paragraphs inside <main> give the body.
• No headless browser: pages are server-rendered, so a browser would only add cost and load on PlacidWay.

Pick one item per run and never post the same URL twice. Keep a simple store of what was posted.

• Postgres is the store. The workflow excludes every URL that is published, publishing or awaiting approval.
• A partial unique index on posts(source_url) rejects a duplicate even if two runs race.
• Dry runs, rejections and failures don't consume a URL, so a bad draft doesn't burn good content.

LLM-written post: a hook, 2–4 lines of value, a CTA, the link and 3–5 hashtags, under 500 characters before the link.

• Gemini returns structured JSON (hook, lines[2–4], cta, hashtags[3–5]) against a response schema, so the shape can't drift.
• The prompt gives the model only the extracted page as facts, plus a PlacidWay brand brief researched from their public site, press and social channels: calm, warm, no hard sell, soft CTAs like "Request a free quote", and #PlacidWay #MedicalTourism plus topic tags.
• The workflow assembles copy, then the link, then the hashtags, and enforces under 500 characters before the link.

No medical claims, no outcome promises, no invented prices, no facts that aren't on the source page. Add a check and explain it.

• Rule check (deterministic): blocks claim words such as cure, guarantee, 100%, risk-free, painless, permanent and "will fix". Every number and currency amount must appear in the source text. Also checks structure, length and hashtag count.
• LLM fact check (second pass, temperature 0): a reviewer prompt lists unsupported claims, prices or outcomes. If its output can't be parsed, the post fails.
• Both checks must pass. One rewrite is allowed, with the violations fed back. After that the post is blocked and an alert is raised. Nothing unchecked is published.

Post to a test Facebook Page, or schedule. Include the image when one exists.

• Two publishing methods, switchable in Workflow settings. Posting agent (default): the run ends Ready to post, and a posting agent with its own browser, logged into Facebook once, posts the caption and image. It declines Facebook's upsell pop-ups and reports success only after it finds the post live on the Page.
• Graph API: /{page-id}/photos with the image and caption, or /{page-id}/feed with the link, using a Page token stored as an n8n credential (never in the workflow or git).
• A manual fallback is always on the Ready card: Copy caption, Open image, Open Page, then Mark as posted with the link.

A config flag switches between auto-publish and approval mode, where a reviewer approves the draft first.

• config.default_mode = auto | approval. Manual runs can override it per run.
• In approval mode the run pauses on an n8n Wait node. The draft appears in this dashboard's approval queue, and Approve or Reject resumes the run. Drafts expire after 24 h.

Log each run (item, post text, Facebook post ID, status). Retry sensibly and alert on failure; never fail silently.

• Every run writes a runs row first, then posts and content rows, so even a crash leaves a trace.
• Every external call retries: sitemap and page 3× at 3 s; Gemini 3× at 5 s; Graph API 3× at 5 s.
• A dedicated Error Handler workflow classifies failures (SITE_UNREACHABLE, LLM_ERROR, FB_TOKEN_EXPIRED, …), marks the run failed and raises an alert that this dashboard shows as a banner.