Tag Archives: Approvals


Campus research teams and related central offices use the SAGE Suite electronic research administration system to manage application proposals and related items. The suite is comprised of three components that access the shared SAGE Suite database.

  • SAGE: System to Administer Grants Electronically – used by campus researchers and administrators
  • SPAERC: Sponsored Projects Administration & Electronic Research Compliance – used by the Office of Sponsored Programs (OSP)
  • SERA: System for Electronic Research Accounting – used by Grants and Contract Accounting (GCA)
  • FIDS: Financial Interest Disclosure System – used by researchers designated as investigators

The following set of tables gives a high-level overview of who uses each of the different components, and describes the possible actions and the why and/or when.

SAGE: System to Administer Grants Electronically

WHO: Campus research administrators, Principal Investigators, campus reviewers, compliance reviewers

Create SAGE Budgets Centralizes data gathering for salaries, benefits, F&A rates. It can be connected to an application, which automatically populates the eGC1 budget data on the Budget & Fiscal Compliance page. Any changes to the budget will update in real time when the eGC1 Budget & Fiscal Compliance page is viewed.

In addition, if your eGC1 is a Grant Runner application using the RR Detailed Budget form, your budget data will be mapped into the form.

Create applications (standard or Grant Runner) Required for all sponsored research. The standard eGC1 pages of the application are, in effect, an approvals routing cover letter for the proposal. It is used only by the UW and does not go to the sponsor.

A Grant Runner application includes, in addition to the standard eGC1 pages, the sponsor forms for NIH. It is submitted system-to-system by OSP.

Approve routing applications Used by the Principal Investigator, Multiple-PI, Application PI, academic reviewers (division, department, dean) and compliance reviewers (human subjects, animal use, EH&S, etc.) to view and approve the application. At each approval, a PDF snapshot of the application is captured and attached to the eGC1 on the Approvals History & Comments page.

Administrators and reviewers have the option to add other reviewers (as individuals or a group) to the approval flow. These are referred to as “ad hoc” reviewers (approvers or watchers).

Request an advance budget number for awards Used when the research proposal is being awarded by the sponsor, but the actual award has not yet arrived. It requests GCA to set up a budget account in the financial system so the research team can start spending the anticipated award money. When the preparer completes it in SAGE, GCA will be able to view and process it in SERA.

Applications, by default, are not eligible for an advance.  The eGC1 preparer must use the Advanced Budget Eligibility tool to request that OSP mark the application as eligible.

Create subaward requests for awarded applications Used when a research proposal has been awarded and part of the award needs to go to the subrecipients (subcontractors) that the research team will be collaborating with. For a new award, a “new” subaward request (SA) is created along with its parent subaward (SC).  For an ongoing award, a “modification” request would be created within the existing subaward (SC).


SPAERC: Sponsored Projects Administration & Electronic Research Compliance

WHO: Office of Sponsored Programs (OSP)

Review and approve applications OSP reviews the information on the eGC1, such as the sponsor proposal information and compliance questions, after all campus reviewers have approved.  When OSP approves the application, they place it into a new or existing Cycle.
Add Approved applications to a Cycle A Cycle holds a “competing segment” for a research team/project/sponsor combination. It’s a container to keep applications, their related advances, funding actions, admin actions, and subawards together. One cycle can be “related” to another, so that more than one segment is associated.

A Cycle is automatically deleted when the last item in it is removed.

Create various types of Administrative Actions as needed Administrative Actions document various related agreements, adjustments and/or changes, and the finalization of a research project. These actions all appear in the project’s cycle, associated to their appropriate parent item.

Note that all actions (including Funding Actions) start as “unidentified” ones, with a prefix of AA. They are then converted to the specific type needed.

  • Non-Award Agreement (NAA) records a generic agreement not pertaining to funding.
  • Pre-Award Notification (PAN) records a change to the proposed project before the sponsor awards funding.
  • Post-Award Change (PAC) records changes to the project after the sponsor awards the funding.
  • Close Out (CO) records the tracked activities to terminate a project upon completion of the research.
Create Funding Actions (FA) for awards When an application is awarded by the sponsor, OSP creates a Funding Action as a child of the application. Depending on answers to certain compliance questions, there may be automatic “holds” applied.

Once the FA is completed (and all holds are cleared), it is trasmitted to SERA to establish a budget in the financial system (if not already done via Advance Request).

Process subawards OSP reviews the subaward requests, and negotiates the contract with the subrecipient. The request moves through several statuses until, when the agreement is “fully executed” the request becomes Active. It is automatically “Expired” once the End Date is passed.

SCs and FAs can have a many-to-many relationship. The system enforces that all related FAs and SCs must be within the same cycle.

SERA: System for Electronic Research Accounting

WHO: Grant & Contract Accounting (GCA)

