Submissions Inbox

Open CoreX → Submissions to work with the responses stored by published flows. The Inbox is distinct from the raw Data explorer: it owns team workflow, personal-data controls, related email actions, and the submission timeline.

Find and work a response

Search by the sender’s name or email, or by the form, and combine flow, status, owner, and date filters. The search looks at the sender the row shows and at the form’s name; it does not look in the other answers. Marked tests are hidden by default; turn on Include marked tests only when diagnosing the real seven-stage flow pipeline. Every list count and detail request uses the current actor’s record scope, so inaccessible records do not leak through counts, filters, or direct IDs.

Click anywhere on a row, or press Enter on it, to open the submission in a pane beside the list. The row that is open stays marked. Escape or Close shuts the pane and puts focus back on the row.

The pane reads from the top down:

The header: the sender’s name, their email address and phone number as links when the form asked for them, the form, the submission’s number, when it arrived, its status, and whether it is read.
Answers, each under the question the form asked. An answer to a question the form no longer asks is kept, under the key it was stored with.
Reply and Team notes.
Triage: the status, and Assigned to, which lists the people who can manage submissions, and Unassigned.
Notification: what became of the notification, when, and the reason when one was recorded.
Technical details, closed until opened: hidden fields, campaign data and the consent record, whichever of them the submission holds. A submission that holds none of them says so on one line.
History, closed until opened: what happened to the submission, and when.

Opening an unread submission marks it read. Mark unread in the header puts it back, for somebody who only looked.

Change the status to New, In progress, Replied, Closed, Spam, or Archived. Read, status, and assignment writes are optimistic: if another teammate changed the response after it loaded, CoreX returns a conflict and asks the Inbox to refresh instead of overwriting their work.

Bulk actions

Select up to 100 visible rows, then preview Mark read, Assign, Mark spam, Archive, or Move to trash. The preview is bound to your user, the exact selected IDs, and their update timestamps; it expires after five minutes and can be applied once. If any row changes or becomes inaccessible, the whole action stops before mutation rather than silently applying a partial result.

Move to the trash, and restore

To take a submission out of the inbox, open it and choose Move to trash under Triage, or tick several rows and choose Move to trash from the bulk actions. Either asks first and says how many submissions will leave the inbox. The notice that follows has Undo, which puts them back.

Trash, beside Inbox above the filters, shows what was moved there, with who moved each submission and when. The filters and the search work on it as they do on the inbox. A trashed submission leaves the inbox, its counts, the exports and the Data screen’s records. It keeps its status, owner, notes and history.

A submission in the trash can be read and nothing else: there is no reply, no new note, and no status or owner to change until it is restored. Open it and choose Restore, or tick several and restore them as a bulk action, the only one the trash offers. It goes back to the inbox as it was. Its history records who moved it to the trash and who restored it, and the activity stream records each action once, with how many submissions and none of what they hold.

You act only on submissions you may see, in the trash as in the inbox.

A submission in the trash is deleted for good after a number of days: 30, unless the site sets another. The Trash view says so above its list, and each row shows the day that submission will go. Set the number under Submission retention, in Keep in the trash for days; 0 keeps a trashed submission until somebody restores or deletes it. The daily clean-up deletes what is due, with everything a deletion by hand removes, and records it in the activity stream as the trash’s own doing.

WordPress empties its own trash too, for every kind of post. It does not empty this one: a submission leaves the trash on the day the Trash view shows and not before.

Delete for good

A submission is deleted for good from the trash, and only from there: move it to the trash first. Open a trashed submission and choose Delete permanently, or tick several in the Trash view and choose Delete permanently from the bulk actions.

The confirmation says how many submissions will be deleted and lists what goes with each:

the answers, with any hidden fields, campaign data and consent record;
team notes and the history of what was done;
files that were uploaded with it, from the server’s disk;
the records and captured copies of emails sent about it, where Email Studio is installed.

It cannot be undone, and the action stays disabled until I understand this cannot be undone is ticked.

Two things are not removed, and the confirmation says the first where it applies:

Export files made earlier. A file you exported before may still hold the submission. Each is kept 30 days from the day it was made, and can be deleted sooner under Export, Recent exports.
Rows of the mail log. The log of mail sent outside Email Studio records a recipient and a subject and is not tied to a submission, so a row that names the submitter is left to the log’s own retention.

If a file uploaded with a submission cannot be removed from disk, that submission is not deleted: it stays in the trash, and the notice says how many were not deleted. The others in the same action are.

Deleting for good needs a permission of its own, apart from managing submissions. Administrators have it. It can be granted to somebody else under Access & Abilities, as the ability to run actions that cannot be undone. Somebody without it can restore from the trash and is told why they cannot delete.

The activity stream records each deletion once: who, when, how many, and of which forms. It holds nothing the submissions said. A submission’s own history is deleted with it, so this entry is the only record that it existed.

