Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

 

...

Section
Column
width40%
Panel
borderColorlightgrey
bgColor#F0F0F0
titleColorwhite
borderWidth1
titleBGColor#88AACC
borderStylesolid
titleOverview

The Submissions page shows who has been using your form and what data they submitted. You can see exactly when the form was submitted, the user’s IP address, and all data the user entered. You can view each submission individually by double clicking a submission in the table.

...

Note
Currently, if the user or app no longer exist (was deleted) the submissions will still be counted.

 

Note

This section is only relevant if you will be working with XML data either directly or indirectly (e.g. [[V4_Create_Update_ConfluencePages|Updating Confluence pages]]).This section is primarily relevant to from-palette controls that are dragged from the palette and dropped into the form. If you are working primarily with XML schemas, please see [[V4_Data_Sources_and_Schemas|Schemas]].

With Live Forms, you can create two kinds of forms:

  • Top-down: drag and drop controls from the palette and Live Forms will generate an XML document based on the structure of your form.
  • Bottom-up: define your data upfront using an XML schema, upload it to Live Forms and Live Forms will generate controls. You can then drag and drop to move the controls, change their appearance etc. However, the generated XML document will always conform to the uploaded XML schema irrespective of where the controls are moved.

You can mix the two approaches, i.e. you can create a form that has, for example, controls generated from two different XML schemas and some from-palette controls. The result will be three documents.

Top-down forms (from palette)

This is the most common type of form where you drag and drop controls from the palette. The form is shown below in the Designer. It contains a Section named Personal. Inside this Section there are two Panels. Each panel has two controls. Below this Section is a Repeating Section called Incident which itself contains two controls.

Section
bordertrue
Column
width100px

 Image Removed

Form with Section and Repeat

Column
width100px

Image Removed

Use Mode form filled with data

The form is shown filled in above. We've filled in all the fields and added a second repeating incident. When the form is submitted, Live Forms generates an XML document that looks like the one below:

Code Block
<ns:form xmlns:ns="http://www.frevvo.com/schemas/_5PqoILXnEeCqU4w2X0ufGw" name="FNLN2"> <Personal> <FN>John</FN> <LN>Doe</LN> <EmailAddress>johndoe@yahoo.com</EmailAddress> <Phone>202.202.2020</Phone> </Personal> <Incident> <Date>2010-08-01</Date> <Description>Parking ticket</Description> </Incident> <Incident> <Date>2010-08-08</Date> <Description>Speeding ticket</Description> </Incident> </ns:form>

Note that the structure of the generated XML document matches the structure of the form. You can download an XML schema that describes the document that the form will generate by clicking on the Schema button for the form. See the [[V4_Forms_Home_Page|Forms Home Page]] documentation for details.

If the structure of the form is changed, the generated XML document (and associated schema will change). For example, if you add a new Section - say it's called Info - and nest both the existing Personal Section and the Incident Repeat inside this new Section, the XML document will change to reflect this change as shown below (snipped for brevity):

Code Block
<ns:form xmlns:ns="http://www.frevvo.com/schemas/_5PqoILXnEeCqU4w2X0ufGw" name="FNLN2"> <Info> <Personal> <FN>John</FN> ... </Personal> ... </Info> </ns:form>

Why is this important? It's only important if you are using the form to edit existing submissions, i.e. to edit the XML documents they have generated. To do so, the form must first be initialized using the XML document. If the structure of the XML document does not match the structure of the form (or more accurately, if the XML schemas are incompatible), the initialization will fail and you cannot edit the submission using the form.

This can happen if you are using the Live Forms API in your application to edit submissions or if you are using the Create/Update Confluence pages functionality. In these cases, you must be very careful that you maintain the structure of the form. You can add new fields or delete existing ones. But you cannot make changes that change the schema of the generated XML.

If you don't want to worry about making sure that form versions remain compatible, you can always use the from-schema bottom-up path to generate forms from XML schemas. In this case, changes to the form will not change the document since it must conform to the schema. The downside is that you must first define the XML schema and then use it in the form, which requires some technical knowledge of XML and XML schemas.

Tip

An upcoming version of Live Forms (currently estimated for late Q1 or Q2 2012) will permit versioning of forms/flows so existing submissions can be edited using older versions of the form/flow.

Submissions Database

Submissions can be accessed directly via database SQL queries. By default Live Forms's submissions are stored in the built-in HSQLDB. You can easily [[V4_Installation_Instructions#Changing_from_HSQLDB_to_another_database | configure Live Forms to use a different database]] such as mySql, MS SQL Server, etc.. Doing so can make direct access to the submission database simpler.

There are many possibilities when using direct SQL queries against the Live Forms submissions repository. Several examples are described below. [http://www.frevvo.com/frevvo/web/static/contactUs Contact frevvo] for further assistance.

Count

You may have a pledge or survey form and you would like to track the number of people that have submitted your form. Here is the SQL query to retrieve the count from the Live Forms submissions repository. In this example your Live Forms designer account name is 'JoeSmith', your application name is 'Economic Impact' and your pledge form is named 'pledge2009'.

To retrieve the count of ALL submission for a specific form:

Code Block
select count(*) from formsubmission fs, formsubmissiontype fst where formsubmissiontype_formtype_id=fst.id 
and fst.ownerid='JoeSmith' and fst.deleted is null and fs.state='SUBMITTED' and 
fst.applicationname='Economic Impact' and fst.name='pledge2009'

To retrieve the count of ALL submission for forms in a specific application:

Code Block
select count(*) from formsubmission fs, formsubmissiontype fst where formsubmissiontype_formtype_id=fst.id 
and fst.ownerid='JoeSmith' and fst.deleted is null and fs.state='SUBMITTED' 
and fst.applicationname='Economic Impact'; 

To retrieve the count of ALL submission for a given form designer:

Code Block
select count(*) from formsubmission fs, formsubmissiontype fst where formsubmissiontype_formtype_id=fst.id 
and fst.ownerid='JoeSmith' and fst.deleted is null and fs.state='SUBMITTED'; 

Image Added

Column
width20%
Panel
borderColorlightgrey
bgColor#F0F0F0
titleColorwhite
borderWidth1
titleBGColor#88AACC
borderStylesolid
titleSubmissons Chapters

View/Edit Submissions

XML Documents 

Process Form Data Tutorial

Warning

The frevvo database is not designed for custom reporting. The submission data is stored in an unsearchable blob format. Although

Frevvoproduct
in-house customers may access submissions directly via database SQL queries, this is strongly discouraged. Future
Frevvoproduct
versions often have changes to the underlying submission database schema which will break your SQL queries. If you are thinking about using a third party reporting tool to read from the frevvo database, we recommend that you store form/flow submission data in a custom database using the frevvo Database Connector. Use the reporting tool against the custom database.