April 9, 2024 - SP 4.0 Release Notes v3 – Cayuse Help Center

Information on this page is subject to change. This page was last updated April 19, 2024.

Please note: In order to enable the following release changes to your environment, we recommend clearing your cache.

View SP 4.0 Public APIs

Release Summary

Here's a quick overview of the updates in this release:

Research team object updates
New funding programs object
Changes to the SP-S2S and SP-FM integrations

Release Dates and Downtime

Release dates are subject to change. Release date changes will be noted in the Change Log column below.

Downtime required: 30 minutes

Environment	Release Date	*Deployment Time (PST) Convert to your timezone**	Change Log	Redeployment Log
UAT-SG	Apr 9, 2024	10:00 am		All UAT environments will have a redeployment on the following dates with 30 minutes of downtime that includes two new fixes (see below): UAT SG - 4/25 @ 10 am UAT UK - 4/25 @ 10 am UAT AU - 4/25 @ 10 am UAT CA - 4/25 @ 3 pm UAT US - 4/25 @ 3 pm
UAT-UK	Apr 9, 2024	10:00 am
UAT-AU	Apr 9, 2024	10:00 am
UAT-CA	Apr 9, 2024	6:00 pm
UAT-US	Apr 9, 2024	6:00 pm
Prod-SG	April 23, 2024 May 2, 2024	10:00 am
Prod-UK	April 23, 2024 May 2, 2024	10:00 am
Prod-AU	April 23, 2024 May 2, 2024	10:00 am
Prod-CA	April 23, 2024 May 2, 2024	6:00 pm
Prod-US	April 23, 2024 May 2, 2024	6:00 pm

Detailed Release Notes

New: General

The Research Team object has been updated to add some additional options, as well as allow flexibility to configure which options to include (see more details below)
Additional accessibility improvements have been made on Dashboard pages and the My Task slideout.
A new form object for Funding Programs has been created that can be added to any form from Simplified or Advanced Form Builders.
- The new form object can be used to search for and select multiple active Funding Programs where each can contain one Funding Round.
- The new form object values can be included in .csv exports of SP data, as well as displayed in the SP in-app award and proposal reports.
The system has been updated to better handle creating review rules based on objects that can potentially have multiple answers. Now, if a rule is set up for one particular answer on one of the object types listed below, even if the object is populated with multiple values, if one of them is the value associated with the rule, the rule will be triggered as expected (see examples below). Applicable form object types include:
- Person Finder
- Unit Finder
- External Org Finder
- AU/NZ Classification Code
- Funding Program
- Multi-select dropdown
In order to continue helping distinguish between people with similar names, the search results in all SP Person searches have been updated to show the following on separate lines:
- Person's name
- Person's email address
- Unit name for the primary association

This change applies within the following search components:

Person finder form component
Research team object form component Name field
SP Task assign to field
Assigned Admin field
Proposal Access tab person search

New: Data Enhancements

The following new data fields are available for display in SP in-app reports and downloadable .csv files (see additional details below):
- Resolution (can also be displayed on dashboards and used in the dashboard search field)
- Routing Tab table content (these new columns are not available on the dashboards)
- Funding Program Object (these new fields can be used in the dashboard search field). The SP APIs have been updated such that records can be created/updated that contain the Funding Program form objects.

New: Integrations

We have updated the system to ensure the SP<>FM integration is functioning properly.
The SP<>S2S integration object has been updated to provide three workflow options. See below for additional information and details.

Fixed

Added April 19: Fixed an issue found during initial UAT deployment of this release that was leading to errors with the dropdown object type on records.
Added April 19: Updated the system to use the ID/Key attribute for the form objects that are populated in the request to create a new S2S proposal instead of headerId.
Fixed an issue that was leading to the award Modification Date and Modified By columns not populating in the in-app report.
Fixed a case on the Proposals API response causing a null value to be improperly set to the string null.
Now that the research team object can be configured so that it is not required on a form, some users encountered an error in the situation where the research team object internal association field was left blank on a member that would otherwise trigger a research team review rule. In this case, when someone tried to complete a review for the rule prior to the research team review rule, it was leading to an error. After this update, the system will skip the research team review rule if no internal association value is provided.
The system has been updated to make sure that once a record is moved out of the review status, any review tasks left incomplete will also close. Please note: If there are existing cases where review tasks are still present for records that are no longer in the review state, a support ticket can be created to have those tasks deleted so that they aren't shown in the My Tasks home page or SP My Tasks slideout.
Behavior has been updated so that if an additional file is uploaded to a task within the same editing session, the file will be added to any others that were previously added instead of overwriting them.
Previously, the Attachments tab on an award was only showing files that were either uploaded directly to the Attachments tab, or any files that were uploaded to attachment form objects in the original version of the award. Now the Attachments tab will only show files that are present in the latest active version of the award regardless of how they were added.

