Self-serve Amazon SQS job launcher for support teams

Build me an internal job launcher app on top of Amazon SQS so support and ops staff can re-run backend jobs without an AWS account or a command line. The app has two clearly separate roles: admins author a small catalog of saved job templates, and everyone else picks a template, fills in a form, previews what will be sent, and submits it. Non-admins should never have to see or write raw JSON except in the read-only preview.

Admin-only template builder. Behind an admin-only section, let an admin create and edit job templates. A template has a name, a plain-English description of what the job does and when to use it, a target queue, a message body template, and a set of typed form fields. For the target queue, show a picker populated from the Amazon SQS List Queues action, then resolve the chosen queue with Get Queue URL and store the resolved queue URL on the template so runs do not depend on re-resolving the name each time. The message body template is a JSON body with placeholders that reference the form fields, for example {{customerId}} or {{reason}}. The typed form fields are defined by the admin: each has a key, a label, a type such as text, number, select with fixed options, or date, and a required flag. Admins can also mark a template as high risk.

FIFO queue handling. If the selected queue name ends in .fifo, the template must deal with message ordering. Require the admin to either map a form field to the message group id or let the app generate one per submission, and make the run form collect it when it is mapped to user input. Sending to a FIFO queue also needs a message deduplication id unless the queue has content based deduplication turned on, so read the queue configuration with Get Queue Attributes when the template is saved, record whether ContentBasedDeduplication is enabled, and generate a deduplication id per message when it is not. Do not let an admin save a FIFO template without a valid message group id strategy.

The catalog. Everyone else opens a simple searchable catalog of the published templates, showing name and description as cards, filterable by a search box. Clicking one opens the run form built from that template's typed fields, with validation on required fields and types. Below the form, show a read-only preview of the exact message body that will be sent, with the placeholders filled in from what the user typed, updating live as they edit. This preview is the only place a runner sees raw JSON.

Submitting a single run. On submit, deliver the resolved message body to the template's queue URL with the Send Message action, including the message group id and deduplication id when the queue is FIFO. Show the result inline with the returned message id, and clear success or failure state.

Bulk runs. Each template can allow a bulk mode where the user pastes a list of ids, one per line, into a designated field, and the app renders one message per id with the other form values held constant. Send these with Send Message Batch, and chunk the list into requests of at most ten entries each because that is the per-request limit, giving every entry a batch-local id that maps back to the row. A batch send can return overall success while individual entries fail, so always inspect the Failed array on every response and surface per-row status in a results table: each pasted id gets its own row showing sent or failed with the failure code and message. Never report a blanket success for a bulk run. Let the user retry just the failed rows.

High risk confirmation. When a template is marked high risk, the submit button stays disabled until the user types the template name exactly into a confirmation box, for both single and bulk runs. Show a clear warning explaining what the job does before they confirm.

Audit log. The app keeps its own persisted, searchable audit log of every submission. Record the template used, the fully resolved payload that was sent, the target queue, who ran it, the timestamp, whether it was a single or bulk run, and the outcome including per-entry failures for bulk runs. Give it its own page with search and filters by template, by person, and by date range, and let an admin open any entry to see the exact payload that went out. This log is the point of the app, so write the entry even when the send fails.

Slack notification. Post every submission to an ops channel using the Slack Bot Send a Message action so engineering can see what was triggered. Let an admin choose the destination channel in settings from a picker populated by the Slack Bot List Channels action. The message should name the template, who ran it, the target queue, the key field values, and for bulk runs the count sent along with the count failed.