Let’s say you have a few webforms to design, which will be embedded into a public facing website, and used by a non-authenticated user
When a form is submitted, it’ll be send to Salesforce, applying a previously discussed webform pattern.
So you have:
- the form itself, which has a label and a field name.
- a staging object in Salesforce, which stores all fields from all forms. The fields store an exact copy of the responses from the form. Let’s call this staging object “Form Submission”.
- the final Salesforce object(s), which may be one or more.
- perhaps some data transformation between the staging object and the final object. Record-triggered flows are great for this.
Since there may be multiple webforms and/or Salesforce objects, it’s best practice to map questions from each form to the final Salesforce field.
Here’s an example with 5 fields in Form A, and 3 fields in Form B:
Some observations:
- The same form field can have different labels in different forms.
- The data type for the form field is similar, if not identical to, the data type for the staging SF field and final SF field
- The data types for most of the staging fields are either Text(255) or Checkbox. This ensures all values submitted will be accepted by the staging object.
- This means you need to have proper data validation on the form itself.
- If you have a dozen or more forms, you may want to have more than staging object.
The takeaway
Performing this field mapping exercise in advance, and keeping the resulting sheet updated, will guide you to efficient webform design.
Category:
Salesforce