Additional Details: Review Rules

Example

If there is a multi-select dropdown object, named Test Dropdown with answers A, B, C, and D, and the following rules are setup:

When Test Dropdown = A, require review from Team1
When Test Dropdown = B, require review from Team2
When Test Dropdown = C, require review from Team3
When Test Dropdown = D, require review from Team4

In the form, select A and C on Test Dropdown and route the form for review.

On the Routing Tab, there should be a line item for Team1 and Team3 since both were answered on Test Dropdown.

Additional Details: Data Enhancements

Resolution

A Resolution column can now be added to SP in-app reports, downloadable .csv files, and dashboards. This column displays the Resolution that was selected when the record was transitioned to the Closed status. This column will only be populated for records that are currently closed.

Routing Tab

Routing Review Order - maps to the "Review Order" column on the Routing tab
Routing Team - maps to the "Team" column on the Routing tab
Routing Members - maps to the "Members" column on the Routing tab
Routing Status - maps to the "Status" column on the Routing tab
Routing Date - maps to the "Date" column on the Routing tab
Routing Comment - maps to the "Comment" column on the History tab

In the report or downloadable .csv file, each Routing tab line item will be displayed on its own row, where only the record number columns are duplicated in each row (note: other columns like the research team columns or history columns may use multiple rows too, but columns with only one value will have "--" in the successive rows on the report, or be blank in the downloadable .csv file).

For awards with multiple versions, all routing entries will be associated with the latest version of the award in the reports and downloadable .csv files. This means that an award may have a row for the -0 version, -1 version, and -2 version (active version). All routing rows will be associated with the active version (-2 in this example).

Funding Program Object

Each available field on the object has its own applicable column that can be added to an in-app report, downloadable CSV, or dashboard. There are columns for:

Funding Program Name
Funding Program Status
Funding Round Name
Funding Round Status
Funding Round Year
Funding Round Internal Closing Date
Funding Round External Closing Date

The SP APIs can be used to retrieve funding program form object information to create records, or update records with funding program object details.

Additional Details: SP<>S2S integration object

The SP-S2S integration object has been updated to provide three workflow options:

The object still supports the ability to search for, and link, an existing Proposals S2S record to the SP proposal This is useful if the related S2S proposal has already been created.
The workflow to create a new Proposals S2S record has been updated to first start with searching for an S2S opportunity (images of the workflow below). The Opportunity field will support searching by Opportunity ID or Opportunity Title. The opportunity field search results will display the Opportunity ID, Title, Package ID, and Closing date on separate lines to help make it easier to select the desired opportunity. After selecting an opportunity, a button will be available to create a new Proposals (S2S) record. Note that this workflow can only be used to create Grants.gov proposals. Another new update is that additional details from the SP record will be sent to S2S so that they are populated on the S2S proposal automatically. This is a first step in making the connection between SP and Proposals (S2S) more integrated. More information on the details that will be populated in the S2S proposal below. This workflow is useful if the desired S2S proposal has not yet been created, and it will be for a Grants.gov opportunity.
Select a hyperlink to be taken to the Proposals (S2S) application directly. This will be useful if a new S2S proposal needs to be created, but it will not be for a Grants.gov opportunity. Once the S2S proposal is created, the first workflow can be used to link it to the SP proposal.

Updated Proposals (S2S) Creation Workflow

Initial layout of the object with Search box.
Opportunity search results are displayed.
Once an opportunity is selected, Create button is activated.
A box with the current status will be displayed once the proposal is created.

Once an S2S proposal is linked through the first or second workflow, the SP<>S2S object will continue to update to show the link's proposal's information on the integration card like it did before. This integration card will show the S2S proposal title, the PI name (if applicable), and the Status. The permissions related to this integration card, and the SP-S2S object itself, still adhere to the behaviors described in these prior release notes.

