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.

Edit answers also offers the questions the response left out, required ones first, each with the right input for its type, so a missing answer can be added rather than only changed. Corrections you save build on each other instead of replacing the last one.

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.
• The run summary names anything it could not record. Where someone can create the target records but cannot write back to the response itself, the summary says which responses could not be recorded and names the records each one created, so nothing is silently processed twice. This is reachable only where a permission set or profile grants Edit on responses without Modify All: Sliick Forms Admin and Sliick Forms Operator are not affected.
• Processing is all-or-nothing if the “processed” stamp is rejected. If a validation rule or trigger of yours rejects the update that marks a response processed, the whole run is undone, so no records are left behind without their response. A rejected stamp is logged, and an error message that is too long is shortened so it cannot strand the rest of the run.
• A suspected duplicate, or a response that failed validation, is skipped until someone marks it genuine or accepts it. See The responses console.
• Processing can also be run without opening the console, from a Flow, using the packaged Process Submissions action.

Dates and numbers

• A Date/Time answer with no time zone is read in your org’s default zone, where it was read as UTC before 0.9.0. That can change a matching key for a response staged before the upgrade.
• A Date answer mapped to a Date/Time field is written as midnight in the respondent’s zone, and cannot be that field’s match key.
• A response staged with a date Salesforce cannot store still fails processing. Correct it with Edit answers, then retry.

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.