Frequently Asked Questions (FAQs)

All form fields have a defined audience that dictates who the field will be visible to and how it can be used on specific form types.

The Applicant audience should be used to capture input on Applicant forms. These fields only allow one entry per application - even when the field is on multiple forms.

Click to view an example

The Grant Manager creates a new Applicant field named Project Title. The field is added to two different forms - the Request form and Supplemental information form. The Applicant will enter the value for the field in the Request form, and it will be shown in the Supplemental information form. If the value is changed in either form, then it will overwrite the value for both forms.

Note: Applicant fields can be added to Grant Manager forms as read-only.

All form fields have a defined audience that dictates who the field will be visible to and how it can be used on specific form types.

The Grant Manager audience should be used to capture input on Grant Manager forms. These fields allow multiple values per application to support instances where multiple Grant Reviewers need to provide feedback. When used on multiple forms, it is considered a separate instance of the field.

Click to view an example

The Grant Manager creates a new Grant Manager field named Score. The field is added to two different forms called Review Scoring and Review Scoring - 2nd round. The Score field contains unique values for each form and for each user that completes each form.

Note: Grant Manager fields cannot be added to Applicant forms.

Encrypted fields offer an additional way for clients to securely store data while keeping the application process streamlined for the Applicant and not interfering with the review experience for Grant Managers. You may wish to store information related to finance, health, or personally identifiable information that should be protected against unauthorized users with this additional level of protection in the GrantsConnect database.

Data is masked to hide it from authenticated users who are not authorized to see this data. Data is encrypted to make it useless if the data becomes compromised.

Examples of sensitive data that may benefit from encryption include:

• Social security numbers

• Bank account numbers

• Health-related information

• Wages

• Financial data

Additional encryption is only available for the following field types:

• Date

• External API

• Number

• Picklist

• Radio buttons

• Select boxes

• Text

• Text area

No, they cannot.

If an existing form field is on a form (Draft or Published), additional encryption cannot be added to it. This is regardless of whether the form has been added to a program.

There will be no indication to the Applicant that the field is encrypted when completing the form. They can see the values they enter and edit them just as they can with other fields in the form.

Unlike those for field masking, special permissions are not required to view and edit encrypted fields. This is because the data is encrypted at the database level.

Encrypted fields are visible in Ad Hoc reporting, dashboards, Data Hub exports, and applications just like any other field. However, they will not appear in searches and filters.

Yes, they will be included in data feeds. They will be decrypted and transmitted in the data feed.

Field group options are the individual fields that make up a Field group field. An example is outlined below.

• Disabilities [Field group]

  • Diseases/Illnesses [Field group option]

  • Hearing Disability [Field group option]

  • Visual Disability [Field group option]

  • Ambulatory Disability [Field group option]

  • Self-Care Disability [Field group option]

  • Other Physical Disability [Field group option]

  • Mental Disability [Field group option]

  • Learning Disabilities [Field group option]

  • Developmental Disabilities [Field group option]

Although both field types allow the Applicant to select options using a checkbox, there are two significant differences between them.

1. The values in a Select box field are from a custom data table while the values shown in Field group fields are configured using Field group options.

2. Field group options can be reported on individually where as the options within a Select box field cannot.

   Note: For more information about adding Field group options to reports, see the Field Types in Reports > Field Groups resource in the Frequently Asked Questions for Ad Hoc reporting.

   View example of Field group report

   Field group options are represented as an individual field or column when a Field group field is pulled into an Ad Hoc report.

   

   View example of Select box report

   The values in a Select box field are listed in a single column when pulled into an Ad Hoc report.

   

One benefit of the Field group field is being able to report on the individual options within the group rather than just the field itself as you would with the Select box field. For more information and examples, see the What is the difference between a Field group field type and the Select box field type? question above.

Field masking is a way for clients to change the visibility of fields so that users that are not authorized to view the data are unable to do so. Masking is offered on fields with an Applicant audience only so that Grant Reviewers cannot see information that may be sensitive or affect the review process. This is an additional layer of masking at the custom form field-level.

Masking is only available for the following field types:

• Date

• External API

• Number

• Picklist

• Radio buttons

• Select boxes

• Text

• Text area

No, it is not. There are multiple ways to manage masked data, including:

• Turn masking on at the field level - Select the Field masking option for the specific field.

  Note: If data is only masked at the field level, then the Grant Applications - Can View Masked Data permission is required to view this data. However, this will be overridden if the workflow level or sub-level specifies users can view masked information.

• Turn masking on at the program level - In the Program Details > Settings, enable the Mask Applicant information option to mask all Applicant data regardless of the field setting.

  Note: If data is masked at the program level, then the data all fields will be hidden unless either the user has the Grant Applications - Can View Masked Data permission or masking is turned off at the workflow level or sub-level.

• Turn masking off at the workflow level or sub-level - Select the Show masked applicant information option for the workflow level or sub-level to show masked data regardless of the field or program settings.

  Note: If data is masked at the workflow level, then the Grant Applications - Can View Masked Data permission is required to view this data.

Only users with the Grant Applications - Can View Masked Data permission can see masked fields.

Note: If the workflow level or sub-level has the Show masked applicant information option enabled, then this permission will be overridden and any users in the level or sub-level will be able to view the data regardless of their permissions.

The experience will differ based on the user's permissions.

• If the user has the appropriate permissions, then there will be a toggle to show or hide the data in this field.

• If the user does not have the appropriate permissions, then the data in the field will appear as a series of asterisks (i.e., *******). There will be no option to show or hide the masked data.

Note: This applies to all areas where this information is shown, including Ad Hoc reports, dashboards, and the Data Hub.

There will be no indication to the Applicant that the field is masked when completing the form. They can see the values they enter and edit them just as they can with other fields in the form.

No, they cannot.