Process Advance Budget Number Requests Received from the research team, this allows the team to spend award money before the actual award arrives. GCA adds a budget number to the ADV and sets up that budget in the financial system. As part of completing the ADV, the system sends a notification to the requesters.
Process Funding Actions Received from OSP.  GCA adds a budget number, if needed, and sets up the budget in UW financial system. As part of completing the FA, the system sends a notification to the requesters, and the first-level reviewers for the organization code receiving funding.
Process Post-Award Changes Received from OSP. Not all types of PACs are sent on to GCA. As part of completing the PAC, the system sends a notification to the requesters.
Create “Other” items Created as needed for various budgetary processes. These items only appear in SERA.

FIDS: Financial Interest Disclosure System

WHO: Any research personnel designated as an “Investigator” on the PI, Personnel, & Organizations page of the eGC1.

Create a Financial Interest Disclosure for an eGC1


A disclosure for a CoMotion tech transfer agreement or IRB approval


Complete an Annual Update disclosure

Investigators are required to disclose any significant financial interests (SFI) such as salary, equity, sponsored travel, etc., that might, or might appear to, bias their research.

An investigator must complete a disclosure for each eGC1, whether or not there are SFI that apply, before the proposal can be marked as Ready-to-Submit = Yes.

The disclosures are reviewed by the SFI Reviewer, in the main Office of Research, who determines if there is a potential for a Financial Conflict of Interest (FCOI).  The review occurs at the time of award (just-in-time).

Annual Updates: All investigators are required to review and update their SFI at least once a year. The “year” is calculated from the date of the last disclosure created. Investigators are notified by email 45 days prior, and again at 15 days prior, to the end of that year’s time.

Full details on using FIDS  can be found in its User Guide.

Note: only a UW NetID is needed to access FIDS.

Who gets an approval email notification?
What should I do if the PI is not available to approve the eGC1?

Some sponsors allow a Department chair to sign an eGC1 and proposal on behalf of a PI in his or her department. This requires an Escalation of PI Certification which is indicated on the Certify & Route page of the eGC1.

Be sure to notify the appropriate reviewer to approve the application for him or herself, as well as for the PI.

For information on the approval of applications in the PI’s absence, contact your department administrator/chair.


This component of SAGE (System to Administer Grants Electronically) is an electronic workflow to route eGC1s for approval by associated departments, colleges, compliance offices, and the Office of Sponsored Programs.


SAGE – the System to Administer Grants Electronically – is the web-based system used by faculty, researchers, administrators and staff to:

  • Submit funding applications for consideration
  • Route them electronically for approval
  • Request advance budget numbers
  • Initiate subawards

The core SAGE system allows you to carry out several tasks, including budget development, creating an eGC1, using Grant Runner to complete SF424 R&R forms for NIH opportunities, reviewing and approving applications, and submitting a request for a budget advance.

You can stay up-to-date on changes in SAGE (and FIDS) by subscribing to our Office of Research Information Services (ORIS) News.

SAGE Budget

SAGE Budget helps you create an accurate budget for your grant proposal. It auto-populates data from the payroll and financial systems, helps you select proper rates, and calculate totals automatically.

eGC1 Forms and Grant Runner

eGC1s are the electronic Grants and Contracts forms you use to route your grant proposal through the University’s internal compliance process.

A Grant Runner application combines the eGC1 and sponsor forms for some NIH funding opportunities requiring SF424 R&R forms, including Modular, Detailed and Subaward Budgets. With the click of a button, OSP can electronically submit your application via Grants.gov to the sponsor.


This electronic routing engine stages eGC1s for approval by associated departments, colleges, compliance offices, and the Office of Sponsored Programs.


Use this part of SAGE to complete an online form to request an advance budget number.


Submit a request for a new subaward or a modification of an existing one.


The text version of the page has an Approval Flow Details section instead of the graph. It consists of a table listing the units and individuals who need to approve or watch this application.

The table columns are:

  • Rule Type: The reviewer, and when applicable, their affiliated unit.
  • Approval Status: Waiting Approval, En Route, etc. See the Approval Statuses article for more details.
  • Acted On By: The name of the person who approved or watched the application.
  • Date: The date and time the approval or watched status changed.
  • View Reviewers: Click to display the Reviewer Details for this role, which includes the reasons for this reviewer.

Approval Flow Text Details section

You can modify the Approval Flow at various times in the life-cycle of an application. You can either add additional nodes directly or the system may change the flow due to changes to a withdrawn or returned eGC1.

If you make changes to a withdrawn or returned eCG1, and none of the changes affect the approval flow, then when you re-completed the eGC1, it will continue routing to the next reviewers.  Any campus approvals that already occurred will remain, and any that are “waiting approval” will receive another email notification.

However, if you update the list of research personnel or the organization receiving funding, this may add or remove nodes from the previous approval flow. When you re-complete the eGC1, the system compares the previous flow and the new flow. Any previously approved nodes will keep their approved status and information on the new flow. All reviewers on any new nodes will be notified at the appropriate time. The system will remove any nodes no longer needed.