Additional details that will be Populated in the S2S proposal:

Submission type: populated with "Application"
Application type: populated with "New"
Due Date: populated with the value from the Sponsor Deadline field (this object must have an ID/Key of "Sponsor-deadline" as outlined in this article)
Project End Date: populated with the value from the Project End Date field (this object must have an ID/Key of "project-end-date" per this article in order for this to be populated properly)
Project Start Date: populated with the value from the Project Start Date field (this object must have an ID/Key of "project-start-date" per this article in order for this to be populated properly)
Proposal Number (this is the Cayuse generated proposal number; we will not include the legacy proposal number in this scope)
Proposal title: populated either with the value from the Proposal title field (this object must have an ID/Key of "proposal-title" for this to be populated properly), or if this field either doesn't exist, or is empty at the time of sending the S2S request, this field will be populated with the SP proposal's project title
Proposal type: populated with "Proposal"
PI Name: populated with the value from the research team object Name field for the member with the role "Principal Investigator"
PI Affiliation: populated with the value from the research team object Internal Association field for the member with the role "Principal Investigator". If multiple internal associations are listed in the research team object, the system will default to populating the association for the person's primary appointment.

If any of the fields listed above are not populated at the time the S2S proposal is created, or do not exist on the SP form, that field will simply not be populated on the S2S proposal by default. Populating the field on the SP record after the S2S proposal has been created will not lead to the value being updated on the S2S proposal.

Limitations: The Opportunity search currently 'ORs' multiple search terms that are separated by a space.

Additional Details: Research team object enhancement

New settings in the form builder

Learn about more the Form Builder.

Within the form builder there are new settings on the research team object to support adding/removing the desired options. These settings include:

Allow External Researchers: If selected, an association radio button selection is displayed for each research team member, allowing either an internal or external member to be listed. If not enabled, this radio button is not displayed and the object only allows internal members to be populated on the research team object. More on this below
Display Credit Field: If selected, each internal team member will have the Credit field displayed. If not selected, the Credit field will be hidden from the research team object.
Display Sponsored Effort: If selected, each internal team member will have the Sponsored Effort fields displayed. If not selected, the Sponsored Effort fields will be hidden from the research team object.
Display Cost Share Effort: If selected, each internal team member will have the Cost Share Effort fields displayed. If not selected, the Cost Share Effort fields will be hidden from the research team object.
Default Effort Format: Can be set to either Percentage or Months. This only defines what format to show by default. Once on a record, the effort format (if any effort fields are displayed) can be toggled between percentage and months (more on this below).

Required Settings

There are three new required settings to go along with the existing general Required setting, including:

Required: This controls whether the object is required or not. None of the other required settings can be selected if this is not selected. If this is the only Required setting selected, then the research team object would require populating the Name, Role, and Internal/External Association field. When this option is not selected, no fields on the research team object will be required.
Credit Field required: This is only displayed on the form builder if the general Required setting is selected and the Display Credit Field setting is selected. When this option is selected, the Credit field will be required for each team member. When this option is not selected, the Credit field will not be required.
Sponsored Effort required: This is only displayed on the form builder if the general Required setting is selected and the Display Sponsored Effort Field setting is selected. When this option is selected, the Sponsored Effort fields will be required for each internal team member (whichever appointment type fields are enabled for the selected internal association). When this option is not selected, the Sponsored Effort fields will not be required.
Cost Share Effort required: This is only displayed on the form builder if the general Required setting is selected and the Display Cost Share Effort Field setting is selected. When this option is selected, the Cost Share Effort fields will be required for each internal team member (whichever appointment type fields are enabled for the selected internal association). When this option is not selected, the Cost Share Effort fields will not be required.

Any existing forms with the research team object will maintain the current state of the object, but the new settings can be updated and published in order to impact future records.

If a research team object is added to a form after the deployment of this release, it will default to not allowing external researchers and default to not displaying credit or any effort fields.

SFB (Simplified Form Builder) Settings

Default settings state when research team object added to a form after this release
Example of all settings available for the research team object

AFB (Advanced Form Builder) Settings

Default settings state when research team object added to a form after this release
Example of all settings available for the research team object

Examples of various configurations on the research team object:

