Collect social post requests and schedule them in Hootsuite

Build me an internal post request desk that replaces the spreadsheet and email chaos of people across the company asking our social team to post something. Anyone at the company, a store manager, a recruiter, a sales rep, opens the app and submits a request. Our social manager opens the same app and works a queue of everything that has come in, edits the copy, picks the Hootsuite social profiles and schedules it.

Submitter view. A simple submit form with: what happened (a short description of the moment or news), a rough caption they would like used, an optional photo, which brand or region the post is for (a picklist I can edit), and the date they want it out. Below the form, a list of everything that person has submitted before with its current status, the final copy if the manager changed it, the accounts it went to, and the scheduled time once it is booked. Submitters only ever see their own requests.

Manager queue view. The same app opened by a social manager shows every incoming request, filterable by status and by requested date, sorted so the soonest requested dates come first. Opening a request gives a work card with the submitter, what happened, the requested date, the photo preview, and an editable copy field. From this card the manager can edit the copy, pick which Hootsuite social profiles to publish to, set the exact publish date and time, and hit Schedule. The manager can also decline a request with a short reason, which shows on the submitter's card.

Persistence. Store requests in the app database: id, submitter identity, description, original caption, edited caption, brand or region, requested date, media id and media processing state, per network variant drafts, chosen social profile ids, scheduled publish time, one row per resulting Hootsuite message id with its own per profile state, decline reason, and status. Statuses: submitted, in review, scheduled, partially scheduled, failed, published, declined.

Photo handling. When a submitter attaches a photo, a handler calls Hootsuite Create Media Upload URL to register the file and get back a media id plus a pre-signed upload URL, then PUTs the bytes to that URL with no Authorization header, since it is a pre-signed S3 URL and not a Hootsuite API call. The app then polls Hootsuite Retrieve Media Upload Status until the media is ready, showing a processing indicator on the request card. The Schedule button stays disabled while media is still processing. If scheduling ever comes back with error 40021, the media is not yet ready, so surface that plainly and let the manager retry rather than failing silently.

Profile picker. Populate the picker with Hootsuite Retrieve Social Profiles, grouped by network with the account name and network shown. Two rules to enforce in the picker: a Pinterest profile cannot be bundled with any other social profile in one scheduling call, so if Pinterest is selected alongside anything else, either block the combination with a clear message or schedule Pinterest as its own separate call. Twitter and X profiles have the same single network restriction (error 40023), so handle them the same way.

Scheduling. Schedule uses Hootsuite Schedule Message with the edited copy, the chosen profile ids, the publish time and the media id when there is a photo. Scheduling to several profiles creates a separate Hootsuite message per profile, each with its own message id, so store every returned id against the request rather than just the first. A partially failed request returns both data and errors in the same response, so show partial success explicitly on the card: which profiles were booked, which failed and why, and let the manager retry only the failed ones. If error 40025 comes back, the Hootsuite scheduled message limit has been reached, so say that in plain words instead of a generic failure.

State refresh. A handler calls Hootsuite Retrieve Message for each stored message id and shows the resulting state per profile on the request card, so the manager and the submitter can both see whether a post is still scheduled, has gone out, or failed after the fact. Refresh on card open and on a manual refresh button. Roll the per profile states up into the overall request status: all booked is scheduled, some booked is partially scheduled, none booked is failed.

Embedded background agent: Adapt for each network. Each request card gets an Adapt for each network button that kicks off a background agent. The agent takes the raw submission, the description, the submitter's rough caption and the brand or region, and rewrites it into per network variants that respect each platform's length and tone: a tight punchy version for X that fits the character limit, a longer narrative version for LinkedIn, a hashtag forward version for Instagram, and a warmer conversational version for Facebook. It writes those drafts back into the request record so the app can display them as editable fields the manager tweaks before scheduling. When the manager picks profiles, default each profile's copy to the matching network variant while still allowing a manual override. The agent only drafts, it never schedules anything.

Notification. Once scheduling succeeds, notify the original submitter over Slack: find them with Slack Bot Look Up User by Email using the email on their submission, then Slack Bot Send a Message as a direct message telling them their request is on the calendar, including the scheduled date and time, the accounts it is going to and the final copy. If the schedule was only partially successful, say which accounts were booked and which are still outstanding rather than claiming a clean success.

Permissions. Keep a manager list in an app settings screen (the app owner is a manager by default). Managers see the whole queue, every filter and the Schedule and decline actions. Everyone else sees only the submit form and their own request history, with no queue view and no scheduling controls.