Forms & Submissions
Declare the fields an app accepts, control what happens after a submission, and review answers and uploaded files in the Submissions tab.
Any app can take submissions: a visitor fills in a form, the answers are checked against the fields you declared, stored, and handed to every workflow bound to the app. Apps created from the Form template take submissions from the start; any other app gets the same abilities once fields are declared for it (in Settings > Fields or by asking the assistant).
Fields
Settings > Fields lists what the form accepts. The server checks every submission against these fields and drops anything else.
For each field set:
| Setting | Meaning |
|---|---|
| Label | What the visitor sees. |
| Type | Text, Email, Password, Number, Long Text, Dropdown, File Upload, Checkbox or Date. |
Name (field_name) | The machine key. Workflows read the value as {{trigger.data.fields.<name>}}. Letters, digits and _, not starting with a digit; each name once. |
| Placeholder | Optional hint inside the control. |
| Required | The submission is refused without a value. |
| Options | Dropdown only - one value|Label pair per line. |
| Max MB | File Upload only - the largest file the field accepts. |
Use Add field, and Move up / Move down to reorder. The assistant can also set length limits, patterns, number and date ranges and accepted file types when you ask for them; every rule is enforced on the server, whatever the page sends.
The form's markup is a file of the app. Changing fields in Settings does not rewrite the page. After you change them, click Ask assistant to update the form (or ask in the chat) so
index.htmlmatches the new fields.
A whole submission, files included, can be up to 10 MB; a single file up to 10 MB or the field's own smaller limit.
After submit
| Setting | Meaning |
|---|---|
| Success message | Shown to the visitor after a successful submission. |
| Redirect to (optional) | An http(s) address, or a path starting with /, to send the visitor to instead. |
"The app's own code shows these (the form's app.js reads them from the form when it was generated) - update the form after changing them."
Result workflow
A submission starts every active workflow in the workspace whose App trigger names this app - one form can drive several workflows. If the form waits for an answer to show the visitor (for example "your ticket number is …"), Result workflow picks which workflow's result is shown; the others run in the background. Automatic (the only bound workflow) is the default.
When no active workflow is bound, submissions are still stored, and the editor says so: "No active workflow is bound yet: a workflow runs on each submission when its trigger is "App" with this app selected." See Connecting Apps to Workflows.
Limits (form)
| Setting | Meaning |
|---|---|
| Maximum submissions | After this many submissions the form closes. Unlimited by default. |
| Close after | A date after which the form closes. |
The section shows how many submissions the form has received so far. A closed form refuses new submissions with a "closed" message to the visitor.
The Submissions tab
The app editor's Submissions tab is the app's inbox. It appears when the app declares fields or still holds submissions.
- Each row shows when it was Submitted and one column per declared field. Checkboxes read Yes / No.
- File fields have a Download link. Files are always downloaded, never opened in the browser. A file that could not be kept says why - for example "Not stored: storage limit reached" (the rest of the submission and its workflows still go ahead).
- A submission that started no workflow is marked "Nothing started - no active workflow was bound at the time".
- Delete submission removes it together with its uploaded files (needs delete permission).
- Use Reload to fetch new submissions, Previous / Next to page through them.
If you remove all fields later, the tab keeps showing the stored answers: "No fields are declared any more - showing the stored answers."
Submissions are kept independently of workflow runs: if a workflow fails or is deleted, the submission stays. Deleting the app deletes its submissions and their files.
Uploaded files in workflows
A file field reaches the workflow as an object:
{
"name": "damage-photo.jpg",
"size": 245678,
"contentType": "image/jpeg",
"key": "…"
}
The key points at the stored file in your organization's storage, so a workflow can attach it to an email, send it to Telegram, or read it with the Files server - for example {{trigger.data.fields.photo.key}}. If the file could not be stored, key is empty and the object carries an error.
Related
- Connecting Apps to Workflows - the App trigger and the submission payload
- Publishing & Access
- JavaScript API -
FlowTrux.submitandFlowTrux.form.bindfor custom forms