How the Posting Calendar handles scheduling, retries, and history

One planned post can have two different stories. The plan may still be scheduled while one destination is already trying to publish it. Or one destination may succeed while another fails.

The Posting Calendar model reviewed for this guide keeps those stories separate. A publication record says whether the plan is scheduled, paused, or skipped. A delivery record says what happened at each selected destination.

That difference explains the labels. "Posted" means every recorded destination returned success. "Partial" means at least one succeeded and at least one did not. "Publishing" means a handoff is still in progress. "Failed" can mean a known failure or an outcome that still needs checking.

This guide describes the reviewed state model. It does not promise that direct publishing, provider connections, retries, or history are available in the version your church can use. Before relying on it, ask to see the complete workflow with your own connected accounts.

The state glossary

The summary label is only the first layer. Open the item and inspect each destination before acting. A Partial item may contain one posted delivery and one failed delivery. A Failed item may contain a destination that says Reconciliation required, which calls for verification rather than a blind resend.

One publication can have several delivery results

Suppose a church schedules one approved sermon graphic for two destinations. The local publication record stores the planned item and time. Each destination gets its own delivery record.

If both destinations succeed, the calendar can show Posted. If one succeeds and the other fails, the summary becomes Partial. The successful post should not be sent again merely because its sibling failed.

This is why "the post failed" is often too vague. The useful question is, "Which destination has which state?"

The reviewed detail view can show these destination states:

• Scheduled means the delivery is waiting for its due time.
• Publishing means the delivery is being handled.
• Retry scheduled means another attempt is queued.
• Posted means the provider returned a successful result with a post identifier.
• Failed means the delivery reached a known terminal failure in the reviewed processing path.
• Reconciliation required means the result is uncertain and needs checking.
• Paused and Skipped are local control states.

Meta's official Instagram publishing documentation lists several container states. They include in progress, finished, published, error, and expired.

Those are provider states, not Church Media Kit labels. They show why a scheduling tool cannot reduce every handoff to a simple yes or no.

What to do when an item is Publishing

Do less.

Publishing is an active handoff, not an invitation to press another button. A second manual post can create a duplicate if the first request completed but its result has not reached the calendar yet.

Use this short wait check:

1. Open the destination account in its native app or website.
2. Check whether the post is already live.
3. Refresh the calendar once.
4. Record the destination and scheduled time if the state remains unresolved.
5. Escalate through the support path available to your account. Do not send the same item again until someone can classify the result.

Avoid inventing a recovery time. Provider processing and connection failures do not obey a church's content calendar. A reliable workflow has an owner for uncertain states and a fallback decision for time-sensitive posts.

How to handle Partial without creating duplicates

Partial is a mixed result. At least one destination is recorded as posted, so a whole-item retry would be the wrong mental model.

Start with a destination list:

The reviewed control path preserves destinations already marked posted when a failed sibling is retried. That is the right boundary. A retry should target unresolved work, not repeat successful work.

A safe recovery checklist for Failed

A retry is useful only when the cause can change. Pressing it against the same permanent restriction wastes time and may make the record harder to understand.

Work in this order.

1. Check the native destination first

Do not trust the local word "Failed" as proof that nothing went live. Buffer's current Facebook error guidance documents a case where a post may already be live even though the scheduling tool received an error. Buffer tells users to check Facebook before retrying.

That is vendor guidance for Buffer, not evidence about Church Media Kit. The operating lesson still holds. Verify an uncertain result at the destination before creating another public copy.

2. Read the destination-level state and error

Separate a known terminal failure from Reconciliation required. Then capture the destination, scheduled time, visible error, and whether a post exists natively.

Do not paste access tokens, credentials, private pastoral material, or full provider responses into a general support message. Share only the evidence needed to identify the failed delivery.

3. Check the connection and permissions

Social connections can expire or lose permissions. The person who owns the connected account should confirm that the account still exists, has the expected role, and has completed any provider security prompt.

Sprout Social's current post-failure guide lists disconnected profiles, missing permissions, provider restrictions, unsupported media, and outages among common checks. Use that list as a diagnostic pattern, not as proof of the error in another product.

4. Check the media and destination rules

Confirm the file type, dimensions, size, caption, alt text, placement, and account type against the destination's current rules. A retry cannot make unsupported input valid.

If the failure names an unsupported content type or destination, change the plan. Export the approved asset and use a supported handoff, or choose another destination. Do not keep retrying the same blocked request.

5. Choose retry, reschedule, or skip

Use Retry only when the destination is known failed and the cause is temporary or repaired. Use Reschedule when the message is still useful but the original moment has passed. Use Skip when the post is no longer timely, the reviewer withdraws approval, or the cause cannot be repaired safely.

