Processing responses onto records

A response does not write straight to your target object. It arrives in the responses console as a staged submission, and processing is the step that maps it onto Contacts, Cases, Leads, or whatever else the form targets. This page covers running that step and fixing what goes wrong.

What processing does

For one staged submission, processing:

• maps the staged answers onto target records via each field’s mapping,
• updates an existing record instead of inserting one where a match key is configured and satisfied,
• applies the form’s record-type choice on newly created records,
• links uploaded files,
• and creates child rows for each row of a repeating group.

You can see all of this before you run it: click the row for the What processing would do preview. See The responses console.

Correct answers before processing

While a submission is Received or Failed, the panel header offers Edit answers. Change what needs changing and click Save correction. Back to preview returns without saving.

Corrections are an overlay. The originally submitted answers are preserved unchanged and stay auditable, and processing reads the corrected values. Saving a correction on a Failed submission puts it back to Received, ready to retry.

Blank answers are skipped at processing, so clearing a value here will not blank that field on a record the submission matches.

Process and retry

• Each row carries one action: Process while it is Received, Retry once it has Failed.
• Tick several rows and use Process Selected to run them together. Afterwards a summary line reports n of m processed successfully.
• Processing runs as you, in your permissions. If you cannot create or edit the target records, processing fails with that error rather than escalating.
• Processing can also be run without opening the console, from a Flow, using the packaged Process Submissions action.

When processing fails

The reason is on the row. Work down this list:

1. Your own access to the target object and every mapped field. Processing needs it on the Salesforce objects the form writes to, not just on Sliick Forms.
2. A mapped field that no longer exists. Renaming or deleting a target field in Setup breaks the mapping quietly until processing runs.
3. A required field on the target object that the form never collects. The record cannot be created. Add a hidden field with a default value to fill it. See Mapping a starter form.
4. A validation rule on the target object rejecting the mapped values.
5. On an org that uses person accounts, two more specific errors have their own explanation. See Person accounts.

Fix the cause, then Retry. Nothing is lost: the original answers are kept exactly as submitted, and you can correct them with Edit answers first if the answers themselves were the problem.

Answers a respondent never saw are not written

Processing writes only the answers that were actually in play. If a field was hidden by a visibility rule, its value contributes nothing to the record even when it reached the org, and neither does a file uploaded to a hidden question, or a row of a repeating group whose own rule was false. The staged response keeps everything that arrived, so the audit trail is complete; your records get only what the respondent could see. The exception is a Hidden Field with a default value, which is an author’s constant rather than an answer and is stamped on every submission.

Failed submissions are counted on the dashboard’s Failed processing tile, which takes you straight to the console filtered to failures, and are listed in Needs attention.