Notification delivery

Every row shows the notification outcome of its submission, and the pane repeats it with a safe reason and the time it was attempted. The states are distinguished by text and icon, never colour alone:

Notification accepted — the mail path accepted the message for delivery. This is not proof it reached an inbox.
Notification captured — a development capture stored it instead of sending externally.
Notification queued — a real queue accepted the job; delivery has not completed.
Notification failed — an attempted delivery failed. A resend may be available.
Notification rejected — routing, policy, or configuration prevented an attempt.
No notification — none was required or configured for this form.
Not tracked — no delivery was recorded for the submission. A form defined in code sends its notification without recording it, so every one of its submissions reads this way; so does a submission stored before delivery was tracked. The pane says which.

A saved submission with a failed notification is still saved and still readable — the failure is surfaced, never hidden. The timeline records a notification event alongside the submission event, so the outcome is visible in the history.

Reply

When the submission holds an email address, the pane’s Reply section sends an answer to it. The reply is typed as plain text: a blank line starts a new paragraph, and a line break is kept.

Whether a reply is delivered

The section says, before anything is typed, when a reply from this site will not reach the person who wrote:

Replies are not being delivered. A production site delivers a reply only when CoreX → Settings → Mail has a Delivery provider chosen and Enable live delivery ticked. Until both are set the section says which is missing and Send reply is off. Somebody who may change CoreX settings gets a link, Open Mail settings; anybody else is told who can change it. What was typed stays in the box.
A reply is kept and not delivered. A development site, and a staging site with live delivery off, keeps a reply in Email Studio’s captures and delivers it to nobody. The section says so, and the reply can still be sent.
Replies need the CoreX Email add-on. Without the add-on there is no box.

The section says nothing where a reply is simply delivered.

What happened to a reply

After Send reply the section says which of these happened:

Reply sent to the address: the mail provider accepted it. That is not proof it reached an inbox.
Reply kept on this site, not delivered: the site captured it (see above).
The reply was not sent, with the mail system’s reason. What was written stays in the box.

What the person receives

The reply is sent as a designed email: the site’s logo, or its name where the site has none, above the message on a card, and a footer naming the site with a link to it. The colours and type are CoreX’s. It holds on a phone, has a dark palette for a mail client that asks for one, and reads right to left on a right-to-left site; each paragraph takes its own direction, so an Arabic line in an English reply starts from the right.

The same words are sent with it as plain text, for a mail client that shows no HTML: paragraphs apart, list items marked, and each link followed by its address.

On a development site the email is in CoreX → Email Studio with both versions, as it would have been sent. The kept email records who it was for and where an answer goes, not who it was from: the sender is not shown there.

Who a reply is from

A reply leaves from the site’s general sender unless the site names one for replies, under CoreX → Settings → Mail:

Reply sender name: the name a reply is sent under. Blank, the general From name.
Reply sender address: the address it is sent from. Blank, the general From address. It has to be a mailbox your mail service may send as: a relay such as an SMTP plugin sends each address through its own connection, and one it does not know may be refused, rewritten, or land in spam.
Replies are answered to: where the person’s answer goes. Blank, the Default reply-to address.

Each is used alone or with the others. A name with no address anywhere is sent over the address WordPress itself sends from. The settings are read by a reply and by a reply sent again; no other email reads them.

A transport plugin set to force a From address or name (“Force From”) replaces what is set here, as it does the general sender. The Mail settings say so when one is.

An address that is not one is not saved, and the settings screen says which field was not changed and why; what was there before stays. The rest of the form is saved.

A site can give these emails its own colours, logo and footer line, or its own template: see A site’s own email design.

What was already answered

Every reply is listed at the top of the section, oldest first: its subject, who sent it, when, its state in words (Sent, Kept, not delivered, Not sent, Waiting to be sent, Returned undelivered) and its text. A reply that was not sent is listed too, with the reason, so the next person to open the submission knows the lead has not been answered. History records that a reply was sent and what happened to it, without its text.

A reply holds paragraphs, line breaks, bold, italic, lists, and links to the web, a mailbox or a telephone. Anything else that is posted is removed before the reply is kept or sent, and its words are kept. What is typed between angle brackets, such as an address written <sam@example.com>, is text and is kept as it was typed.

If a reply is sent and cannot then be kept on the submission, the section says so: the reply went, it is not listed, and it is not to be sent again.

A reply listed as Not sent has a Send again button, for anybody who may answer the submission, not only whoever wrote it. It sends that reply as it was written, to the same person: in the conversation where it was to join one and there still is one, and as a new email otherwise. It says what happened as a first sending does. The reply stays one reply: it then says Tried 2 times, with the state of the latest.

