What is wrong-account prevention?
Before a post publishes, Cenelira checks the saved destination account against the schedule's workspace and platform, and refuses when that account is missing or invalid.
Destination refusal
How Cenelira refuses an invalid publish target
Before a post publishes, Cenelira checks the saved connected account for the platform in the active workspace. If that account is missing, deleted, in another workspace or on the wrong platform, the schedule is refused with a named reason.
When you choose an account, the server can pick the one clear match for you. When more than one account matches, it refuses instead of choosing. This page describes both paths and names the proof fields that record the destination when a publish goes ahead.
Where is the refusal enforced?
It is enforced in the target identity flow. Choosing an account can pick the one clear match, while publishing a saved schedule needs an exact connectedAccountId and returns HTTP 409 with a named reason when the target needs repair.
What is out of scope?
It refuses at publish time only. It does not authenticate the platform user again when a post publishes, and it does not audit posts made before the account was connected.
Who this is for
Built for operators who know how a post reaches the wrong account
The refusals matter most in workspaces where more than one account, workspace or platform could plausibly be picked, and they matter less when there is only one of each.
For
- Agency operators publishing for multiple client workspaces where a cross-workspace slip would be visible to the client.
- Brand teams with more than one handle on a platform, such as a corporate handle and a product handle, who want Cenelira to refuse when the account is unclear.
- Ops leads who have already seen a post go to the wrong account and who want the refusal enforced in code rather than in process documents.
Not for
- Solo operators with exactly one handle on each platform. The resolver picks that account without asking, so these refusals rarely apply to you.
- Teams that want Cenelira to guess or to pick any account. Cenelira refuses instead of choosing.
- Workflows that want a publish attempted even when the destination is unverified. Cenelira refuses at publish time and never makes a best-effort attempt.
Mechanism
Two target checks and six repair reasons, each answered with HTTP 409
The target identity flow lives in src/lib/schedules/targetIdentity.ts. resolveConnectedAccountForPlatformSelection handles account choice and can auto-resolve one clear candidate. resolveScheduleTargetIdentity validates the persisted schedule target before execution. Repair cases use ScheduleTargetIdentityError with HTTP 409 and the shared error code target_repair_required.
- connected_account_required
At publish time the saved schedule has no connectedAccountId, so the publish is refused instead of a destination being chosen.
409 target_repair_required - connected_account_not_found
The saved connectedAccountId points at a row that no longer exists.
409 target_repair_required - connected_account_wrong_workspace
The saved account row exists but belongs to a different workspace from the schedule, and delivery across workspaces is refused.
409 target_repair_required - connected_account_wrong_platform
The saved account row exists but is bound to a different platform from the schedule.
409 target_repair_required - connected_account_missing_for_platform
No connected account exists for this workspace and platform, because the caller did not pass one and the workspace has none.
409 target_repair_required - connected_account_ambiguous_for_platform
Two or more connected accounts match the workspace and platform, and the caller did not say which one, so the resolver refuses instead of choosing.
409 target_repair_required
Proof record
The proof record shows the destination the server stored
When a proof export is generated, the record uses the schedule and connected-account state held on the server. The destination is read from stored publishing data rather than written separately.
Two columns in the 17-field proof record carry the resolved destination:
targetAccount stores the label of the destination account as the server resolved it. It comes from the schedule's ConnectedAccount relation and never from the caption text.
platform stores the platform identifier on the schedule. The export does not run target repair again, and it records the schedule and account state on the server for every schedule in the selected range.
The signed PDF and the unsigned CSV file both carry these columns. See the proof record schema for all 17 fields and how the PDF is signed.
What this does not claim
Where the refusals stop
A refusal at publish time is one check in a larger system, and this page says where that check stops.
- The connection is checked at publish time, but the resolver does not verify again the person who connected the account through OAuth.
- The resolver uses the external account id and label the platform returned when the account was connected, and it does not authenticate the platform user again on every publish.
- A workspace with exactly one account on each platform has that account picked for it without asking. The refusals apply when the exact account is unclear or missing.
- The scope is authorisation at publish time and the proof record. This page does not claim to audit posts made before Cenelira was connected to the account.
- External reviewer identity is a separate matter, and wrong-account prevention runs the same way whether the reviewer was internal or external.
FAQ
Short answers for operators
What exactly does Cenelira refuse?
It refuses for six named target-repair reasons, each returned as HTTP 409 target_repair_required when an account is chosen or a post publishes: connected_account_required, connected_account_not_found, connected_account_wrong_workspace, connected_account_wrong_platform, connected_account_missing_for_platform and connected_account_ambiguous_for_platform.
I have two accounts on the same platform in one workspace. What happens?
The resolver returns connected_account_ambiguous_for_platform when the caller did not say which account to use, and the schedule cannot move forward until an exact account is chosen.
What if a connected account was removed after the schedule was created?
The resolver returns connected_account_not_found and the schedule needs target repair before review or publish.
Does this cover external reviewers?
No. External reviewers approve a version of the content on a review link, while wrong-account prevention is a check at publish time. The two checks are independent, and both run.
Where does the proof record show the destination?
It is in the targetAccount and platform columns of the proof export. Both come from the schedule and connected-account state on the server, never from the caption or any other written copy.
Last reviewed 2026-04-24
Get notified when the wrong-account prevention checklist ships.
A short checklist on how to set up workspaces and connected accounts so the refusals keep matching your accounts. Leave an email and we will send it when the checklist is ready.