One of the activities undertaken by RO administrators, is to request changes in Response Codes ahead of a submission period. There are various reasons why they would want to do this, including if the award holder is on parental leave or long-term sick leave, or if the award holder has left your research organisation.

If your organisation holds very many awards in Researchfish, this can become operationally challenging. 

We have longer-term roadmap plans to better support this process; but below are some notes based on discussions with some funders and RO admins, that might help you with this task in the near term. 

Some preliminary notes, before we start:

1. The process described is not how you make change requests to funders, but it's a way of tracking whether funders have accepted change requests. You will still need to contact funders about change requests as you have in the past.
2. To use this process, you will need to be comfortable using Excel and features such as filters.
3. To use categories, you need to have the RO “Administrator” subscription.
4. For a reminder about Response Codes and their meanings, see Researchfish — What are the Descriptions for the Five Funder Response Codes?

How to identify the awards for which you'd like to request a change in the Response Code

Two approaches are commonly used:

1. Delegate this task to departmental contacts.
2. Email award holders directly, and taking note of any out-of-office replies to identify (for example) who may be on parental leave or long-term sick. 
   1. A potential challenge here is in generating a list of email addresses for award holders. The email addresses included in an awards export are those used by the funders when inviting researchers to accept their awards. While these are typically institutional email addresses, this is not always the case. 
      Therefore, if you want to ensure that emails are sent only to institutional addresses, you will need to verify and identify the appropriate email address for each award holder.

How to track submission compliance, if there are potentially outstanding Response Code change requests.

During the submission period, the RO administrator must track which awards have been submitted and which have not. This task becomes more complex when there are outstanding Response Code change requests, as it requires cross-referencing the submission status with the list of change requests. If the change request data is stored outside of Researchfish, this process can be particularly challenging and time-consuming.

But it's possible to store the change request data in Researchfish, by making use of the categories feature of Researchfish.
Note that for this solution to work, the funder(s) need to be sharing the award details. However, most funders do this.

In the following worked example, I’ve assumed that the RO admin is only making change requests for awards that have a Response Code of 1 (ie, mandatory submission); a similar approach should work in other situations, but with different category data values.
 

Setting up a Category

1. Create a category named “Response Code CR”, to hold the Response Code change request. It will have type “Select One”, with values 2, 3 or 4. 
   1. So an award with a “Response Code CR” category value of 2, is one for which the RO admin has requested that the funder change the Response Code from 1 to 2.
   2. Either by individually editing the award, or by using bulk actions, assign the appropriate “Response Code CR” category value to the relevant awards.

Making use of this category data

Here are some likely questions that an RO admin might have, and how they could answer the questions if they make use of categories as proposed above. Screenshots are from an awards export, with some columns hidden. 

Which award holders do I need to chase up to complete their submission, where the award isn’t pending a funder decision on a Response Code change request? 

Filter an awards export to show awards in submission, with Response Code 1, not submitted, without a “Response Code CR” category value.

  This check is likely to be of most use towards the end of the submission period.

Which of the Response Code change requests are still pending a decision by the funder?

Filter an awards export to show awards in submission, with Response Code 1, with any non-blank “Response Code CR” category value, and optionally not submitted (since if the award has been submitted anyway, then the Response Code CR is now unnecessary).

Note that this filtered view will include awards where the Response Code CR has been rejected by the funder. If the RO admin accepts the funder’s rejection, then they should remove the “Response Code CR” category value from the award to avoid it showing up in this filtered view.

Which of the Response Code change requests have been processed by the funder, but they have set a different Response Code to that requested?

Filter an awards export to show awards in submission, with any non-blank “Response Code CR” category value (which implies the original RC was 1), with a Response Code that isn’t 1 (which implies that the RC has been changed), and add a column to compare the Response Code to the “Response Code CR”. Awards where the comparison value is FALSE, are ones where the funder changed the Response Code to something other than the value requested by the RO admin.

Clearing out Response Code change requests

If you don't want to retain a history of past change requests, you can remove "Response Code CR" values from awards using the bulk updater. 

1. Navigate to e-Val > Awards, search for the awards you wish to remove values from, and select them in the search results. 
2. Click on "Choose Action" at the bottom of the page, and under "Alter a category", select "Response Code CR". 
3. In the resulting dropdown list of values, select "- None -", and then click "Save". 
4. The selected awards will then have their "Response Code CR" values removed.

This could be done at any stage, but is sensible to do sometime after submission period has ended (so that old data is removed ahead of the next submission period).