Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Child Articles Underneath This Parent Article

Children Display
alltrue

Table of Contents

Table of Contents
outlinetrue

...

Before you begin: Please make sure to refer to the Employee Reference Guide as well.

Website URL

The main landing (home) page for WPP's Fluxx instance is: https://wpp.fluxx.io/user_sessions/new

...

Record Types

To organize data properly, the data is managed with several unique record types.

...

All of these record types can be displayed in various ways using Cards – more on that in the Cards section, below.


The main record types that the WPP uses are:

...

These records store data on the organization that submitted the request (or, in PERC's case, shows data relating to the PI Principal Investigator of the project). In OAC's case, they also store the the Tax ID of the organization in question.

...

These records store all of the data related to grant applications, and subsequently grants if the application is approved. Request/Grant records are the central record from which all other records in the system link in one way or another.

People Records

These records store information regarding the person or user who is signing into Fluxx. These records store the email addresses, titles, and login information (i.e. password) of the users in question.

...

A view of ALL of the various Cards available in the system:


Finding Linked Records On a Card

There is a relationship between these the records types listed above. Please see the diagram below which outlines exactly how every data type connects to every other type within the Fluxx database (as you can see, the Request/Grant is at the center of all connections):

...

All Forms are edited via the Admin Panel. Please see the dedicated Admin Panel page for detailed information on how to edit forms.

...

Note: Not all records that are returned are necessarily related to the Request I'm trying to look for. As you can see from my screenshot, below, the Requirement that is returned is NOT related to the Llama Rescue Inc. testing grant application, but was returned by the Universal Search because it's ID (requirement ID) is also 5014.


More on Searches under Search Functionality page.

Correspondence with Grantee in Fluxx

Within Fluxx, there are many different ways to generate correspondence to grantees. Additionally, Fluxx has a way to store correspondence that occurs outside of the system to records that exist within the system.

...

Letter: The user can generate longer-form documents that dynamically pull in fields from the related Grant Request; these are called Letters. These letters can be a big time saver; for example, in the past Partnership Program staff might have needed to manually write up the whole Grant Award Letter, but with the Letter functionality we can automate the generation of the Grant Award Letter from data we already have.

Record Locking

Record locking is the technique prevalent across computing software platforms of preventing simultaneous access to data in a database (such as Fluxx), to prevent inconsistent results.

The classic example of what can occur without the use of record locking is demonstrated by two bank clerks attempting to update the same bank account for two different transactions in a system lacking record locking. Clerks 1 and 2 both retrieve (i.e., copy) the account's record. Clerk 1 applies and saves a transaction. Clerk 2 applies a different transaction to his saved copy, and saves the result, based on the original record and his changes, overwriting the transaction entered by clerk 1. The record no longer reflects the first transaction, as if it had never taken place.

A simple way to prevent this is to lock the file whenever a record is being modified by any user, so that no other user can save data while the first holds the lock. This prevents records from being overwritten incorrectly, but allows only one record to be processed at a time, locking out other users who need to edit records at the same time.

To allow several users to edit a database table at the same time and also prevent inconsistencies created by unrestricted access, a single record can be locked when attempting to edit or update it. Anyone attempting to edit the same record is denied edit access because of the lock (although they are be able to view the record without editing it). Once the record is saved or edits are canceled, the lock is released. Records can never be saved so as to overwrite other changes, preserving data integrity.

What It Looks Like in Fluxx

In Fluxx, all records are always readable. However, when you go to "Edit" the record, you may encounter a message stating that the record you are attempting to edit is locked and will also say which user is locking the record. An example of the message can be seen here:

Image Added

When the user who holds the lock Saves & Closes out of the record (i.e. their view returns to the "view-only" view), the record can be edited by the second user. The second user will then hold the lock on the record until they also Save & Close the record.