The following are a few examples of how the research team object can look on records with different available configurations.

All fields enabled and required, with mix of internal/external researchers
Effort fields removed, with mix of internal/external researchers
Effort and Credit fields removed, with mix of internal/external researchers
External members not allowed

External Researcher Behaviors:

When configured to allow external researchers, the first field to populate on each research team object member's section is the Association Type. This will be defaulted to Internal. When this option is Internal, the research team objects will behave like they always have. When this option is changed to External, the Name and Role fields will remain, but the Internal Association Field will change to an External Association field, and any Credit or Effort fields that are configured to be displayed will be removed.

For external researchers, the Name field will return any people with external associations instead of those with internal associations. Similarly, the External Association field will list the active External Associations for the selected person in the Name field.

There is no restriction to which role an external research team member can be assigned in the Role field.

New Effort Behaviors

Besides having the ability to display/remove the Sponsored and Cost Share Effort fields, there is also the ability to change the effort format on the research team object. When any effort field is configured to be displayed on the research team object, a View Effort radio button selection will be displayed at the top of the research team object. This object will default to the effort format configured in the form builder settings. If the option is changed, then all effort fields, including the total effort calculated value, will change to displaying in the new format.

As values are entered into the research team object in one format, the other format is calculated and stored in the system, so that upon toggling the effort format, you will be able to see the equivalent value in that new format. One thing to note is that validations are only done on a per field basis, meaning for one effort field in percentage format, values from 0-100 are supported, but there is nothing that prevents exceeding 100% across all enabled effort fields. Similarly, when working in effort months, each enabled field will allow values from 0 to the appointment month value from the Admin module, but nothing prevents exceeding the total appointment month value across all effort fields. This was done intentionally to try to allow some flexibility for institutions that may allow for exceeding 100% effort.

If you prefer to see effort values in the opposite format than what your institution has configured as the default, you will not need to constantly change the View effort radio selection on each record. Once you manually modify the View Effort button on a record, any other records that are loaded within the same user session will continue to default to whichever format was selected. So you should only have to select your preferred format once each time you log in and start a new user session.

Finally, the total effort calculation has been updated to properly support Academic/Summer appointment types. Previously the equation just summed all of the added Academic and Summer effort values, but didn't take into account the appointment months for each.

Reporting/CSVs/Dashboards

The new research team object fields are all available in the in-app reports, downloadable CSV files, and dashboards.

Details

In addition the the columns specified in these past release notes, the following columns have also been added for the research team object:

Research Team Cost Share - Calendar (months)
Research Team Cost Share - Academic (months)
Research Team Cost Share - Summer (months)
Research Team Sponsored Effort - Calendar (months)
Research Team Sponsored Effort - Academic (months)
Research Team Sponsored Effort - Summer (months)
Research Team Total Effort (months)
Research Team External Association
Research Team External Association Primary Code
Research Team External Association Org Type

Existing Columns with updated names

The existing effort columns that contained the percentage values have been updated to include "(%)" at the end of the column name to distinguish them from the effort month columns.

Research Team Cost Share - Calendar (%)
Research Team Cost Share - Academic (%)
Research Team Cost Share - Summer (%)
Research Team Sponsored Effort - Calendar (%)
Research Team Sponsored Effort - Academic (%)
Research Team Sponsored Effort - Summer (%)
Research Team Total Effort (%)

API

The answer format of the research team object will now include the two effort formats, as well as the external researcher attributes in the existing GET API endpoints.
The existing PATCH API endpoints support updating the new research team object effort attributes and external researcher attributes.
The POST API endpoints will be updated soon to allow populating the research team (and other form objects) within the same request
See the following articles for more information about how to retrieve or populate the research team object in the API requests:

Limitations

Existing Record behaviors:

The new effort month fields will not be backfilled for all existing records. These fields will only be populated for existing records if the record is saved after the deployment of this release. This applies to seeing the effort month values in API responses, Dashboards, In-app reports, Downloaded CSV files, etc.

Effort API Limitations

If the request body includes sponsored effort or cost share effort values and they are not displayed on the research object, the API request will be accepted and that value will be stored but not shown on the record. But this value will impact the total effort calculation. This will be updated in a future build to have the API request reject effort values that are not enabled on the research team object.

(Ref ID: 23.02.17)