The responses console

Every submission lands here first. The Sliick Responses tab is the working surface for staged submissions: find them, read them, check what they will write, and export them. Open it from the app, or from a form’s Submissions row action on the dashboard.

It comes with Sliick Forms Admin and with Sliick Forms Operator, the set for staff who work responses without authoring forms. See Install and permission sets.

Nothing has been written to your Salesforce records yet. A submission stages in this console, and processing is the separate step that maps it onto records. See Processing responses onto records.

Filter the list

Filter with the status picker (All statuses, Received, Processing, Completed, Failed, Suspected duplicate, Failed validation), the form picker, a from and to date range, and an Include test checkbox. Test-respondent submissions are hidden until you tick it.

There is no free-text search here: searching happens on the dashboard, across forms rather than responses.

See the answers in the list

Filtered to one form, each row’s own questions become the table’s columns, up to five, in field order. Without a form filter, or with a status or date filter spanning several forms, each row instead shows a short summary line: up to three answers, an email-looking one first if there is one, each capped at 60 characters.

Either way this reads straight off what the respondent submitted, so an answer shows whether or not its field is mapped to a Salesforce field: mapping decides what processing writes onto target records, not what you can see here.

File uploads, signatures, and payment fields are never shown in either view; open the row for those.

Preview what processing will do

Click the row. The panel that opens is a dry run, titled What processing would do. It shows every record processing would touch: Create, Update existing, or Create child row, the object, the field values it would write, and, where the form has matching fields, whether this submission matches an existing record or would insert a new one.

Nothing is written at this stage. Click the row again to close the panel. If the form maps no fields at all, the panel says so rather than showing an empty plan.

Any files a respondent uploaded are attached to the submission record as soon as it is received, so you can open them while reviewing, before you process anything. See File uploads.

A response from a public form can take a few seconds to appear. Answers from an anonymous visitor are staged through a background step rather than written on the spot, which is what keeps visitors away from the response records themselves.

Suspected duplicates

A response that arrived under a link id another response to the same form had already used, with different answers, carries a Suspected duplicate badge next to its status. It is kept rather than discarded. Choose Suspected duplicate in the status picker to list only these. The Received filter shows them too, badged, because a suspected duplicate stays Received. See Accepting responses for how one arises.

• Open the row to see why it was flagged. The panel names the responses it shares its link id with, earliest first, up to ten, then how many more. The earliest one is not badged, because it arrived first and was recorded as normal.
• The dry run is still shown, under a note that processing skips the response until it is marked genuine.
• Mark as genuine takes the place of Process on a flagged row. It clears the flag and sends the form’s webhook for the response, which was held back. It does not process the response, change its status or send any email, and it does not recheck the response limit, because the response already counted. Afterwards Process is offered as for any other row. The webhook carries the answers as the respondent sent them, so a correction saved beforehand does not change what it receives.
• If the response is not genuine, delete its Form Submission record. That also frees its place under the response limit. If it turns out the earliest response is the one you do not want, check the records it created first, then delete it.
• Mark as genuine refuses a response that is no longer flagged, for example because someone marked it a moment ago, and says so.

Sliick Forms Admin and Sliick Forms Operator can mark a response genuine.

Responses that failed validation

A response Salesforce kept after it failed the form’s checks carries a Failed validation badge. This happens only when the sender asks for it, using keepIfInvalid. A response submitted on an Experience Cloud page is never kept this way: the respondent sees the errors and fixes them on the page. Choose Failed validation in the status picker to list only these, and the dashboard’s Needs attention list shows each form that has any.

• Open the row to see why. The panel lists the checks it failed when it arrived, then checks it again with any correction you have saved: it either now passes, or still fails and says what.
• Use Edit answers to correct it, then open the row again to see the new result. A required answer that never arrived is listed under Not answered in this response, so you can add it.
• Accept for processing takes the place of Process on the row. It clears Failed validation and sends the form’s webhook for the response, which was held back. It does not process the response or send any email. Afterwards Process is offered as for any other row. The webhook carries the answers as they arrived, and a saved correction reaches your records when the response is processed.
• If it still fails, Accept for processing asks first, because the check itself can be what is wrong. It asks the same way when the check could not be run again.
• The recorded reasons stay on the response in its Validation Errors field after it is accepted, as the record of what was overridden.
• A response that is both a suspected duplicate and failed validation shows both buttons. Each clears its own flag, and Process is offered only when both are cleared.

Sliick Forms Admin and Sliick Forms Operator can accept a response for processing.

Export CSV

Export CSV downloads every submission matching your current filters, including status, form, date range and Include test, across all pages rather than just the page on screen.

It is a real spreadsheet. One column per question, headed with your own labels, in field order, with the raw payload kept in a final column and an IsTest column so test-respondent rows stay identifiable. Three columns were added after it in 0.9.0: SuspectedDuplicate, FailedValidation and ValidationErrors. If something reads the file by column position, check it after upgrading to 0.9.0. A question you have since removed from the form is still included, headed “(no longer asked)”, so an old response never loses its answers. Headings, paragraphs, images and other blocks nobody answers are left out rather than exported as empty columns. The file is named for the form and the date.

There is no row cap. A large export pages in the background with live progress and a Cancel button.

An answer that looks like a spreadsheet formula cannot execute when the file is opened. The same protection, with full quoting and a byte-order mark so accents survive in Excel, applies to the translations export, and re-importing an exported translations file restores them exactly.