This article covers a process that's required for Frontly's Full Screen Form function and User Input blocks and should not to be confused with the standard Form block. Note the Form block may also benefit from the processes covered, depending on your use case, but already has the built-in capability to create new rows of data into your data source.
Saving Submitted Values from a Full Screen Form
After your users complete your Form Screen Form, you'll want to choose a method to store their inputted values through either a configured Submit Action or Complete Button Action.
Click here to learn more about the Full Screen Form
Saving Inputted Values from a User Input Block
For custom forms created with user input blocks, make sure to include a Button block or anything else that can trigger an action sequence in Frontly.
βClick here to learn more about User Input Blocks
βClick here to review the list of events that can trigger a Custom Action in Frontly
Read on to learn more about the three most common methods to achieve this and the potential reasons for adopting them. Keep in mind this is not the exhaustive list of methods for storing form data, and they can even exist together within the same action flow depending on what you're trying to achieve.
Form Variable and Field ID
There are two vital components of the set up that will apply to all of the following procedures.
The "form" variable prefix where the system will look to the form's responses as its data source.
The Field ID is the referential ID connected to every question you create in the Full Screen Form editor.
You'll combine these two components to create the dynamic variable that's formatted as followed:
β{{form.Field ID}}
Where you see "Field ID" is where you'll enter your ID value (which is case sensitive). Using the above example, the resulting variable would appear as {{form.homepage}}.
Did You Know? π‘
By utilizing variables like {{form.Field ID}}, you can also dynamically incorporate user-provided information into follow-up questions or responses, creating a more engaging and tailored interaction flow. This technique can enhance the user experience by showing a user's past inputs in real time and providing relevant follow-up questions or information based on their previous responses.
Data Source Request
Selecting the Data Source Request option will give you the choice between create a new row or updating a pre-existing one in your desired data source.
Fill each field you wish to create or update with the corresponding form variable.
Use cases: This method is useful for recording user inputted data into your spreadsheets so it can visualized in-app elsewhere or for triggering your automations with another tool.
Update Local State
Create a Local State that temporarily stores your user submitted data by completing Key / Value pairs. Values will be stored until the Key value is updated, or the user refreshes their page or logs out.
Use cases: Using this method is an effective way to surface form filled values throughout the user's session and contextually tailoring their experience based on their input using Hidden Filters and Display Conditions. Accessed via the {{localState.CustomKeyLabel}} variable.
Click here to learn more about Local State Variables
Click here to learn more about Hidden Filters
Click here to learn more about Display Conditions
Navigate to Page / Using URL Parameters
Using a Navigate to Page action that references your user's form submissions through Key / Value pairs that will display as URL parameters on the proceeding page.
Use cases: This method is usually helpful for visualizing Full Form responses on one page through the use of the {{params.CustomKeyLabel}} variable in any block. If the responses are saved into a Google Sheet, they can be continually accessed by referencing the URL and all the inserted parameters.
Click here for a fully comprehensive guide on URL parameters.