...
This section is for recording database decisions for administrators. Please review carefully to get context before making related system changes.
...
New Application Cycle Launch Checklist
There are common steps you'll need to take for each new application/program cycle that goes live. This section covers the key things you'll need to do/keep in mind.
1. Update existing forms for new program cycles
A big part of Fluxx administration is updating grant request and request review forms in preparation for new application cycles. Rather than copying forms for each new year (which, as you'll see historically, gets messy fast), update the existing form.
Quick note: If you remove a field from the form, this does NOT delete the information from the record. For example, if you remove the "Project Title" field from the CHSP form, and then you perform an Excel export on that record, the project title will still be populated.
Best practice if a field is no longer relevant to a given program is to create an employee-only section that has that field. Include relevant contextual information, such as the year(s) a given field was in use. This will make it easier for the average Fluxx user to access relevant historical details without having to do a more in-depth database search. Grants aren't editable by grantees after they're granted/declined/withdrawn/closed, so this does not present a problem for previous grant cycles.
Similarly, validations should be turned off after an application reaches the granted state, so even if you add new required fields it should not impact old grants.
2. Ensure core request grant fields are present
Background: There are certain types of information that we always want to collect, regardless of application type. Often, the goal is to provide reliable reporting references so WPP staff can easily query across time, program category, and application to answer basic questions like "How much money has been awarded for cancer-related topics in the past 5 years?"
Therefore, the following fields MUST be filled out on ALL applications. If someone requests these fields to be removed, do not fulfill the request until you've verified with WPP or come up with an alternative plan to collect the pertinent information. Similarly, do NOT update the fields on dropdown lists without investigating potential impacts. For example, even if you're simply combining two fields into one, you'll want to think about whether it's appropriate to update existing applications with either of the old topics based on reporting needs. Contact with the WPP researcher/reporting contact to verify changes (Lindsay Barone, as of 10/4/23).
When a new program is launched, you should also check to make sure these fields are all present on the application form.
...
- Reviewer Feedback - Full App - Previously, there was one field for reviewer comments to be shared with grantees. Going forward, that field (previously review_summary, now Reviewer Feedback - LOI and Historical) should be labeled Reviewer Feedback - LOI and the full app field should be added to all templates (Internal > Reviewer Comments section).
- Grant ends at, Grant closes at, Original project end date - These three fields have been used together to indicate when the project ends (or originally ended). Grant ends at is a core calculated field, which requires updating the duration (months) field to change. WPP has decided not to use this field, and would like it removed going forward. Use ONLY Grant closes at and Original project end date (Key Information section)
- Organization Primary Contact Employee ID - This field is used on application forms to collect employee IDs, referenced by HR to determine eligibility (I think this might be PERC specific). When a new app goes live, check if this should be added.
- Academic Staff Indicator - PERC ONLY - Academic staff need to upload a document verifying PI status with campus to be eligible. Use this language in the question: "Do you have an academic staff appointment? If yes, please upload documentation of permanent PI status." Also, for CHSP 2024, we're using the Other Documents type. Might be subject to change.
...
3. Ensure core request review fields are present
Features that should be present on ALL Review records
- Send back to review button - In the Submitted state, make sure there's a button that allows any WPP internal staff to send a review from submitted back to pending
- Sometimes reviewers will ask to adjust their reviews based on discussions about the various grants, which happen after they submit. Since it's a standard workflow, program officers should be able to do this without having to contact an admin.
Custom Field Limits/Generic Fields
Although you can create as many fields as you like, creating too many will degrade system performance, not to mention making exporting data take forever.
...
- .
...
If you ever need to find out what information was intended to be collected, you can take the following steps:
...
...
There's more information littered across the WPP wiki about this issue, including, somewhere, a tracker (possibly on the N drive?). If you're ready to fall down the rabbit hole, here are a couple places to start:
Updating Forms for New Program Cycles
A big part of Fluxx administration is updating grant request and request review forms in preparation for new application cycles. Rather than copying forms for each new year (which, as you'll see historically, gets messy fast), update the existing form.
Quick note: If you remove a field from the form, this does NOT delete the information from the record. For example, if you remove the "Project Title" field from the CHSP form, and then you perform an Excel export on that record, the project title will still be populated.
Best practice if a field is no longer relevant to a given program is to create an employee-only section that has that field. Include relevant contextual information, such as the year(s) a given field was in use. This will make it easier for the average Fluxx user to access relevant historical details without having to do a more in-depth database search. Grants aren't editable by grantees after they're granted/declined/withdrawn/closed, so this does not present a problem for previous grant cycles.
Similarly, validations should be turned off after an application reaches the granted state, so even if you add new required fields it should not impact old grants.
Document Type Prefixes
You'll notice a lot of Grant document types have a prefix like F07A. The purpose of the prefix is to enforce a consistent sort order in the Document Group on application forms. Doc types without a prefix might be retired or intended for internal or ad hoc use (ex. MOUs).
...
Examples: F12A, P01O, etc.
Custom Field Limits/Generic Fields
Although you can create as many fields as you like, creating too many will degrade system performance, not to mention making exporting data take forever.
To prevent performance issues, do not create more than 150 custom fields per record type. To get the most out of existing fields, we have a policy of creating generic fields which can be reused for different purposes on different forms. The downside is that when exporting, we can't see what field name/prompt was so it's not apparent what information was intended to be collected on each form.
If you ever need to find out what information was intended to be collected, you can take the following steps:
- Export the field value for all records
- If the field is included in the default export card, you can just create a dashboard card with no filters and export Excel
- If the field isn't included as a default export, create an ad hoc report that returns the record ID, model theme name, and the field value
- Filter results to find which model themes used said field and the creation date
- Look up the affected themes (either via card filtering or the Admin Panel) and check the configured field name/surrounding text
There's more information littered across the WPP wiki about this issue, including, somewhere, a tracker (possibly on the N drive?). If you're ready to fall down the rabbit hole, here are a couple places to start:
Permissions
If a user says they can see a record but can't edit, it's likely a permissions issue.
...