A user reference field is a search box of your instrument's user accounts that are tracking activities. User reference fields are used to associate records with user accounts. Records with which a user has been associated are visible to that user. An example of User Reference usage in Faculty Success is the Authors DSA on the Intellectual Contributions screen, which enables a user to associate co-authors with a single intellectual contribution record.
User reference fields will always display the name of the user followed by their Faculty Success username.
Important: When importing data from other systems, it is not always possible to populate user reference fields since the ability to do this depends on the way in which the systems provide the name data. In order to populate a user reference field, the import file must contain one or more columns of Faculty Success usernames or unique user identifiers. If the import file contains name fields only, we will leave the user reference question empty and the name data will be stored within the corresponding text fields. If a user subsequently tries to edit and save such a record,Faculty Success will force the user to select their name from a user reference field and delete the text entry of their name.
You can configure user reference fields in Faculty Success as either non-editable or editable. Non-editable is the default.
Non-Editable User Reference (Default)
By default, only the user who created a record is able to edit that record.
Editable User Reference
User Reference can also be configured so all users associated with a record can edit the record. With Editable User Reference configured, collaborators will be able to update the records to which they are associated. However, only the record’s creator will be able to delete the record, or remove him or herself from the record if record ownership should shift.
This setting affects your entire data collection instrument. We cannot set this on a per-screen or per-field basis.
Warning: Screens with Editable User Reference fields cannot contain restricted fields, as different users may have different restrictions. Restricted fields are fields that only display for specific colleges or departments.
Determining the Record Owner for a Linked Record
There may be cases where a user needs to modify a record, or remove themselves as a collaborator. Records where the user is a linked collaborator, but not the owner, will appear with a Lock icon in the summary table. If editable user reference is not enabled, changes may not be made by the current user. If editable user reference is enabled, the account may still revise the locked record but will not be able to remove themselves as a collaborator.
For these cases, the primary record owner may be determined by adding a column to the summary table. Use the Select Columns feature and search for the "Record Owner" option. Once selected, the column will appear toward the far right of the table and display the name of the record owner. Either this user, or a user with the appropriate Manage Data permissions may then modify the record through this account.
In this example, the first four records were entered by other accounts and appear with a Lock icon. The records must be modified from or on behalf of the referenced record owner's account.
Disabling User Reference Linking
The linking feature of user reference fields can be set at the field level so users are not automatically associated with specific types of records. If User Reference is disabled, each user will need to enter his or her own records. For example, if two users co-author an intellectual contribution, each user will need to enter separate intellectual contribution records in Faculty Success. It will appear as though these are two separate intellectual contributions and it will not be possible for Faculty Success to recognize these two records as the same intellectual contribution. This will result in reports counting this intellectual contribution twice. Because of the resulting decreased flexibility in counting users' activities, Faculty Success does not recommend disabling user reference fields.
Warning: When an existing user reference field has linking disabled, we do not automatically create records for the referenced users. If you would like Faculty Success to create records for each referenced user, specifically state this in the Screen Revision(s) work request that you submit.
Auto-Population and User Reference Significance
If only one DSA section with a User Reference field exists on a screen, Faculty Success will auto-populate that field with the name of the user on whose behalf the record is entered. If more than one DSA with a user reference field exists on a screen, neither user reference field will be auto-populated with the name of the user on whose behalf the record is entered. User Reference auto-population does not occur in this instance, as Faculty Success cannot know which DSA to populate. However, the name of the user on whose behalf the record was entered must be selected in at least one DSA before the record can be saved. For example, if the Publications screen contains separate authors and editors DSAs with User Reference fields, you must select the user on whose behalf the record was entered as either an author or an editor.
You can request that Faculty Success disable the auto-population feature. This is called removing User Reference Significance. However, one drawback of disabling auto-population is that users will have to enter their own name in the user reference field. Many users will fail to do so, resulting in incomplete records that list only collaborators or no one at all. You can add instructional text to the screen, but this does not ensure that users will comply. You cannot make the user reference field required, as doing so would prevent users from saving records when a collaborator does not have a user account. We do not recommended disabling auto-population, as it will have a negative impact on more users than it will benefit.
Note: If a user – User A – is linked to a record through a User Reference field, but does not want that shared activity to appear on their reports, they should contact the record's owner – User B – using the link provided on the summary screen. User A can then ask User B to deselect their name from the field, and instead type their name into the input fields. The record will no longer show up for User A, but it will show up for User B who entered it. Alternatively, you could disable the linking functionality that shares a record with all users to whom the record it is linked. This is a setting on the User Reference field. Of course, this has trade-offs, such as requiring each person involved in an activity to enter that activity individually and preventing simple unique counts of activity records in department-, college- and campus-level reports.