This page also displays any comments previously entered by campus reviewers or OSP when processing the application. Comments are:

• optional when you or another reviewer approve an application*
• optional when a preparer re-completes an application*
• required when you or another reviewer returns an application
• required when you add an ad hoc approver or watcher

*OSP’s business rule is to always give reviewer comments even when the system does not require them.

The system adds a standard comment when the preparer created the current eGC1 by copying another.

Notes:

• Comments entered by OSP when approving only appear on the OSP Notes and Status pages. A standard comment of “Approved by OSP” appears on the History & Comments page.
• All contents of the History & Comments page are visible to the owners of the application as well as OSP.
  • To access the History & Comments page of an application, click History & Comments in the left-hand navigation menu.

The History & Comments page lists completed actions and includes, reading from left to right:

• Name: the person taking the action
• Rule Type: the person’s relationship to the application
• Budget Version: if a budget is connected
• Action Taken: Completed, Withdrawn, Returned, Approved, Watched
• Date: when the action occurred
• Comments: included system-generated and user-entered comments
• For approvers, there are also links to Approved Attachments and an eGC1 Snapshot, to show the state of the application at the time of approval.

Note: If campus adds comments or details to the Additional Information section on the Certify & Route page of the eGC1, the system will add them as a Comment upon initial routing of the eGC1. Any edits to this field will not be tracked with an additional comment unless copied into the comments pop-up window upon routing. OSP can track any edits to this field within the eGC1 Campus Comments section of the Control Sheet, but there will be no alert for any edits made.

The following image shows an example of this page.

For Grant Runner applications, there is also a link to Approved Sponsor Forms.

Upcoming Approvals lists the units or reviewers who have not yet approved (or watched), their approval status, and a link to view the list of authorized reviewers for that unit.

Possible approval statuses are:

• Waiting Approval indicates the eGC1 is ready for this Reviewer to approve.
• En Route indicates a prior Reviewer on the graph (to the left) has yet to approve.
• Watching indicates a reviewer who is not required to approve the eGC1, but who may need to review it.

The post History & Comments appeared first on SPAERC.

When the application is returned by OSP before the ad hoc node is approved, and campus re-completes the application, the graph’s logic changes. When it is redrawn upon re-completion, the ad hoc OSP Approver node is considered to be a campus approver with an approval status of Waiting Approval, and the standard OSP node will have an approval status of En Route. Therefore, the status of the eGC1 is set to Routing rather than back to In OSP as expected. Unless the OSP staff have included eGC1s with a status of Routing in their tasklist view, the application will not appear on their tasklist.

This causes confusion for both the campus user who can verify that the eGC1 has been re-completed and the OSP Administrator who cannot see the eGC1 because of the unexpected status change.

���dzٱ�:��Once the ad hoc OSP Approver node is “approved” the status of the application will change from Routing to In OSP.

Solution: When an eGC1 does not show up on the Tasklist for an Administrator in OSP but Campus asserts to have Re-Completed it, have OSP include “Routing” on their tasklist filtering, or search for the specific application.

The post Status Problem Due to Returning an eGC1 with an Ad Hoc OSP Approver appeared first on SPAERC.

For information about email messages associated with approvals, review Approvals: Reviewer Notifications.

Also review the following sections in the Communications chapter:

• Application Returned Email
• Sponsor Deadline Email

SPAERC automatically generates documents which SPAERC users may customize and send. These documents are covered in Communications: Auto Generated Documents and .

The post Which e-mail alerts are automatically generated and to whom are they sent? appeared first on SPAERC.

Otherwise, the node is added “just-in-time” when the sponsor notifies the PI that the proposal has received a fundable score. The PI or other application owner adds Animal Subjects to the Approval Graph as an ad hoc Watcher. This sends an email notification to the Animal Subjects reviewers and gives them access to the application.

Just-in-time application types are:

