Jitterbit Form Flow App

Overview

Jitterbit provides the Form Flow app through Jitterbit Marketplace. Built with Jitterbit App Builder, it is a template-driven form builder and data-collection app. Administrators assemble reusable form templates from sections, forms, and fields, then end users complete those templates through a guided, step-by-step wizard. Submissions move through a review and approval lifecycle, with email notifications at each stage.

You download the app as an App Builder release package (an .LP file) from Marketplace and install it into your own App Builder instance, where you can configure and extend it to fit your process.

This page describes how the app works, its core features and data model, and covers the prerequisites, how to download and install it, how to configure it for your environment, how access is controlled, and common troubleshooting steps.

How it works

At a high level, Form Flow moves from building a template, to completing submissions against it, to reviewing those submissions:

flowchart TD A["Administrator builds
a form template"] --> B["Define sections, forms,
fields, and visibility rules"] B --> C["Template available
for submissions"] C --> D["User starts
a submission"] D --> E["Complete the
guided wizard"] E --> F["Submit"] F --> G{"Reviewer
decision"} G -->|Approve| H["Submission locked,
approval email sent"] G -->|Request revision| I["Submission reopened,
revision email sent"] I --> E

Core features

When you install and configure Form Flow, it provides the following capabilities:

Template builder: Build custom questionnaires organized into sections and forms, using a range of field types including text, text area, number, date, checkbox, radio button, dropdown, and HTML content.
Guided data entry: End users complete a submission through a wizard with a left-hand navigation tree that groups sections and forms in sequence and tracks progress as they go.
Conditional visibility: Rules evaluate a user's responses in real time to show or hide individual fields or whole forms, and to make fields required, based on earlier answers.
Review and approval lifecycle: Each template designates a reviewer. When a user submits an entry, it moves to a review state where only that reviewer can approve or reject it. Approval locks the submission; rejection reopens it for edits.
Email notifications: The app sends email at key lifecycle events (submission, approval, and rejection). Message content is driven by configurable template records, so administrators can edit the copy without changing the app's logic.

Lifecycle and states

Form Flow tracks state for each end-user submission (instance) at two levels: the submission's overall status, and the progress of the individual sections, forms, and fields within it.

Submission status

A submission moves through three overall states from creation to approval:

In Progress: The starting state for a new submission. If the reviewer rejects a submitted entry, it returns to this state so the user can make edits.
Under Review: Set when the user submits. The submission passes to the assigned reviewer.
Completed: Set when the reviewer approves, which locks the submission.

Section and form states

As a user works through a submission, its sections and forms progress through these states:

Sections and forms begin as Not Started.
A section changes to In Progress when the user opens it, and a form changes to In Progress when the user answers its first field.
On submission, sections and forms that are In Progress become Submitted, and any still Not Started become Skipped.
When the reviewer approves, the overall submission status becomes Completed, but the section and form states do not change: they remain Submitted or Skipped.
If the reviewer rejects the submission, Submitted sections and forms revert to In Progress and Skipped ones revert to Not Started, so the user can edit and resubmit.

Data model

Form Flow is fully self-contained: it stores all templates, submissions, and responses in its own tables and does not require an external database connection.

Each table has a data usage type, set by its Install Option, that controls how its data is treated when the app is installed in a new environment: Developer data is replaced on install, Shared data is seeded once, and User data is left for each environment to populate.

Table	Usage type	Purpose
`FieldType`	Developer	Registry of supported input field types.
`TemplateStatus`	Developer	Submission lifecycle states (`In Progress`, `Under Review`, `Completed`).
`SectionStatus`	Developer	Section navigation and lock states.
`FormStatus`	Developer	Form entry and permission states.
`Operator`	Developer	Comparison operators used by visibility rules.
`VisibilityAction`	Developer	Visibility outcomes (`Hidden`, `Visible`).
`Template`	Shared	Root record for a reusable form template.
`Section`	Shared	A grouping of forms within a template.
`Form`	Shared	An individual step within a section.
`FormField`	Shared	A single input field and its settings.
`FieldOption`	Shared	Choice values for radio and dropdown fields.
`FormVisibility`	Shared	Rules that show or hide whole forms.
`FieldVisibility`	Shared	Rules that show or hide individual fields.
`Parameter`	Shared	Global settings and environment values.
`WorkflowTemplate`	Shared	Email subject and body templates.
`TemplateInstance`	User	A single end-user run of a template.
`SectionInstance`	User	Progress state for a section within a run.
`FormInstance`	User	Progress state for a form within a run.
`FieldResponse`	User	An individual answer captured from a user.

Note

Deleting a Template cascades to its child Section, Form, FormField, and FieldOption records; deleting a TemplateInstance cascades to its child SectionInstance, FormInstance, and FieldResponse records. These delete actions are restricted to administrators.

Prerequisites

To use Form Flow, you need the following:

A Jitterbit Harmony license with access to App Builder. This enables the Marketplace download; if your organization is not licensed for App Builder, the Download app action is replaced by a Get app request action (see Download and install).
An App Builder instance running App Builder 4.63, the version the current package is built for. Each package installs only on its exact App Builder version; if your instance is on a different version, contact Jitterbit support to request a matching package.
A PostgreSQL database for your App Builder instance.
An outbound SMTP mail server configured in your App Builder instance. The app's notifications rely on it; without SMTP routing, email notifications do not send.

Download and install

Log in to the Harmony portal at https://login.jitterbit.com and open Marketplace.
Locate the app named Form Flow. You can use the search bar or, in the Filters pane under Type, select App to show only apps.
Click the app card to open the Details panel. Review the app's Requirements (the App Builder version and database it needs).
Click the app's Go to documentation link to open this documentation in a separate tab, and keep it open for reference.
Do one of the following, depending on whether your organization is licensed for App Builder:
- Download app: If your organization is licensed for App Builder, click Download app, on either the app card or the Details panel. Your browser saves the .LP file to its download location, and an App Builder file downloaded successfully notification confirms the download.
- Get app: If your organization is not licensed for App Builder, the action is labeled Get app. The Details panel shows a message that an App Builder license is required, with a Submit button. Click Submit to send a request for a representative to contact you about App Builder; a Message successfully sent notification confirms it.

Install the app in App Builder

Install the downloaded .LP file into your App Builder instance:

Log in to App Builder and go to the IDE.
Under Deploy, click Install Release.
Click + Package, then Browse and select the .LP file you downloaded.
Click Save. The Release panel displays the package information, then close the Package dialog.
Confirm the details are correct, then click Install.

To preview a package's contents before you install it, click the Manifest button.

Modifying the app in a development environment

The app's data source installs sealed. If you deploy the app to a development environment and intend to modify it, unseal the data source so you can edit the app's objects. Leave it sealed in QA and production to preserve equivalence across environments. See Seal or unseal a data source.

Configuration and setup

After you install the app into a new environment, complete the following steps to make it ready to use:

Assign users to groups. Add your users to the appropriate access group, either Form Flow Administrator or Form Flow User. See Security and access.
Verify user email formats. The rejection notification is sent to the submission creator's account. Confirm that user accounts use valid email addresses so notifications resolve correctly. See related troubleshooting.
Set the environment URL. In the Parameter settings, update the AppBuilderURL value to match your environment's root URL so that links in email notifications resolve correctly.
Update the sample template's reviewer. The app ships with a sample "Employee Onboarding Template." Open it and replace the placeholder reviewer email in the ApproverEmail field with a valid, monitored address.

The app also ships with sample lookup data and a sample template so that its features work immediately after install.

Security and access

Form Flow uses App Builder role-based security with two access groups, Form Flow Administrator and Form Flow User. Access to each area is as follows:

Area	Form Flow Administrator	Form Flow User
Template builder	Full access	Build and modify templates
Submissions workspace	Full access	View and start submissions
Live submission forms	Full access	Complete form entries
Rejection remediation page	Full access	Read-only, reached through workflow actions
Lookup data and settings	Full access	No access (menus hidden)
Record deletion	Full access	Not permitted

Approval and rejection actions are available only to the reviewer whose email matches the ApproverEmail on the template. For all other users, those actions are disabled. When a submission is submitted, its fields become read-only; a reviewer rejection reopens them for editing.

Business rules

Form Flow's logic is implemented as App Builder business rules. Rule names follow App Builder's Target (Purpose or Subtype) Descriptor convention, so the leading word identifies the table the rule acts on. The tables below list the rules by functional area to help you locate and understand them when you extend the app.

Template configuration rules

Rule	Purpose
`Template (Business Object)`	Manages parent template configuration records.
`Template (List)`	Selector list of active templates.
`Section (Business Object)`	Manages section layout records.
`Section (List)`	Selector list of configured sections.
`Form (Business Object)`	Manages single form-step records within a section.
`Form (List)`	Structural list used for template mapping.
`FormField (Form Fields)`	Adds form fields in the template builder and controls the field-options panel.
`FormField (List)`	Field selector used when defining visibility rules, grouped by section and form.
`FieldOption (Business Object)`	Manages choice lists for selection fields.
`FieldOption (List)`	Reference list of choice values.

Runtime (instance) rules

Rule	Purpose
`TemplateInstance (Business Object)`	Manages a user's submission run.
`TemplateInstance (Default) Status`	Defaults a new instance to In Progress.
`TemplateInstance (Navigation)`	Orders active sections and forms in the workspace.
`TemplateInstance (Reject Submission)`	Backs the reject page and captures the rejection reason.
`TemplateInstance (Subquery) Navigation Steps`	Aggregates navigation indices for progress tracking.
`TemplateInstance (Subquery) Navigation Union`	Unions section and form navigation into a single list.
`TemplateInstance (Update) Status Completed`	Sets instance status to Completed.
`TemplateInstance (Update) Status In Progress`	Reverts instance status to In Progress.
`TemplateInstance (Update) Status Under Review`	Escalates instance status to Under Review.
`FormInstance (Business Object)`	Tracks a form step within a run.
`FormInstance (Insert) Forms`	Clones live form instances from the template.
`FormInstance (Subquery) Form Navigation`	Sequences forms for the navigation list.
`FormInstance (Update) Status Change On Reject`	On reject, sets Submitted to In Progress and Skipped to Not Started.
`FormInstance (Update) Status Change On Submit`	On submit, sets In Progress to Submitted and Not Started to Skipped.
`FormInstance (Update) Status In Progress`	Marks a form In Progress on first edit.
`SectionInstance (Business Object)`	Tracks a section within a run.
`SectionInstance (Insert) Section`	Clones live section instances from the template.
`SectionInstance (Subquery) Section Navigation`	Builds the section level of the navigation list.
`SectionInstance (Update) Status Change On Reject`	On reject, reverts section states.
`SectionInstance (Update) Status Change On Submit`	On submit, advances section states.
`SectionInstance (Update) Status In Progress`	Marks a section In Progress when it is opened.
`FieldResponse (Responses)`	Captures user answers on the submission page and applies show/hide and required logic.
`FieldResponse (Insert) Fields`	Clones response records from the template's fields.
`FieldResponse (Validation) Required Response`	Checks required fields before advancing to the next form or section.
`FieldResponse (Validation) Template Required Response`	Checks all required fields before final submission.

Visibility rules

Rule	Purpose
`FormVisibility (Business Object)`	Manages rules that show or hide whole forms.
`FormVisibility (Subquery) Count By Template`	Returns the count of form visibility rules per template.
`FieldVisibility (Business Object)`	Manages rules that show or hide individual fields.
`FieldVisibility (Subquery) Count By Template`	Returns the count of field visibility rules per template.
`FieldResponse (Visibility)`	Flags a field as required or available based on the user's answers.
`FieldResponse (Subquery) Field Visibility Action`	Resolves field-level visibility state.
`FieldResponse (Subquery) Form Visibility Action`	Resolves form-level visibility state.

Lookup and settings rules

Rule	Purpose
`FieldType (Business Object)` / `FieldType (List)`	Manage supported field types.
`TemplateStatus (Business Object)` / `TemplateStatus (List)`	Manage submission lifecycle states.
`SectionStatus (Business Object)` / `SectionStatus (List)`	Manage section states.
`SectionStatus (List) Form and Section Statuses`	Combined list of form and section states.
`SectionStatus (Subquery) Navigation Statuses`	Unions section and form states for the navigation panel.
`FormStatus (Business Object)` / `FormStatus (List)`	Manage form states.
`FormStatus (Subquery) Form and Section Status Union`	Consolidates form and section states for indexing.
`FormStatus (Subquery) Navigation Statuses`	Unions form and section states for the navigation panel.
`Operator (Business Object)` / `Operator (List)`	Manage comparison operators for visibility rules.
`VisibilityAction (Business Object)` / `VisibilityAction (List)`	Manage visibility outcomes (`Hidden`, `Visible`).
`Parameter (Business Object)`	Provides runtime access to global settings.
`Parameter (Application Settings)`	Backs the settings page where administrators edit global parameters.

Notification rules

Rule	Purpose
`Email (Submission Under Review)`	Sends the notification when a submission is submitted.
`Email (Submission Approved)`	Sends the notification when a submission is approved.
`Email (Submission Requires Revision)`	Sends the notification when a submission is rejected.
`WorkflowTemplate (Business Object)`	Manages the message subject and body definitions.
`WorkflowTemplate (List)`	Selector list of notification templates.

Configuring visibility rules

Visibility rules (in the FormVisibility and FieldVisibility tables) control what a user sees based on their answers. Each rule is defined by the following properties:

Source form field: The field whose value is monitored.
Field option: A specific choice on a selection field (a radio button or dropdown option).
Operator: The comparison used to evaluate the input.
Comparison value: The value compared against the live input.
Visibility action: The result applied when the rule is true, either Hidden or Visible.
Dependent form or field: The target whose display and requirement are changed by the rule.

Two behaviors are enforced when you configure a rule:

Direct selection and expression are mutually exclusive. You can evaluate either a specific field option, or an operator and comparison value, but not both. When you select a field option, the operator and comparison value are cleared and locked.
A hidden field cannot be required. When the visibility action is Hidden, the required setting is turned off, disabled, and locked. A field can only be made conditionally required when its action is Visible.