Your automation history shows one successful run and one output bundle. Facebook shows two posts.

That evidence rules out some simple causes, but it does not prove which system duplicated the write. The safest next step is not another retry. It is to preserve both provider originals and build one evidence row for every write that may have reached Facebook.

This checklist is for the specific case where an Airtable, Make, n8n, or custom workflow appears to run once while a Facebook Page receives duplicate posts.

The short answer

Before changing the scenario, record:

  1. the automation execution ID and exact start/end time
  2. every input bundle or source-record ID
  3. retry, incomplete-execution, and timeout history
  4. every Facebook post ID and permalink
  5. the public timestamp and rendered content of each post

If the two Facebook posts have different provider IDs, there were two provider-side creates even if the automation UI summarizes the work as one run. The remaining question is where the second create originated: another trigger, an automatic retry, a timeout recovery, a provider-side duplicate, or a separate client using the same source record.

Do not label the cause until the evidence distinguishes those paths.

1. Preserve both public originals first

Open both Facebook posts before deleting or editing either one. For each post, capture:

  • Page identity
  • provider post ID
  • permalink
  • published timestamp
  • exact caption and media
  • any visible author or publishing attribution

Compare the text and media fingerprint. Two identical captions do not prove that the same request was replayed; two independent clients can send the same source record. Two different provider IDs do prove that the provider accepted two creates.

If only one permalink is available and the second post is still visible, preserve a screenshot and the public timestamp while you investigate. Mark the missing ID as unknown.

2. Separate a scenario run from a provider write

A green automation run means the orchestration completed under that platform's rules. It does not necessarily mean one external write occurred.

Make documents that connection, rate-limit, and timeout failures can be retried through incomplete executions and exponential backoff. Its documentation also notes that actions in non-transactional external apps cannot be rolled back. A provider create may therefore succeed even when a later client step times out or loses the response.

Check these separately:

Layer Evidence to collect What it can prove
Trigger schedule/webhook time and trigger ID how many runs were started
Source Airtable record ID and input bundle count how many records entered the flow
Create module module operation, start/end time, raw output how many provider calls the platform recorded
Retry system incomplete executions, automatic retry, backoff history whether a failed or ambiguous call ran again
Facebook every post ID and permalink how many public provider objects exist

Do not collapse these five rows into “the run succeeded.”

3. Check for hidden second triggers

Before blaming Facebook, eliminate the causes you can control:

  • another scheduled scenario using the same Page
  • an instant webhook plus an hourly search
  • a second workspace, environment, or old scenario
  • two source records with the same content
  • a manual post made from the Page or Business Suite
  • a polling window that selects a record again before its status update is visible

Use stable identifiers, not only timestamps. Record the automation scenario ID, source-record ID, content fingerprint, and destination Page ID in the same row.

If two workflows share a source table, add a destination-specific claim or lock before the provider create. A time buffer alone is not an idempotency guarantee.

4. Treat a slow response as ambiguous

A long-running Facebook module is important evidence, but it does not identify the cause by itself.

If the provider accepted the post and the client timed out before receiving the response, an automatic retry can create another post unless the integration reconciles the first result. If the module returned one provider ID while two posts exist, preserve the unmatched post ID and ask which actor created it.

The safe rule is:

A timeout or lost response is unknown, not failed, until the destination is checked.

Pause automatic recovery for that destination when any provider ID or matching public post already exists.

5. Build a two-post evidence ledger

Use one row per provider object:

destination_page_id:
source_record_id:
automation_execution_id:
create_module_operation_id:
retry_or_incomplete_execution_id:
provider_post_id:
provider_permalink:
provider_timestamp:
content_fingerprint:
public_outcome:
observed_in_automation_output: yes | no | unknown

For two Facebook posts, the ledger should contain two rows even if the automation platform exposes one run. The unmatched fields show where the investigation needs stronger evidence.

6. Add a destination-scoped recovery gate

Before a create or retry, check the existing record for that Page:

  1. Is there already a provider post ID?
  2. Is there a stored permalink?
  3. Does the public Page contain a matching content fingerprint in the expected time window?
  4. Is an incomplete execution still eligible to retry the create module?

When the outcome is ambiguous, move the item to manual reconciliation instead of creating again. When a multi-channel batch partially succeeds, retry only the unresolved destination after checking its own provider state.

This gate does not guarantee that every provider exposes an idempotency key. It prevents your recovery logic from treating missing client confirmation as proof that nothing was created.

A real partial-success warning from another network

In a separate ANKK Threads incident, one scheduled root was published and the reply step encountered a provider-unavailable result. Automatic recovery produced two identical public replies even though the operator made no manual retry. The provider originals and stable content and job IDs were preserved for the product investigation.

That Threads incident does not prove the cause of a Facebook duplicate. It demonstrates the general failure boundary: once any segment may have reached the provider, recovery needs provider reconciliation at that segment rather than a blind replay of the whole operation.

Sources and next steps

I operate ANKK. ANKK does not include a built-in AI writer. It connects content prepared by people, external AI tools, or scripts to social scheduling, channel-level states, and provider-original verification.

Review the ANKK developer workflow