• Pre-Application
• New
• Competing Renewal
• Competing Resubmission
• Competing Supplement

For more information, see Approvals: Compliance Reviewers.

The post When is the Office of Animal Welfare added to the approval graph of an eGC1? appeared first on SPAERC.

• The organization receiving funding
• The principal investigator’s primary position unit, and possibly the selected unit in cases where the PI has more than one job
• The primary position and selected 91̽��organization code of any additional research personnel
• Any 91̽��unit with a cost sharing commitment
• The academic units or central offices connected to certain compliance question explanations (See for more details.)
• The additional organization unit reviewers added on the PI, Personnel, & Organizations page

Each unit at the 91̽��determines its own routing rules. For example, one academic unit may require approval from the division, department, and Dean while another unit may require approval only from the Dean.

Note: The eGC1 preparer or any reviewer can add an additional node (called an ad hoc reviewer) for an individual or role (for example, Dean’s Reviewer) to the approval flow once the eGC1 is routing.

The post How the Flow is Generated appeared first on SPAERC.

OSP staff can modify the approval flow by adding an ad hoc reviewer. These manually added reviewers can be for a particular role or a specific person.

Rules for OSP staff adding ad hoc nodes

If you add an ad hoc node, you must add it “before” the “OSP Approver” node. For example, OSP staff who do not have signing authority to submit proposals can add their manager “ad hoc” to let the manager know that they have reviewed the eGC1, and it is ready for manager approval prior to submission.

On the approval flow, there are three Graph Options you can use:

• Add Comment – used to add a comment to the History & Comments page
• Add Approver – used to add an ad hoc approver to the graph; opens the Add Approver dialog
• Add Watcher – used to add an ad hoc watcher to the graph; opens the Add Watcher dialog

The dialog for adding both approvers and watchers has the same options. The following image shows the Add Approver dialog.

First, select whether the node will be for a Role or just one Person, and fill in the related details.

• If you choose Person, a Look Up Person button will display. Click it to search for and select the individual.
• If you choose Role, a drop-down menu will appear from which you can select the desired reviewer role.

If the role you choose is limited by organization code, a Look Up Organizational Code button will appear. Use it to pick the org code at the corresponding level (dept, div, dean).

Next, choose where on the graph the node will appear. This is a two-step process.

1. The “Location on graph… ” drop-down menu lists all of the nodes currently on the graph. Pick the one you want the ad hoc node to be next to.
2. Then choose if the ad hoc node will be before, parallel with, or after the selected node.

Finally, provide a reason for why you are adding this ad hoc reviewer. This is a required field. Click the “Add Approver” button to complete the process.

This is an example portion of the graph for an In OSP status application, before adding the ad hoc node.

The following images show the pop-up screen with options selected.

The next image shows the resulting graph with the new ad hoc Approver added “before” the OSP node, as seen by the person who added it. Note the “Delete” option. The person who adds the ad hoc node is the only one who can delete it.

When other reviewers see the node for the ad hoc reviewer it will indicate who added it.

The post Ad Hoc Nodes appeared first on SPAERC.

If none of the changes affect the approval flow, then the re-completed eGC1 will continue its routing with the next unapproved node. Any prior campus approvals remain and any that are “waiting approval” receive another email notification.

However, if the preparer changes, for example, the list of research personnel or the organization receiving funding, these changes will add or remove nodes from the previous approval flow. When the preparer re-completes the eGC1, the system compares the previous flow and the new flow. Any approved nodes on the previous flow that also appear on the new flow will keep their approved status and information. The system will notify the reviewers for any new nodes at the appropriate time.

If the changes to an eGC1 are substantial, it is up to the preparer and/or PI to notify any reviewers that have already approved it. If an additional approval is necessary, the preparer can add an ad hoc node. Another option is for a reviewer to add a comment to document approval of the changes.

