This page contains important information about Fluxx workflows, limitations, best practices. If you are new to Fluxx, watch the training videos first, and then come here before diving into build! |
This section is for recording database decisions for administrators. Please review carefully to get context before making related system changes.
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.
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.
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).
When a new program is launched, make sure these fields are all present on the application form.
Required fields (all applications):
Other changes to include (all applications unless otherwise indicated):
Features that should be present on ALL Review records
Fluxx has hard-coded the project summary field to be required on all grant records. However, WPP doesn't really use this field. If for whatever reason you absolutely must make a new grant form, you'll need to add a bit of code to the template to auto-populate some dummy text.
If records have already been created and the project summary is blank, you have a couple options:
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).
Doc sort order is controlled in the Admin Panel > Global Settings > General Settings in the Sort Documents By field (ctrl+f to find). We decided not to sort by file name due to the likelihood of error and to avoid burdening grantees. Also, we didn't use a simple 1, 2, 3 naming convention because not all document types are used for each application, which might spark some confusion for grantees.
The naming convention looks fancy but is pretty straightforward. Each code has 4 digits:
Examples: F12A, P01O, etc.
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:
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:
If a user says they can see a record but can't edit, it's likely a permissions issue.
Permissions work like this: Users can be restricted access to certain workflow states EITHER by updating the state permissions or, most commonly for grantees, filtering certain states out of their dashboards.
Finance Review state details are shown on the right
However, even if a user can see records in a specific state, they can't edit UNLESS their profile has access to one of the Workflow buttons in that state.
For example, in Bundle Stage below, all profiles can see records this state, but only users with the Grants Management Staff profile can edit records in this state. This is because there's only one button, Send to Program Review, which only Grants Management Staff have access to.
This is more of a call-out for specific tools that are extremely helpful but took me a while to find. Hopefully this saves you time and headaches!
First, a lot of important tasks, such as applying filters or exporting data, can be taken directly from a dashboard card. The training videos touch on some of them, but they're worth calling out.
Some additional things to note:
Note: Not all WPP staff will have access to all of these tools.
One of the Card Actions options, it's worth its own call out due to its versatility–it does more than the name implies.
Any action taken applies to all records in a card, so make sure your filters are configured correctly before taking any action! |
You can choose an email template to generate messages for all records in the card--even disabled templates! These messages follow queueing rules for the email template, i.e. if Autosend is turned on, they are sent automatically and don't show up in the queue.
You can update records' attributes (i.e. fields) and statuses en masse. For example, during the progress report workflow changeover, the previously separate statuses of Finance Review, NSQ Review, and Program Staff review were combined into one new status. New fields were added to indicate each reviewer type's comments or approval, so for old forms I used bulk update to apply a generic message "Approved - see notes for details" to indicate who had already finished review.
Note that this tool only lets you apply the same value for all filtered records. If you need to update multiple records to have different values, this tool isn't much more efficient than just looking up each record and updating manually.
The migrations option is really nifty if you need to make a bunch of updates to a lot of different records. Documentation here, but honestly I had more success copying an existing config. NCE Updates or Grant Demographics Consolidation both worked (check the settings carefully!!).
A couple considerations: