Summary

This article covers the functionalities of the application setup worksheet. 


Table of Contents

The Application Setup worksheet defines the attributes affecting how the application functions. This page shows the effects of the functions in this worksheet on the system, as well as serves as a tutorial on how to fill out the worksheet in the DataArchitect.

Record Identification Attributes

This section outlines the steps necessary for specifying basic record identification information. Unless a default is specified, it is recommended to complete all fields not marked as deprecated.

  1. recordName:Enter the word that should be used throughout the study to label the record being tracked.
    Common recordNames include Patient, Subject and Record.
  2. recordNamePlural:Enter the word that should be used for the recordName when proper grammar indicates a plural noun should be used.
    If the field is left empty, the system will automatically insert an ‘s’ following what was entered for the recordName.
  3. primaryQuestion: Enter the full path to the question used to uniquely identify the record using the format: #form.questionID where ‘#’ signifies “start at the root.”
Note: It is recommended to specify a primaryQuestion as well as a secondaryQuestion (see step 4). These fields are intended to be unique identifiers for the subject and are used in some utilities such as reconcile and manually assigning drug to a subject. As these are used to find subjects in Reconcile Record and that utility does not support all question types, please do not point this at a question that is not Text, PlainText, MultiLineText, Radio, or RadioCheckbox. Using any other question type for this locator will result in a Reconcile Record screen with no input for the question.

Example: If the primary question should be the subject’s unique subject number, located in the form ‘Screening Summary’ in ‘Screening’, the path may look like #screening.screeningSummary.subjectNumberBy default, this question and its answer are displayed in the Pinned Questions bar but can be removed by the user.

  1. secondaryQuestion:Enter the full path to the second question used to uniquely identify the record.
Note: As these are used to find subjects in Reconcile Record and that utility does not support all question types, please do not point this at a question that is not Text, PlainText, MultiLineText, Radio, or RadioCheckbox. Using any other question type for this locator will result in a Reconcile Record screen with no input for the question.

Example: If the secondary question should be the subject’s initials, located in the form ‘Screening Summary’ in ‘Screening’, the path may look like #screening.screeningSummary.subjectInitialsBy default, this question and its answer are displayed in the Pinned Questions bar but can be removed by the user.

Setup/Display Attributes

  1. initialFormToDisplay: Enter the full path to the form that should be displayed when a record is first created or enrolled.
    • Example: #baseline.registrationForm
      The default is the highest level form summary.
  2. isQuestionAbove:
    • Enter ‘yes’ if questions should appear above the form summary on container forms as shown in the following example:
    • Enter ‘no’ if questions should appear below the form summary on container forms as shown in the following example.
    • The default value is “no”.
  3. useNodeTreeForECRF:This field is not used in the user interface and should be left blank for trials using the interface.
  4. collapseTreeOnInitialEntry:
    • Enter ‘yes’ to collapse the form tree when navigating between records.
    • Enter ‘no’ if the whole form structure should be displayed.
    • The default value is “no”.

Data Management Attributes

  1. deleteType: This property has been deprecated. See Deprecated Section for description.
  2. useMetaData: This property has been deprecated.See Deprecated Section for description.

Data Entry Attributes

  1. useSavePrompt: This property has been deprecated. See Deprecated Section for description.
    • Regardless of this setting, when values have been modified on a form and the user attempts to navigate to another page within the Fountayn application without saving, the user will be notified that there are unsaved values on the form.
  2. saveOnExit: This property has been deprecated. See Deprecated Section for description.
  3. enterKeyAction:Enter one of the following:
    • None – Disables the “Enter” key on forms. No action will be taken when the “Enter” key is pressed.
    • Submit – Allows users to submit the form by hitting the “Enter” key. This is standard functionality for most browsers.
    • nextField – Attempts to forward the cursor to the next field on the form, functioning similarly to the “Tab” key.
Note: This property obsoletes the old property “allowEnterSubmit”.
    • Old DataArchitect files that have the “allowEnterSubmit” property will still work, and will be interpreted as follows:
    • ‘Yes’ in allowEnterSubmit is equivalent to ‘submit’ in enterKeyAction.
    • ‘No’ in allowEnterSubmit is equivalent to ‘none’ in enterKeyActions.
  1. changeReason: In separate cells, list the reasons that will populate the View Choices list next to the Reason for Change field.

DA Example:

Query Feature

The query feature is defined within the Application Setup and the Roles worksheet. The Roles worksheet is where the designer can define what query actions each role can perform. The Application Setup defines whether or not a comment is required when a query status changes.

  1. queryStatus: The common list of query statuses includes:
    • unconfirmed
    • new
    • answered
    • declined
    • reopened
    • closed
  2. requiredComment: For each query status:
    • Enter ‘true’ if a comment should be required when a query changes to the specified status
    • Enter ‘false’ if no comment is required
    • The default value is “false”.