Regardless of what fields a preparer changes on a withdrawn or returned eGC1, the system will not update the SPAERC “assigned to” field. This ensures that the OSP person who was working on the eGC1 will see it reappear on their tasklist once the preparer re-completes it. For more information on how the system assigns eGC1s, see Monitor New Applications.

If the preparer changes the org code, the system will updated the OSP group.

The post Modify the Approval Flow appeared first on SPAERC.

Note: If the PI is the person who completes the eGC1, the system automatically marks the application as approved by the PI.

Once the PI has approved, SAGE automatically notifies the next set of reviewers on the approval flow. The system emails each authorized reviewer for a unit, but only one reviewer needs to approve the eGC1. Once a reviewer approves the eGC1, the status of the node on the approval graph changes to “Approved by” followed by that reviewer’s name. The node also changes color from Waiting Approval (purple) to Approved (green)

In the above example, the Dept. Reviewers for Bioengineering, Biology, and Chemistry and the Reviewer for EHS Select Agents were notified when the PI approved the eGC1. The eGC1 is “Waiting Approval” for each of these reviewers; the eGC1 is “En Route” to the remaining reviewers. When a node on a given “row” changes to approved status, the system notifies the next node and changes its status (and color) from En Route to Waiting Approval. In the example above, when the Bioengineering Dept approves, the system will notify the College of Engineering reviewers.

Any campus reviewer may approve the application prior to receiving their notification. The system does not impose any specific order on the approvals.

Once all of the campus reviewers have approved the eGC1, it moves to In OSP status, and the PI, eGC1 Preparer, and Admin Contact are notified of the status change by an automated email.  You can approve eGC1s out of the order on the approval graph, but this rarely happens. You can view all the email notifications sent to reviewers, and preparers and contacts for a specific application by clicking Email Notifications from the left-navigation menu of an open application. The page lists the reviewers who were notified, the date the notification occurred, and, under Action Taken, the reason.

When a reviewer from a specific unit approves the application, that information is added to the eGC1’s approval history, which you can view from the History & Comments page of the application. You may also view a snapshot of the eGC1 and Approved Attachments as they were when approved.

In very rare cases, OSP may approve an application that is still in Routing status when, for example, one unit does not have any reviewers available within the deadline timeframe. You cannot do this for Grant Runner applications.

The post Reviewer Notifications appeared first on SPAERC.

The following table describes when a Compliance Reviewer is added, which individual or unit is added, and whether the Reviewer is an Approver or a Watcher.

Additional Animal Use Notes

• For an application with AU-1 = Yes, and an application type other than those listed above, the review is done just-in-time, when the sponsor notifies the PI that the proposal has a fundable score. Upon notification, the PI or other application owner adds Animal Subjects to the Approval Graph as an ad hoc watcher. The system then sends an email notification to the Animal Subjects reviewers and gives them access to the application.
• On the Non-Fiscal Compliance page, if a user chooses an existing Hoverboard protocol or enters a new protocol, and the protocol indicates that the Primate Center will be used, then the Department/Center Reviewer for the Primate Center (org code 3010221000) is automatically added to the Approval Graph as an Approver.

The post Compliance Reviewers appeared first on SPAERC.

Additionally, each node is color-coded based on its status. A black outline indicates a reviewer’s node.

• Watching indicates that none of the watchers for this node has marked it as Watched
• Watched indicates that one of the watchers has marked it as Watched
• En Route indicates that the associated reviewers have not yet been notified
• Waiting Approval indicates the associated reviewers have been notified
• Approved indicates an approver has approved the application
• Returned indicates that a either a campus or OSP approver has returned the application to the preparers for changes

The first (left-most) approval node is always for the PI, and the last (right-most) node is always for OSP. The top line on the graphical version is generally for the reviewers associated with the organization receiving funding. There is no fixed order for the other nodes.

Tip: Click on a node in the approval flow to display the reason(s) for the node and the list of authorized reviewers.

The post Interpret the Approval Flow appeared first on SPAERC.