An X publishing handover is complete when a brand owner can identify who owns the account, who may publish, which posts are already scheduled, who approves changes and which old access has been removed. A new writer seeing the content calendar is not enough. They need the live publishing state and a way to pause an incorrect post. The brand needs a recovery owner who stays in control after the working relationship changes.
This record is for a technical brand moving X content writing or publishing between staff, founders or an external partner. It covers scheduled content and account positioning, not customer support or direct-message work. A monthly X content audit helps decide what to improve; this handover answers who can carry out the next approved cycle.
Name the account owner and the publishing roles
Start with the account handle, brand entity and a named internal owner. That person should know where the login email, recovery methods and two-factor settings are controlled. Do not put passwords, backup codes or recovery secrets in a shared editorial document. The handover record should state who controls them, where the approved secure process lives and whom to contact if access breaks.
X’s Delegate guidance describes owner, admin and contributor roles and says collaborators can act without sharing the account password. The owner controls password, phone and login-verification settings. An admin can manage delegates; a contributor can publish but cannot manage delegates. Those are broad platform roles, so compare them with your actual approval process before inviting anyone. A person who can technically post is not automatically authorized to approve product claims.
Record three separate decisions: the person who confirms technical facts, the person who approves public wording and the person who presses publish or maintains the schedule. One person may hold more than one role, but write that down. When an agency drafts content, brand staff may still approve product availability, pricing statements or security claims. If there is no named approver for a claim, hold that item rather than treat an access grant as editorial approval.
The X two-factor guide explains login verification options. Have the owner confirm that recovery access works through the organization’s secure account process. This is an ownership check, not a request for a delegate to collect codes. The handover document can mark “owner confirmed” and the date without exposing the underlying credentials.
Capture the actual publishing queue
Open the platform or scheduling tool that will send the posts. List every item already scheduled for the next publishing cycle. For each, capture the account, scheduled time with time zone, working draft link, final saved text, media, destination URL, approval owner and edit or hold authority. A spreadsheet calendar may differ from the saved item; compare them rather than assuming they match.
Technical products change quickly. Mark any queued post containing a feature, access, launch-date or partner claim that needs reconfirmation. Check whether the destination still matches the promise in the post. If a launch link changed after scheduling, use the changed-destination preflight to decide whether to keep, revise or hold it. The incoming publisher should acknowledge each higher-risk item individually. A blanket “calendar received” sign-off hides unresolved claims.
Keep the content workflow visible. Record where approved source material lives, which voice guide is current, how drafts are named and what evidence supports recurring product statements. State the normal review deadline and the fallback if the approver is unavailable. If a post is time-sensitive, name the person authorized to cancel it. A handover should enable a safe stop as well as a scheduled release.
Use a decision table, not a password list
Hypothetical example: Alderline is a fictional developer-tool company changing its X publishing partner. The following table illustrates role decisions; it is not a Nowix client case or a measured outcome.
| Person or system | Publishing need | Access decision | Acceptance evidence |
|---|---|---|---|
| Brand account owner | Control login, recovery and final escalation | Retain owner control internally | Owner confirms security and recovery process privately |
| Product lead | Check product facts before release | Approve claims in the editorial workflow; X delegate access only if needed | Named approval on each material claim |
| Incoming publishing partner | Load, schedule and correct approved posts | Invite to the least privileged suitable X Delegate role for the agreed work | Invite accepted; one approved draft and saved queue checked |
| Outgoing partner and old scheduler | Finish transfer, then stop publishing | Remove unnecessary delegate and app access after acceptance | Owner records revocation date and checks remaining scheduled items |
“Least privileged” means the role with only the access needed for the assigned work. Test the permissions in the account’s current interface. An admin may be necessary for delegate management, but routine writing and scheduling should not receive admin power solely for convenience. If a third-party scheduler is used, review its connection separately from X Delegate. X’s connected-app guidance explains that app access can be reviewed and revoked in Apps and sessions. Removing a person from a document does not revoke a connected app.
Copyable handover record
Copy this structure into a private workspace and fill it with names, links and decisions. Keep credentials in the organization’s approved secret store, outside this record.
Account: handle, legal brand owner, internal escalation owner.
Current working roles: who confirms product facts, approves copy, schedules and may hold a post.
Access transition: outgoing delegates and connected apps; incoming invitation, role, acceptance date and owner confirmation.
Saved queue: each post’s scheduled local time and zone, saved item link, claim owner, final URL and approval status.
Source of truth: content calendar, voice notes, product evidence and media permissions.
Exceptions: unresolved claims, missing links or inaccessible scheduled items, with an owner and deadline.
Closeout: incoming publisher acknowledges queue; owner revokes obsolete access; owner signs off remaining schedule.
For the hypothetical Alderline handover, suppose a post promises a public feature that the product lead has not yet confirmed. The incoming partner can receive contributor access and prepare the draft, but that post remains on hold. The handover is accepted only when the product lead resolves the claim or removes it, the saved item is checked and the brand owner confirms old access removal. Nothing in that example asserts a real launch or result.
Close the handover with a live acceptance check
Ask the incoming publisher to find one approved draft and the current scheduled queue in the actual tool. Confirm they can perform the assigned action without gaining access they do not need. Ask the brand owner to verify the delegate list and connected apps after old access is removed. Record the date, the person who checked and any unresolved exception. Do not create a public test post simply to prove access.
Check that the account’s profile positioning and pinned post still match the current product, then assign any proposed changes through the same fact and copy approval path. The publishing handover should end with a clear next cycle: the first approved post, the reviewer, the scheduled time and the person who can hold it. A record without a next action often becomes an archive rather than a usable operating handoff.
Knowix works directly with product and marketing teams on X account positioning, content planning and publishing. If you need a partner to turn a technical product’s source material into an approved posting process, describe the account, the current publishing setup and the next campaign through the enquiry form below. Our X account management service explains the working scope. We can use the handover record to identify owners and missing approvals before the next publishing cycle; no access should be granted merely to start that conversation.
Frequently asked questions
Who should own a brand X account after a publishing handover?
Keep a named person inside the brand responsible for account ownership, recovery settings and final authority. Assign publishing roles to the people doing the work, and record who can approve and schedule posts.
Should an agency receive the brand account password?
Use X Delegate where it meets the workflow and available roles instead of sharing a password. The brand owner should control login and security settings; verify the actual permissions before work starts.
What happens to posts already scheduled during a handover?
Inventory each scheduled post, its account, time zone, link, approval status and person who can edit or hold it. The incoming publisher should confirm the saved items in the actual publishing tool.
When should old publishing access be removed?
After the new person has accepted access, a responsible owner has confirmed the publishing queue and a rollback contact is named, revoke roles and app connections that are no longer needed. Record completion without storing secrets in the handover document.
Does this handover cover replies and direct messages?
No. It records account ownership, approved content and publishing responsibility. Assign any separate support or moderation work through its own process.