Note: Typically comments are only used on the query statuses ‘closed,’ ‘reopened,’ and ‘answered.’
  1. Repeat steps 1 & 2 for each query status used in the trial.
  2. queryComment: In separate cells, list the reasons that will populate the View Choices list whenever a query comment is required while working in the casebook.

In DA:

Not Done, Not Known, Not Applicable

Setup → Data Entry

The ND/NK Feature allows a user to mark a question as Not Done, Not Known or Not Applicable when a blank edit check fires. The feature also allows marked export values to be exported in order to identify the value.This is a study-wide feature and cannot be enabled for individual forms or questions.


Note: The Missing Data Flag options only apply to standard exports, the defined values will not export out in a custom mapped export.
  1. Included: For each type of Missing Data flag that should be included, enter an X in the ‘Included’ column for that particular row. If the Missing Data flag should not be included, this field should be left blank.
  2. Missing Data Flag: There are 5 defined Data Flags that can be implemented into each application:
    • notExpected – when blank values are not expected to have an answer, such as Pregnancy fields when the subject is male.
    • notSet’ – for fields that have the Not Done/Not Known data flags are enabled but the user does not set the field.
    • notDone – for blank values where an answer option is not entered.
    • notKnown – for blank values that the answer option is not known.
    • notApplicable – for blank values that an answer option is expected but for which the value is not applicable for a particular subject.
Note: All 5 options are possible "background" values, meaning they can all provide values to the exports. Only 3 (notDone, notKnown, notApplicable) can be explicitly selected through the interface. The notSet flag is automatically given if no other missing data flag is clicked by the user on a question which is expected if there is a dependency with checkIfBlank set to yes and the edit check's expression causes that alert to fire. The notExpected flag is given instead of the notSet flag if there is no dependency with checkIfBlank set to yes or it is not fired.


  1. Definition: Enter the text to be displayed when the user moves their cursor over the missing data option.
  2. Number: Enter the value for when the Missing Data Flag occurs on a question that expects an Integer or Float.
    • This defined value will be included in the export.
  3. Alpha: Enter the value for when the Missing Data Flag occurs on a question that expects a String.
    • This defined value will be included in the export.
  4. Date: Enter the value for when the Missing Data Flag occurs on a question that expects a Date. The value entered must be in a Date Format that fits the date format of the question. Currently there is an outstanding issue for the case that the Missing Data Flag is used on multiple questions with have different date formats. Note that Excel prevents the date from being correctly displayed if the date is before 01-JAN-1900.
    • This defined value will be included in the export.
  5. Display Name: Enter the defined value that will display on the screen for the user to mark the appropriate flag such as ‘Not Done’ or ‘Not Applicable.’
Note: When you use a “Check If Blank” dependency and it fires because of the empty value, the Missing Data Flag Handling is processed. It is not possible to disable the Missing Data Flag handling for selected questions.



Additional Deprecated Attributes

The features below have been either discontinued or superseded by a new feature.

  1. allowEnterSubmit: Defines if the user can submit the form by hitting the “Enter” key from an active field.
    • Acceptable Values:
      • Yes – Users may submit the form by hitting the “Enter” key.
      • No – Disables the “Enter” key on forms. No action will be taken when the “Enter” key is pressed.
  2. keyName: The keyName is the unique, CamelCased string identifier defining the DataCollector application within the system; i.e., the project name. This value supplies the name of a directory where the configuration information will be stored, and it is a required parameter in each request to that application. It is the string that uniquely identifies each DataCollector application in the Fountayn system as a whole. This string identifier must start with a letter and contain no spaces or special characters. This should follow variable naming convention for Java, which helps to distinguish between fields, arguments and local variables.
  3. deleteType: This property has been deprecated. In previous versions, this property designated what happens when the user attempts to delete a record.
    • The system sends the deleted record to a “recycle” bin. This temporarily deletes the record, which consists of changing the record flag and marking the record as “inactive.” These records can be restored.
  4. useMetaData: This property has been deprecated. In previous versions, this property designated if the application should store management data concerning the forms.
    • Tracked metadata includes signature status, answer status, query status, etc.
  5. saveOnExit: Enter ‘no’
    • This property has been deprecated. In previous versions, this property designated if the system will attempt to save new form values when an user exits without saving.
  6. useSavePrompt: Enter ‘yes’
    • This property has been deprecated. In previous versions, this property designated if the system will prompt to confirm that they want to leave the page when values have been modified on a form an the user attempts to close the browser window or navigate away.


Need more help?

Please visit the Fountayn Contact Information page.