Which posts should share one campaign?
A cross-platform campaign should share one objective and source idea, not necessarily one identical post. Group posts together only when they promote the same event, launch, offer, or editorial moment and can be reviewed as one unit.
Create a campaign record with a working name, owner, target date, source copy, destination accounts, and approval state. Then create a separate post for every account that needs a different caption, format, link treatment, or call to action. This structure prevents a late edit for one network from silently changing every other version.
A solo founder might create one campaign for a product announcement and prepare three channel versions. An agency operator managing multiple social accounts might create one campaign for a client, then split it into several brand and network jobs. The campaign is the planning container. The post is the delivery unit.
The useful decision rule is simple: combine work when the message and approval are shared, but separate work when publishing, compliance, or reporting differs. A single “publish everywhere” button can still be useful, but it should create visible, independently trackable jobs underneath.
How do I turn one idea into platform-ready posts?
Start with a canonical draft, then produce channel variants before scheduling anything. The canonical draft should contain the approved claim, destination link, media reference, disclosure language, and call to action. Variants should change only what the destination requires or what the audience needs.
Keep three fields distinct: the source message, the rendered caption, and the final payload sent to a platform. That separation makes it possible to identify whether a problem came from the brief, the adaptation, or the publishing step. It also gives a developer or AI agent a clear boundary for editing.
Do not assume that shortening a caption is enough to adapt a post for each network. A useful variant may need a different opening, link placement, mention, media selection, or call to action. Preserve the campaign identifier across every variant so operators can compare them later without confusing separate posts.
Require a human review when the variant changes a price, promise, legal statement, target audience, or destination. Automation can produce drafts quickly, but approval should focus on meaning, not merely grammar. The safest workflow lets an operator see both the canonical draft and each final version before scheduling.
Which time should each account use?
Schedule each delivery job in the destination account’s intended time zone, not in the operator’s browser time zone. Record the time zone beside the account and display the resolved local date and time before approval.
A campaign planned for a morning launch may cross midnight for another account. If the system stores only a clock time, daylight-saving changes and regional differences can move a post to the wrong day. Store an explicit time zone with the scheduled timestamp, then show the converted time for the person approving the work.
Separate campaign timing from account timing when the same event reaches multiple audiences. For example, a client may want a launch announcement to appear at a local morning for each regional account rather than at one global instant. That requires several delivery times under one campaign, not one timestamp copied everywhere.
Include a visible rule for late scheduling. If an operator changes the campaign date, the system should show which jobs move, which retain their original time, and which have already entered publishing. Ambiguous rescheduling is a common source of duplicate posts and accidental early announcements.
What should happen before a post enters the queue?
A post should enter the publishing queue only after its account, media, copy, permissions, schedule, and approval state have passed explicit checks. A green calendar entry is not enough if the destination account is disconnected or the media is unavailable.
Use a preflight record for every delivery job. It should identify the destination account, intended time zone, final text, attached media, link, approval owner, and current connection state. For developers, the record should be inspectable without opening application logs. For operators, the same information should appear in a compact review screen.
Preflight should catch missing media, unsupported content combinations, expired authorization, duplicate campaign jobs, and a schedule in the past. It should also distinguish a warning from a blocking failure. A long caption may need review, while a missing required asset should prevent queuing.
The strongest rule is to freeze the approved payload at queue time. If a shared draft changes afterward, the queued job should either remain unchanged or return to review. Quietly replacing approved copy creates an audit problem and makes it difficult to explain what the operator actually authorized.
How should a system represent each publishing job?
Represent every account and platform destination as an independent job with its own lifecycle, even when an operator schedules them from one campaign screen. A campaign can be ready while one destination is blocked, delayed, or already complete.
Useful states include draft, awaiting approval, scheduled, publishing, confirmed, needs attention, cancelled, and expired. The names can differ, but the transitions must be clear and one-way where appropriate. A confirmed job should not silently return to scheduled because another channel failed.
Store the planned time, actual attempt time, final payload version, destination identifier, operator action, and latest result for each job. A developer wiring an integration or AI agent should be able to ask which jobs are waiting, which require a decision, and which are complete without interpreting free-form notes.
Campaign-level status should summarize the jobs rather than hide them. “Partially complete” is more useful than “published” when four destinations succeeded and one still needs attention. This model also makes billing and capacity easier to understand because operators can see which connected destinations consume scheduling work, rather than treating a campaign as one indivisible action.
When should a failed destination be stopped?
Stop a destination when the next action could create a duplicate, violate approval, or repeat a condition that requires human intervention. Continue other independent destinations when their approved payloads and permissions remain valid.
A missing connection, changed account permission, rejected media type, or invalid destination should place that job in an attention state. The operator needs a plain explanation, the affected account, the approved payload, and a safe next action. The system should not keep attempting the same job simply because the campaign remains active.
A temporary publishing problem calls for a different decision. The system may continue within its defined policy if the job has not been accepted and repeating it cannot create a duplicate. If acceptance is uncertain, stop and ask for reconciliation instead of sending again. The right response depends on whether the platform could have received the post, not on the fact that the first attempt looked unsuccessful.
For AI agents, expose a permitted action set such as pause, reschedule, cancel, or request review. Do not let an agent invent a new caption or change a destination while handling a failure unless the campaign policy explicitly allows that action.
How do I control cost when many accounts are connected?
Control cost by measuring active destinations and publishing jobs separately from campaigns. One campaign sent to several accounts creates several operational obligations, even when the operator wrote only one brief.
Before connecting an account, define its business purpose, owner, expected posting frequency, and review requirement. Remove dormant destinations from active workflows instead of leaving every historic connection in the working set. A freelancer with five clients should be able to see which client accounts are active, paused, or no longer billable without searching through old campaigns.
Show the cost or capacity consequence at the point where an operator adds a destination. A simple confirmation can state that the campaign will create another independent scheduled job. That is more useful than showing a total after the schedule has been saved, when the operator may not understand why the charge or usage changed.
Use one approval and asset library where appropriate, but do not pretend shared planning eliminates destination work. Each account still needs its own permissions, content variant, schedule, and result. The practical trade-off is clear: centralization reduces coordination effort, while separate jobs preserve control and accurate accounting.
What should an AI agent be allowed to do?
An AI agent should prepare, explain, and organize scheduled publishing, while a human or explicit policy controls irreversible actions. The agent needs structured campaign data, destination identities, approval rules, time zones, and a clear record of what it changed.
Safe agent actions include drafting channel variants, identifying missing fields, proposing local times, grouping related jobs, and summarizing attention states. Scheduling may be allowed after approval, but the agent should show the exact final text, media, destination, and time before committing. Publishing and cancellation deserve stronger controls because they affect external accounts.
Give the agent narrow tools with named inputs and predictable results. A tool should accept a destination job rather than an ambiguous instruction such as “post this everywhere.” The response should identify the job, current state, and next permitted action in language an operator can understand.
For developers, preserve an audit trail of agent requests, approvals, payload changes, and operator overrides. For operators, provide a manual escape hatch that does not require reconstructing state from a chat transcript. A useful agent makes uncertainty visible. It should ask for a decision when account identity, approval, timing, or delivery state is unclear.
Sources consulted: Meta for Developers (developers.facebook.com) · X Developer Platform (developer.x.com) · LinkedIn Developers (developer.linkedin.com) · TikTok for Developers (developers.tiktok.com)
Common questions
Can I use one caption for every platform?
You can, but one caption should be treated as a source draft rather than an assumption that every destination is identical. Review mentions, links, media, calls to action, disclosures, and length for each account. Create separate final variants whenever a destination or audience changes the meaning or presentation.
What is the safest way to schedule across many accounts?
Create one campaign with separate delivery jobs for each account. Give every job its own final payload, time zone, approval state, connection state, and result. This lets successful destinations proceed without hiding a blocked one and prevents a single campaign status from overstating what actually happened.
Should all platforms publish at the same time?
Only when the campaign requires one coordinated moment. Otherwise, schedule each account in its intended local time zone or according to its audience plan. Show the resolved date and time for every destination before approval, especially when regional accounts may cross midnight or observe seasonal clock changes.
How should an AI agent handle an uncertain publishing result?
An AI agent should pause the affected job when repeating it could create a duplicate. It should show the destination, approved payload, attempt time, and available evidence, then request reconciliation or human review. The agent should not rewrite the post, change accounts, or keep trying simply because the campaign is incomplete.
Do platform publishing rules stay the same?
No. Permissions, supported content, review requirements, quotas, and account eligibility can change by platform and over time. Check each platform’s current developer documentation before building or revising an integration. Treat the documented capability as a dependency that needs periodic review, not as a permanent product assumption.
PostWharf is priced per workspace rather than per connected channel, and every plan carries unlimited channels. See per-brand pricing.