DEV Community: Workflow Field Guides

Stop Publishing “Here Is Your Caption”: Validate Gemini Output in Make

Workflow Field Guides — Wed, 30 Sep 2026 13:31:27 +0000

You ask Gemini to adapt one Airtable draft for Instagram, Pinterest, and Threads. Most runs look fine. Then a platform gets this as its caption:

Sure! Here is an engaging Instagram caption for your brand:

Or a blank string. Or a plausible sentence with an invented discount. A scheduled workflow can publish all three without anyone seeing the problem first.

The fix is a small contract between the AI step and the publishing step: request structured fields, parse them, then check them before posting. This is a separate issue from duplicate prevention; each platform can publish exactly once and still publish bad copy.

Start with a narrow output shape

For one destination, request a JSON object like this:

{
  "caption": "A complete, ready-to-publish caption",
  "cta": "A call to action supported by the source draft",
  "needs_review": false,
  "review_reason": ""
}

Make caption, cta, needs_review, and review_reason required in the schema. Use a separate request or schema per platform if their fields differ. For Pinterest, you might use title and description; for Instagram, caption may be enough. Avoid one giant object with many optional fields that every later module must guess how to use.

Google's Gemini API supports structured output with a JSON schema. The exact setting depends on the API or Make module you use. If that module exposes a response format or schema control, use it. If it does not, a prompt asking for JSON is only an instruction to the model, not a format guarantee; parse and reject bad results before the publish module. Google documents a supported subset of JSON Schema, so keep the schema simple and test it against the model you select.

Tell the model what it may use

An example instruction for the Instagram step:

You write an Instagram caption from the source fields below.
Return only the fields in the configured JSON schema.
Use only facts, prices, offers, links, and product claims present in the source.
Do not invent a discount, testimonial, deadline, or result.
If the source lacks a fact needed for a safe caption, set needs_review to true,
explain the missing fact in review_reason, and keep the caption empty.
Do not add an introduction such as "Here is your caption".

Title: [map Airtable Title]
Source draft: [map Airtable Caption]
Approved CTA: [map Airtable CTA]

Map fields with Make's mapping controls; do not paste actual account keys or private customer details into a reusable prompt. An empty caption is acceptable only when the scenario routes it to review instead of publishing.

Put checks between Gemini and the social module

In Make, parse the Gemini response as JSON, or use the module's structured fields when it returns them directly. Define the expected Make data structure so downstream mapping is explicit. Then use a filter before the publishing module:

needs_review must be false.
caption must be nonempty after trimming whitespace.
The text must fit the destination's current limits, which you should verify in that destination's own module or documentation.
Required source facts or approved link must still be present if your workflow depends on them.

Route anything else to a review queue in Airtable. Save the generated text and a reason such as empty caption, invalid JSON, over length, or unverified claim. Do not use a Skip handler as your sole quality control: dropping a failed bundle does not explain what needs editing.

For a higher-risk claim, add human approval even when the JSON parses. A schema can constrain shape; it cannot prove that a discount exists, a health claim is accurate, or a link points to the intended product. This is a business rule, not a parsing rule.

Test deliberately bad inputs

Create three test Airtable records before scheduling:

Source draft	Expected behavior
Clear product facts and an approved CTA	Valid caption reaches the test publishing step
Missing offer details but asks for a discount	needs_review or a failed business-rule check; no publish
Empty draft or malformed AI response	Review queue receives a reason; no publish

Inspect the actual Make bundles after Run once. Check the parsed field mapped into the social module, not just the AI module's raw response. The best evidence is a test post on a controlled account and a corresponding Airtable result.

The goal is modest but important: an AI caption should have to pass a visible gate before the social API sees it. That gate does not make the writing perfect. It makes broken or unsupported output easier to catch and fix.

I also made Small Budget, Big Results: SMM Automation Guide, a $15 guide with a 15-page PDF, an edited Make blueprint, and a setup checklist. It covers the broader Airtable → Make → Gemini workflow. The blueprint is a setup-required example: connect your own accounts, map fields, add your validation and retry rules, and test before scheduling.

How to Prevent Duplicate Social Posts in an Airtable Make Workflow

Workflow Field Guides — Wed, 30 Sep 2026 13:08:16 +0000

A practical pattern for scheduled content with retries and partial failures.

You schedule a post in Airtable. Make finds it, publishes it to Instagram and Pinterest, and then updates the record. It works—until Pinterest fails after Instagram succeeds. On the next run, the same Airtable record is still eligible. If the scenario starts from the beginning, Instagram gets a duplicate.

The fix is to track the record's overall state and each destination's state separately. You also need to decide what happens when publishing succeeds but the status update fails. No simple filter can make a social platform and Airtable update atomically.

1. Set up the Airtable fields

In a Posts table, use these fields (adapt the names to your base):