While one person’s Send again is out, the reply is listed as Waiting to be sent and nobody else can send it: somebody who presses at the same moment is told a colleague is already sending it, and nothing is sent twice. If the person sending it again still has that same reply in their own reply box, the box is emptied and their draft of it discarded when it goes. Anything else in the box is left alone.

There is no Send again on a reply that went, is waiting to be sent, or was kept on a site that keeps its email; nor where a reply from this site would be refused, which the note above the box explains.

The replies are removed with the submission when it is deleted for good, and when retention anonymizes it.

Inspect a notification’s delivery

A related retryable template attempt can be resent from its immutable template version and current submission context. Open log returns the redacted delivery record only when that attempt belongs to the open submission.

Export personal data

Choose Export. Under What to export, pick one, each shown with how many submissions it holds:

Selected rows: only the rows ticked in the inbox.
Current filters, spelled out: the form, status, owner, dates and search in force.
Everything you can access.

Under Columns, choose the groups to include: Submission details, Status and assignment, Answers, Hidden fields, Campaign data, Consent record, Team notes. The file has one row per submission and one column per answer, headed by the question the form asked. Personal-data columns require both the export permission and an explicit acknowledgement. Marked tests remain excluded unless you tick Include submissions marked as tests.

Under Format, choose Excel workbook (.xlsx), CSV (.csv) or PDF document (.pdf). A workbook has a sheet per form, real dates and numbers, and a frozen heading row. A CSV opens correctly in a spreadsheet, with a choice of separator: comma, semicolon or tab.

A PDF is a document to keep or print, on A4 pages set wide. It opens with what was exported, how many submissions, and who exported it and when. Every page is headed by the site’s name and the export’s title, and signed at the foot with the CoreX logo, “Exported with CoreX”, the copyright line and the page’s number out of how many. The heading row is repeated on each page. An export of more than eight columns is set out one submission at a time, each question beside its answer, because that many columns do not fit a page. On a right-to-left site the page reads right to left, and a phone number, a date or a Latin-script answer inside it keeps its own order.

A PDF holds up to 500 submissions. The dialog says so under the choice, and names the limit instead of starting when the choice holds more: export fewer, or choose a workbook. On a site installed from the shared-host package, text in a script whose font the package was built without prints as empty boxes in a PDF; the workbook and the CSV hold it as it is (see the shared-host package’s --pdf-fonts). PDF is offered only where the server can write one, which needs PHP’s gd and mbstring extensions.

The dialog shows the export’s progress and saves the file when it is ready; there is nothing to refresh. History records the actor, scope, columns, row count, and time, while the shared activity stream records the compliance event without copying submitted values.

Recent exports

Under the form, Recent exports lists what was exported before: your own exports, or everybody’s when you may manage every submission. Each entry says what it covered (the ticked rows, the filters in words, or everything), its format, how many submissions, how large the file is, who made it and when, and what became of the file:

Expires on a date: the file is kept, and Download saves it again.
Expired: the file passed its retention and can no longer be downloaded. The entry stays.
Deleted by somebody, on a date. The entry stays.
No file to download: the export did not finish, or its file is no longer on the server.

An exported file is kept for 30 days from the day it was made. The daily retention sweep then removes the file and leaves the entry. Delete removes a file sooner, after asking; the activity stream records who deleted it. The list shows the five newest; a link under them, which says how many more there are, shows the rest.

In a CSV, a value that begins with +, -, = or @ is written so a spreadsheet does not run it as a formula. Downloads pass through the authorized Inbox endpoint rather than exposing a public uploads URL.

Retention

Set the age window under Submission retention. The panel shows how many responses are currently due: older than the window and still holding their personal data. The count excludes marked tests by default and stops at 500, the size of one run. After confirming, choose one operation:

Archive keeps the response and marks its workflow and retention state.
Move to trash moves the response to the inbox’s Trash view, where it can be restored and from which it is deleted for good after the number of days set there. It is the same trash as the inbox’s own: each response’s history says the retention run moved it and who ran it, the activity stream has one entry for the run, and a person whose view of the inbox is limited moves only the responses they can see. It does not depend on how WordPress’s own trash is configured (EMPTY_TRASH_DAYS).
Anonymize personal data removes submitted values, submitter projections, hidden/UTM/consent data, and notes while preserving non-personal workflow evidence.

A run handles at most 500 responses, oldest first, and skips the ones its operation has nothing left to do for:

An anonymized response is finished. It is no longer counted as due, and no operation selects it again.
An archived response still holds its personal data, so it stays in the count and can still be anonymized or moved to trash. Archive does not select it a second time.

Each applied archive or anonymization writes a retention timeline event. Including marked tests is a separate explicit choice so diagnostic fixtures are never swept into ordinary retention work accidentally.

For creating the versioned response source, see Forms & Flows. For generic source adapters and data exploration, see Manage submission data.