Form Data Overview

   Journey Manager (JM) The transaction engine for the platform.  |    Platform Developer  |  All versions This feature is related to all versions.

Manager uses XMLXML (Extensible Markup Language) is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. format to store and represent form's data, such as user's input and prefilled information, for example, a current location. Manager automatically generates a default XML data structure to handle the data passed between the server and a form.

Each Maestro form that you deploy into Manager contains a formseed.xml archive file describing all relevant form data in an XML format. If you have specific data schema requirements, you can edit the form's XML data structure or upload a form seed file to update the form XML data. When you export a form from Manager, the archive file also contains a formseed.xml file so you can check and modify the XML data structure as required.

The form XML data structure varies depending on a form content, but it usually includes the following elements:

• AvokaSmartForm - the root element that incloses all other tags. The example is shown below:

  <AvokaSmartForm>
  ...
  </AvokaSmartForm>

  Note

  If a form is configured to uses Unified App Data, then <Root> is the root element of the form XML data.

• SFMData - Smart Form Data that contains transaction data, such as formCode, TemplateVersionNumber, ReceiptNumber, PaymentDetails, and so on. The example is shown below:

  <SFMData>
      <SystemProfile>
        <DisplayMode/>
        ...
      </SystemProfile>
      <PaymentDetails>
        <Payment>
          <SubTotal/>
          <GST/>
          <ServiceFee/>
          <Total/>
        </Payment>
        <PaymentType/>
        ...
   </PaymentDetails>
  </SFMData>

• SystemProfile - system specific properties of the form. The example is shown below:

  <SystemProfile>
  	<FormCode>test</FormCode>
  	<TemplateVersionNumber>1.0</TemplateVersionNumber>
  	<UpdateUserProfile>false</UpdateUserProfile>
  	<HostContext>Page</HostContext>
  	<SubmissionType>Submitted</SubmissionType>
  	<OnlineSaveEnabledFlag>true</OnlineSaveEnabledFlag>
  	<Referer><![CDATA[...]]></Referer>
  	<RequestLogKey>...</RequestLogKey>
  	<TestMode>false</TestMode>
  	<SubmissionNumber>
  	</SubmissionNumber>
  	<DisplayMode>Entry</DisplayMode>
  	<ShareForm></ShareForm>
  	<ComposerDataVersion>21.05.4</ComposerDataVersion>
  	<ServerBuildNumber>22.4.0</ServerBuildNumber>
  	<RevisionNumber>0</RevisionNumber>
  	<FormDataServiceURL>...</FormDataServiceURL>
  	<OfflineSubmissionId>..</OfflineSubmissionId>
  	<TrackingCode>...</TrackingCode>
  	<AbandonmentReason>...</AbandonmentReason>
  	<AbandonmentComments>...</AbandonmentComments>
  </SystemProfile>

  Note

  If you build a form using the Use server side Transact Functions (requires TM 17.10 +) option, a number of SystemProfile properties, such as <TestMode>...</TestMode>, are removed from the form and from the submission XML data.

  So, in the above example, the reduced set of form's properties will be like this:

  <SystemProfile>
  	<FormCode>test</FormCode>
  	<RequestLogKey>...</RequestLogKey>
  	<DisplayMode>Entry</DisplayMode>
  	<ServerBuildNumber>22.4.0</ServerBuildNumber>
  	<RevisionNumber>0</RevisionNumber>
  	<FormDataServiceURL>...</FormDataServiceURL>
  	<TrackingCode>...</TrackingCode>
  	<AbandonmentReason>...</AbandonmentReason>
  	<AbandonmentComments>...</AbandonmentComments>
  </SystemProfile>

• Form's specific elements, such as FirstName, LastName, EmailAddress, and so on. The example is shown below:

  <FirstName/>
  <LastName/>
  <DateOfBirthDropdown>
      <Day/>
      <Month/>
      <Year/>
      <Date/>
  </DateOfBirthDropdown>
  <EmailAddress/><AddressAustralia>
      <AddressLine1/>
      <AddressLine2/>
      <City/>
      <State/>
      <PostCode/>
  </AddressAustralia>

When a user selects a form, Manager starts to controls the data flow that can be one of the followings:

• Standard default form processing
• Customized form processing. This is the most common method to process a form.

Form data configuration addresses one of a common requirements - prefill of a form with user’s details.

Before proceeding with data configuration in Manager, there are several data settings that should be configured in Maestro. Once the Maestro form version is built and published, these data configuration is transferred to Manager.

The list below identifies details on how to customize forms in Manager for the following data requirements:

• Prefill a form with user details using one of the supported prefill methods:
  • Property Prefill mapping
  • Request Parameter Prefill mapping
  • Input XML Prefill mapping
• Capture and store additional details that are passed along with the form submission that may be required for handling attachments, receipts, and anonymous submissions. For more information, see configuration mapping.
• Provide an alternative data structure, according to your enterprise’s requirements, to the default XML. For more information, see form XML data.
• Extract some details for easy access for monitoring and managing form submissions. Data extracts are also required for some collaboration job features.

Form Builders customize these data mappings using Manager or Maestro UI, so that individual data elements can be externally defined and mapped to your form’s XML data structure when the form is rendered.

Next, learn how to view form data configuration.