Field	Type	Example
`Title`	Single line text	`Three ways to simplify scheduling`
`Caption`	Long text	Source copy for the post
`Publish Date`	Date with time	A scheduled date and time
`Image URL`	URL	A publicly accessible image
`Status`	Single select	`Ready`, `Processing`, `Needs Review`, `Published`
`Instagram Status`	Single select	`Pending`, `Published`, `Failed`, `Uncertain`
`Pinterest Status`	Single select	The same choices
`Threads Status`	Single select	The same choices, if used
`Instagram Post ID`	Single line text	ID returned by the publisher, if available
`Pinterest Pin ID`	Single line text	ID returned by the publisher, if available

Only add columns for platforms you actually use. Keep the platform post IDs or URLs when the publishing modules return them. They are useful when a timeout leaves the result uncertain.

2. Search for posts that are due

In Make, start with Airtable → Search Records. Use this Airtable formula:

AND(
  {Status} = "Ready",
  {Publish Date},
  {Publish Date} <= NOW()
)

Sort by Publish Date ascending and start with a limit of one record per scheduled run. Set the Airtable field to include time, and check the base, field, and scenario time zones with a test record near midnight.

TODAY() is the wrong boundary for a timed schedule: it provides the date, not the current time. NOW() includes time, but Airtable does not guarantee a real-time refresh; its documented recalculation cadence can delay eligibility. If you need precise minute-level delivery, use a scheduling mechanism designed for that precision and test its behavior. See Airtable's date-function reference.

For a simpler existing base with an Is Published checkbox, AND({Is Published} = 0, {Publish Date} <= NOW()) is a reasonable eligibility filter. It is not a complete duplicate-prevention system.

3. Claim the record before publishing

After Search Records, use Airtable → Update a Record with the ID returned by the search. Set Status to Processing before reaching any social publishing module.

That keeps a later scheduled search from treating the record as Ready while an earlier run works on it. Run one worker for this queue and avoid manually starting a second copy of the scenario at the same time. Search followed by update is not an atomic lock: two overlapping runs could both read Ready before either writes Processing. For strict concurrency guarantees, use a store or queue with an atomic claim and a unique key for each post/destination; do not present this Airtable-only pattern as exactly-once delivery.

4. Record the result of each platform

Create your platform routes in Make. Before each publishing call, filter out a destination whose status is already Published. After a confirmed successful call, update its platform status to Published and save the returned post ID or URL. On a confirmed failure, mark that destination Failed and keep the other destinations' results. Test each error path: a failed module can prevent a normal update module after it from running.

Do not mark the whole record Published just because the first branch finished. A final Airtable update should set Status = Published only after every required destination has a confirmed success. If a platform failed or its outcome is unknown, set Status = Needs Review instead. Make's Router routes cannot be reconnected: use a separate finalizer run that reads every platform status, or design a sequential path with explicit error handling. Do not place an unconditional Published update at the end of any one branch.

Instagram	Pinterest	Overall status	Next action
Published	Published	Published	Stop
Published	Failed	Needs Review	Retry Pinterest only
Uncertain	Published	Needs Review	Check Instagram before retrying

An error handler that merely skips a failed module can make the scenario appear complete while a platform remains unpublished. Make's error-handling and incomplete-execution settings deserve explicit testing; see Make's scenario settings and incomplete-execution options.

5. Treat timeouts as uncertain, not failed

A publishing request can reach a platform successfully, then time out before Make receives a response. Repeating it automatically may produce a duplicate. Mark that platform Uncertain; inspect the platform account or query the published item if your integration supports that. Retry only after you establish that the post was not created.

This is also why a fixed five-second sleep is not a duplicate-prevention strategy. A delay can help with a specific timing problem, but it cannot tell you whether a prior publish request succeeded.

6. Test the failure path

Before turning scheduling on, use test posts and run these cases:

A future record must not be selected; a due Ready record must be selected.
A successful publish on all required platforms must end with Published.
If the second platform fails after the first succeeds, the first must remain Published and the record must become Needs Review.
A retry must skip the platform that already succeeded.
A timeout with an unknown outcome must stop for verification rather than immediately republish.
Two overlapping manual or scheduled runs must not be assumed safe; test your concurrency controls before increasing throughput.

The goal is recoverable publishing: each result is visible, and a failure does not silently reset the entire workflow. This pattern greatly reduces accidental duplicates, but neither Airtable nor a generic social API gives an automatic exactly-once guarantee across systems.

Disclosure: I created Small Budget, Big Results: SMM Automation Guide, a $15 guide with a PDF, an edited Make blueprint, and a setup checklist. The blueprint requires you to connect your own accounts, map your own fields, add retry filters, and test before scheduling. This article is free and self-contained; the guide covers the broader Airtable → Make → Gemini workflow.