The reviewed calendar includes a Retry failed destinations control for known failed deliveries. It does not establish a public retry count, delay, or success guarantee. "Retry scheduled" means another attempt is queued. It does not mean the destination accepted it.

Buffer's connection refresh guide makes a similar boundary visible in its own product. Refreshing a connection does not automatically retry failed posts. The user chooses what to retry. Church Media Kit buyers should ask for the same level of clarity in a live demonstration.

Pause, skip, and reschedule are planning controls

Pause and Skip change the local plan before a blocking handoff. They are not remote moderation tools.

The reviewed control path uses a five-minute lock before the planned time for ordinary pause, skip, and reschedule actions. Active publishing, uncertain reconciliation, and posted deliveries also block ordinary plan changes. These boundaries reduce the chance that a local edit races with an external request.

They also create an operating requirement. Do not wait until the last minute to withdraw a sensitive post. If a testimony, prayer request, child, counselling detail, or breaking event changes the approval decision, use the church's escalation path immediately and check the native destination.

A local skipped state does not prove that a provider-side post was removed. A local reschedule does not edit a post that is already live. Once a delivery has left the planning stage, verify its actual state at the destination.

What local history can and cannot prove

The calendar can help a team find planned items and their recorded destination states. That is not the same as a complete, immutable publishing archive.

The reviewed calendar reads publication and delivery records. Its current detail view does not expose a history archive action. This guide therefore does not present exact snapshots, permanent history, archive controls, or retention periods as ready product features.

If a local Hide or Archive control appears in a version you use, treat it as a local organizer unless the product states otherwise and proves the behavior. Hiding a record should never be interpreted as any of these actions:

• deleting or unpublishing a live provider post;
• deleting media already copied by a provider;
• removing a provider's logs, backups, caches, or other retained data;
• deleting every local thumbnail, file, attempt record, or support record;
• proving that an account-deletion request has completed across third parties.

Use the destination's own controls when the church needs to edit, remove, or unpublish something that is live. Follow the church's approval and incident process for sensitive content. Keep a separate record of who verified the external result.

What this guide does not promise

The state model is useful, but several buying questions remain open until a live demonstration answers them.

This guide does not claim:

• that direct publishing is enabled for your account;
• that any named social destination is connected and approved in the current release;
• that retries are automatic, capped at a stated number, or completed within a stated time;
• that an uncertain provider response resolves itself;
• that every failure produces a detailed or correct cause;
• that Posted proves continued visibility, correct audience, or complete content;
• that history is exact, complete, permanent, or covered by a working retention process;
• that local hide, archive, skip, source deletion, or account deletion changes a provider-side post;
• that scheduling improves reach, engagement, attendance, giving, or ministry outcomes.

These are not small footnotes. They decide whether the calendar fits a church that needs dependable multi-destination publishing, audit records, formal approvals, or remote content removal.

A live demonstration worth asking for

Bring one ordinary, approved static post and use accounts your church is allowed to connect.

1. Schedule it for two test destinations in the church's time zone.
2. Confirm the calendar shows the planned time and both destination records.
3. Pause it, then reschedule it while it is still safely outside the lock window.
4. Let one controlled test reach its due time and watch the destination-level states, not only the summary label.
5. Confirm a successful result in the native destination.
6. Ask how the system distinguishes a known failure from an uncertain result.
7. Ask the demonstrator to show a failed-destination retry without resending a successful sibling.
8. Ask where history comes from, what Archive changes, which media remains stored, and what happens to the live provider post.
9. Ask for the current retry policy, provider support, alerting path, retention policy, and deployment evidence in writing.

Do not use a polished sample that cannot fail. The useful demonstration includes one expired connection, one unsupported input, or one controlled provider error. Recovery is where a calendar earns trust.

Quick answers

What is the difference between Scheduled and Publishing?

Scheduled means the delivery is waiting for its planned time. Publishing means the handoff is active. Do not submit a second copy while Publishing remains unresolved.

What does Partial mean?

At least one destination is recorded as posted and at least one has another state. Confirm the successful destination, then work only on the others.

Does Failed always mean the post is not live?

No. The reviewed summary can also cover an outcome that requires reconciliation. Check the native destination before retrying.

Does Retry scheduled mean the retry will work?

No. It means another attempt is queued in the reviewed state model. It says nothing about provider acceptance or timing.

Does Posted mean the post is correct?

No. It records a successful provider result. Someone still needs to check the live account, audience, crop, caption, alt text, timing, and pastoral suitability.

Does Archive remove a live social post?

No. A local archive or hide action changes local organization only unless a separate provider action is clearly shown and verified. Use the native destination to manage a live post.

Should a church rely on this workflow before seeing a live demonstration?

No. Ask to see scheduling, destination states, one controlled failure, retry isolation, uncertain-result handling, history, and archive boundaries in the version your church would use.