If the changes to an eGC1 are substantial, it is up to the preparer and/or PI to notify any reviewers who have already approved it. If you decide that additional approval is necessary, you can add an ad hoc. Otherwise you might add a comment, or do nothing.

Regardless of what fields you change on a withdrawn or returned eGC1, the system does not change the assigned OSP person. This ensures that the OSP person who was reviewing the eGC1 will see it on their tasklist once you re-completed it. They can then reassign it as needed.


This is the visual graph of approvers and watchers. The graph begins on the left with the PI and ends on the right with the Office of Sponsored Programs (OSP). Directly under the PI node, is a node for the Preparer/Owners.

If there is an Application PI, that node is immediately to the right of the PI. If there are one or more Multiple PIs, they will follow the PI or the Application PI, if there is one. The Multiple PIs are displayed one below the other. Note that if the Multiple PI is a non-UW person, they will not appear on the approval flow.

The top line of nodes on the graphical version generally are the reviewers associated with the organization receiving funding. The order of other nodes is not fixed.

There is a Legend that defines what the colors of the nodes mean. The heavily outlined node on the graph indicates your location in terms of the overall Approval process.

Approval Flow Graph Legend

  • Watching (color white) indicates that none of the watchers for this  “node” has marked it as Watched
  • Watched (color light gray) indicates that one of the watchers for this node has marked it as Watched
  • En Route (color light purple) indicates that the associated reviewers have not yet been notified
  • Waiting Approval (color medium purple)indicates the associated reviewers have been notified
  • Approved (color light green) indicates an approver has approved the application
  • Returned (color light pink) indicates that a either a campus or OSP approver returned the application to the preparers for changes

Each node lists the person or unit reviewing, the role (for example: Div Reviewer), and the status.

In the example below, the nodes in green have been approved, and they list who the approver was. The outlined node is the one for this approver and shows a status of “Waiting Approval”.  The node for OSP has a status of “En Route”.

  • Click on the name of the node’s unit to view the Reviewer Details page which includes a list of persons authorized to review for this role. This data comes from ASTRA.
  • Click on the “Owner/Preparer” node to display a list of persons who are owners of the eGC1, or have been assigned access to it. Contact the appropriate owner with questions related to the eGC1.Reviewer Details for Preparer/Owners

Approval Flow Graph


Status Data

This initial section explains your relationship to this application.

Approval Flow Status Data

Field Description
Current Status This approval status is based on you or your role and the current routing status of the eGC1.
Your action options Based on your status with this eGC1, this field displays what actions you may take.
Reason for your review This is the reason(s) you or your organization needs to approve this eGC1.

Approval Options

Approvers (other than the PI) can only approve an eGC1 which is in Routing status. If you do not see the Approve or Return buttons, check the eGC1s status on the My Approvals page. The PI can approve an eGC1 in Composing status by completing it, or in Routing status by using the Approve button.

  • Use the Approve button to indicate your approval of this application. You can optionally include a note which will display on the History & Comments page.
  • Use the Return button to return the application for modification; the PI and owners will be notified by email of the return, and the email will include your return comments. Comments are required and will display on the History & Comments page.

Approval Flow Options

Graph Options

Use the Add Comment link to include a note which will display on the History & Comments page.

Use the Add Approver or Add Watcher link to include an additional approver or watcher in the approval flow. See the appropriate section for the steps to do this: Add Approver or Add Watcher.

View eGC1 Options

The View eGC1 link opens the application in a new window, in a read-only mode. This allows you to review the details of the application.

The View Attachments link opens a new window and displays a list of all the attachments for this eGC1.

View Printable eGC1

The PDF link opens a new window that displays a printer-friendly copy of the entire application.


This section lists selected fields from the eGC1 to help you confirm that you are viewing the correct item  (eGC1 Application Details). The data fields include:

  • eGC1 Number
  • Full Application Title
  • PI Name
  • Org Code Receiving Funding
  • Sponsor Deadline
  • OSP Due Date
  • Ready To Submit response

Only the person who has added an ad hoc reviewer node can remove it from the approval flow. However, if the ad-hoc reviewer has already provided approval, the node cannot be removed from the approval graph, as it is part of the approval history.

To start the process, click the Delete link in the graph node, or next to the approver on the text flow page. This opens the Remove Reviewer page in a pop-up window. The pop-up contains two sections: Application Details and Reviewer Details.

The Application Details section lists selected fields from the eGC1 to help you confirm you are viewing the correct item. The data fields include:

  • eGC1Number
  • Full Application Title
  • PI Name
  • Org Code Receiving Funding
  • OSP Due Date
  • Ready To Submit value

The Reviewer Details section lists the Role, Reason, and Status for this reviewer and includes a comments field.

Use the Comments required when deleting an ad hoc reviewer field to enter the reason for removal. Select the Remove button to complete the process or the Cancel link to return to the flow page.

Details about the removal of an ad hoc reviewer will display on the History & Comments page.

remove ad hoc reviewer dialog