There are multiple search methods used throughout the SP application. The following sections highlight:
- Different search methods in SP
- How each method works
- Which areas of SP use the various methods
- Search limitations of the methods
Default Search
Objects will use the default search functionality unless otherwise specified.
This method wraps the entire search string with asterisk wildcards on both ends and returns anything that has the exact search string matching in the answer value.
When searching for non-date form elements, these behave like a keyword search. The behavior follows the same behavior described above.
Depending on the object type, there are some nuances when searching for non-form elements (examples, proposal number, project title, and status). For example, the Proposal number behaves like a keyword search similar to the form elements.
However, objects like Project Title and Status work in the following way:
- When there is only one search term entered, it will work like a keyword search
- When there are multiple search terms, each term is treated as if “or”is between them. For example, if searching for Test example title, this is transformed to searching for *Test example title*, which returns any record that includes the term *Test OR the term example OR the term title* (where * is a wildcard).
Search Limitations
When using the following special characters with default search, it is best to only search for characters before or after the special character, or use "" (quotes) around the entire search string: \ + - ( ) : ^ [ ] { } ~ * ? | & / #
If “” (quotes) are used, the full answer needs to be included. See the Dashboard Search - Encapsulating with Quotes section below for more specifics about using quotes on a dashboard.
In general when using the default search method, different object types have slightly different behaviors. We are working to update all of the object types to have more consistent behavior aligning with one of the described search methods in this article (timeline TBD).
Search Method 1: “Fuzzy” Search
This method splits the search string into terms and allows the search to be done using those terms.
When using this method, the returned result will not necessarily start with the specified term/search string. When there are multiple search terms separated by a space, this method “ANDs” all terms, meaning the returned results must contain all of the search terms listed somewhere in the value. This method is the most flexible and is more useful for columns/objects with lots of unique values.
Attributes on dashboard that use "fuzzy" search:
- AU/NZ Classification Code Object Attributes
- Created by
- Checkboxes - SFB Only
- Drop down (single)
- Drop down (multi) - AFB Only
- External Organization Finder Objects
- Funding Program Object Attributes
- Multiline Text - AFB Only
- Person Finder Objects
- Radio Objects
- Research Team Name
- Research Team Employee ID
- Research Team External Association Name
- Research Team External Association Org Type
- Research Team External Association Primary Code
- Research Team Internal Association Name
- Research Team Internal Association Primary Code
- Text Objects
- Textarea Objects - SFB Only
- Unit Finder Objects
Object types that use "fuzzy" search:
- AU/NZ Classification Code Objects
- External Organization Finder Objects
- Funding Program Objects
- Person Finder Objects
- Research team object (External Association field)
- Research team object (Internal Association field)
- Research Team object (Name field)
- Unit Finder Objects
Example
You are searching for John Jacob Smith in the Admin Module using “Fuzzy” search.
Old search method:
- Searching for John Smith would not return the desired user.
- In order to get the correct search result, you would need to search for only John, only Jacob, only Smith, or the full name of John Jacob Smith.
- Using partial search would work fine in this scenario if the person’s name was “John Smith”, with no middle name.
Updated search method:
- Any portion of any of the names can be used in the search and all users containing a match for all listed terms will be returned.
Searching for ohn aco will return the result of John Jacob Smith as it contains both "ohn" and "aco".
Search Limitations
When using the following special characters with “Fuzzy” search, it is best to omit the special character and instead use a space to search for the characters before and after the special character: \ + - ( ) : ^ [ ] { } ~ * ? | & / #
If the special character is included, quotes can be used around the search terms, however, when quotes are used, full words have to be used as well. See the Dashboard Search - Encapsulating with Quotes section below for more specifics about using quotes on a dashboard.
Search Method 2: Prefix or "Start-With" Search
This method only returns matches that start with the listed search characters.
This method is more useful for attributes that have a predefined list of options, especially if several of those options have similar names, like the research team role.
If the “fuzzy” search method was used for items like the research team role, it would be impossible to return only results for a role like "Investigator" as results for roles like "Principal Investigator" or "Co-Investigator" would be included in the results.
Similarly, “Gender” would have the same issue, as searching for "male" would always include results for "female" if the “fuzzy” search method was used. Using the “start-with” search method allows those attributes to be narrowed down to only those desired.
Attributes on dashboard that use prefix (“start-with”) search:
- Role
- Gender
- Ethnicity
- Citizenship
Example
You are searching for the role of “co-investigator” in Admin Module using “Prefix” search.
- Searching for "co" will return the correct result.
- Searching for "co-invest" will return the correct result.
- Since "investigator" is not the beginning of the role name, it will not return the correct result.
Search Method 3: Numeric Search
This method not only supports searching for numeric values that match, but also supports relational operators (“>”, “<“, “>=”, “<=”).
For example, if Credit was selected on a dashboard search, the characters "> 50" could be entered to return all records that have any research team member with a credit greater than 50%.
Note that this method requires an exact match, so searching for "5" would only return results that have "5" in the field. No results for things like "15", "50", etc. would be included with this method.
Attributes on dashboard that use numeric search:
- Credit
- Total Effort
- Cost Share Effort - Academic
- Cost Share Effort - Calendar
- Cost Share Effort - Summer
- Sponsored Effort - Academic
- Sponsored Effort - Calendar
- Sponsored Effort - Summer
Dashboard Search - Encapsulation with Quotes
Encapsulating search terms with “ “ (quotes) on any SP dashboard will search for a strict exact match for most form objects (exceptions noted below). This behavior applies to object types that use the default search or fuzzy search methods mentioned in previous sections.
A strict exact match means the full answer value must be provided.
For example, if a record has the project title Example Title: Containing a Colon, in order to find this record on the dashboard search, a user could search for Example or Example Title without needing to use quotes. But if the : character was included, then the search characters would have to be encapsulated with “” and the full title would need to be included. Meaning, searching for "Example Title: Containing a Colon" would return the record, but searching for "Example Title: Including" would not since that isn’t a strict exact match for the record’s project title.
The object types that have slightly different behaviors regarding encapsulating the search terms with quotes are:
- Rich text
- Attachment
- Checkboxes (SFB only)
- AU/NZ Classification Codes
- Drop down (multiple)
For the first four object types, the difference is that because of the stored answer format, when using quotes, a “pseudo-strict” exact match approach is applied instead of a true strict exact match. This approach will return any records that have the fully encapsulated search terms in the listed order.
This means that if there are three records, one with a rich text field answer of example answer 1, a second with a rich text field answer of example answer 2, and a third with a rich text field of answer example, searching for “example answer” will return only the first two records as they both contain the fully encapsulated search term within the answer. Even though the third record contains both example and answer, it doesn’t contain both terms in the searched order.
For the drop down (multiple) object type, the answer is stored with [ ] (square brackets), so if trying to search for an exact match using “”, the square brackets need to be included as well.