Request Fields

Can we re-use request fields in different progress report forms without the data being overwritten? I am now creating our progress reports for 2026 grant awards and would like to use the Request fields that were used in the application/request to update the programmatic status of those on a quarterly basis. Can I use these or do I need to create Requirement fields instead? And if I need to create requirement fields, do I have to create unique fields for each of the 4 quarterly reports?

I found this on Help:

Form fields are used in custom forms to capture information from Applicants, display responses to Grant Managers, and more. Fields can be reused across forms, and standard product fields are available out-of-the-box to quickly create forms that integrate with other standard product templates like reports.

But does that mean the prior data for that field will not be overwritten with a new form; example Progress Report 1 (field x); Progress Report 2 (field x)? And does it matter if that field is from a request record used in a requirement form?

Tagged:

Answers

  • Per BB:

    If you use a request field on a requirement form, whatever is entered into that form will overwrite any data already in that request field.  

    For example, if you added "Request:Project Description" to a requirement form, when that was submitted, whatever the applicant put into that field would be updated on the request record.

    Generally, it's best to use Requirement fields on Requirement forms, because each requirement form has a separate record so each time you create that requirement, there would be an "empty" field ready to collect data.

    All requirements for a given request would be associated with that single request, so if you use a request field, it will update the request record, overwriting anything previously in that field.

    Within a program, any repeat use of fields may not have the desired experience.  Here's an example scenario:

    1. I submit an application which is considered and turned into a request.
    2. I create a quarterly progress report requirement, and publish out my requirement form named "Requirement Progress Report"
    3. On that requirement progress report, I have a requirement field named "Update". 
    4. The first time I submit this Requirement Progress Report, that data will flow into a requirement record.
    5. If I create another requirement record and publish the same form again the next quarter, the system will view that as a revision.
      1. Your grantee would receive an email indicating a revision has been requested
      2. When they log into the portal, they'll be requested to revise that previously submitted requirement progress report.
      3. When they open the report, all of their previously submitted responses will be pre-populated.  Those can certainly be changed and submitted.
    6. Grantmaking would still retain the data that was submitted from the first report on the separate requirement record.
    7. In order to prevent this from being seen as a revision, you would need to create an additional Requirement Progress Report form - perhaps "Requirement Progress Report #2".  If you have a separate form, then the system will treat it as a new requirement and not as a revision.
    8. However, if you have the requirement field named "Update" on both the first form and the second form, when you publish the second form out, that field will automatically prepopulate with the data they submitted in the first form because that field was already used once in that program.
    9. To avoid having any data prepopulate, you would need to create unique fields for each form, so you could have "Update" on your first form, and "Update 2" on your second form.  Because these are unique fields and are on separate forms, you would collect clean data and not prepopulate anything.
  • We are also experiencing this issue. At the very least, it would be convenient if they gave me an import function for the 900 new custom fields I am going to have to build out to ensure that fields don't auto-fill with a previous submission. I have grantees that complete monthly reports over the course of multiple years, up to five. At a minimum, I have 14 fields for each monthly report, that is 840 new custom fields. Then more for annual summaries and another grant type with quarterly reports. This is not a reasonable solution. Also, why would they have a selection that allows us to "pull from BBGM" and then pull data from previous submissions automatically? This process is inefficient and poorly managed.

  • Yes, waiting for BB to fix this issue - completely ridiculous situation to have to have multiple versions of the same report - if they don't fix it, they will be losing a lot of clients to other more user friendly platforms!

  • Hi - we seem to be having a similar issue which is really frustrating and creating a lot of extra work!

    In a nutshell, we've created a 2nd stage application form and when tested, some of the answers were pre-populated with answers from another application form.

    Where someone has posted about a similar issue, the response from Blackbaud is that "to avoid having any data prepopulate, you would need to create unique fields for each form." 

    Up until now, our understanding was that the fields aren't be used twice in one form but hadn't realised that you can't use them if you are creating two application forms for one programme that has a 2-stage application process.

    Our understanding is that brand new fields will need to be created which will be time consuming.

     Our questions are: 

    • as Blackbaud are suggesting creating unique fields for each form, does this mean that the field limits have been removed?
    • as this is not an ideal situation, can this issue please be fixed?
  • Arancha  Lattanzio
    edited February 11

    Just letting everyone know in case it wasn't clear, I agree with all these comments. I was just posting the response from Blackbaud. vote on the IDEA about this:

Categories