Tag Archives: Approvals

2

The System to Administer Grants Electronically (SAGE) is the tool that researchers and grant administrators use to prepare proposals for approval and submission to the funding agency. At the UW, the appropriate campus units, compliance offices, and the Office of Sponsored Programs must review and approve all grant and contract proposals.  The Approvals component of SAGE manages the electronic routing of the proposal for approval.

This guide describes the functionality of the Approvals component.

The “approval flow” is a sequential list of all UW individuals, divisions, departments, deans, and/or compliance offices (including OSP), that must review and sign off on a proposal before its submission to the sponsor. Review: How the Flow is Generated.

SAGE automatically routes the proposal to the individuals and units included in the approval flow. The system also sends email notifications of pending approvals to Approvers on campus. OSP uses their SPAERC (Sponsored Projects Administration & Electronic Research Compliance) tasklist to manage proposals waiting for approval. Review: Reviewer Email Notifications.

As a reviewer, you can access the approval flow for an application from the Approvals tab in SAGE. You have the option of viewing a graphical or a textual representation of the approval flow.  If you are a preparer or owner of the eGC1, you can also access the approval flow from its Certify & Route page.

Generally, anyone who appears on the SAGE approval flow is referred to as a reviewer. More specifically, reviewers are either Approvers or Watchers.

Approvers

Watchers

  • Monitor the status of an eGC1; they are not required to approve the eGC1
  • May choose to “mark” the application as Watched
  • May add a comment that then becomes part of the permanent record of the proposal
1

The Approval Status indicates where an eGC1 is in the routing process relative to you or your role. An eGC1 will have different approval statuses for different people or organizations depending on where the eGC1 is in the process.

My Approval Statuses

The approval statuses are:

Status Description
En Route Applications that are waiting for approval by units before you in the approval flow. This status allows reviewers to see eGC1s before they receive the notification to approve. You do not need to wait for your approval notification to approve an eGC1.
Waiting for My Approval All units before your node in the approval flow have approved the application. You, or someone in your shared role, (for example: Dept Reviewer) are now due to approve the application.
Approved You, or someone else in your shared role, has approved the application.
Returned You, or someone else in your shared role, has returned the application to the research team.
Watching You do not need to approve an application in this status. You can review it, and optionally, mark it as Watched.
Watched You, or someone else in your shared role, has marked the application as watched.

Note: When an eGC1 on your list with a status of “Waiting for My Approval” becomes withdrawn or returned, its approval status will change to “En Route.” If you do not have your list filtered to show that status, the application may seem to disappear. You would still be able to see it by either including more statuses, or searching for it from the Advanced Search page.

May 2012 SAGE Maintenance Release

New Features

  • The Security and Export compliance questions have been revised, and a new one has been added concerning access to classified national security information. Answering “Yes” to the new question will generate a new Security Reviewer approver node on the approval graph.
  • The SAGE Budget export now contains data formatted to simplify data entry for the SF424 forms. You will find this information following the usual export data.
  • When adding an ad hoc approver or watcher, a new validation checks for any mismatch between the Role chosen and the level of the associated organization code.
  • When OSP marks an eGC1 as eligible for an Advance Budget Review, the eGC1 owners will automatically receive an email message.
  • When users look up personnel, the results will contain the employee identification number. This will allow users to quickly differentiate between personnel with similar names.
  • You may now delete an eGC1 sooner. You must have read/write access, it has been more than six months since the eGC1 has been completed, and the eGC1 is in Withdrawn or Returned status.

Fixes

  • If you create new budget and complete all of the steps until you reach the access page where you add and remove an admin/budget contact, you will see the full budget navigation instead of the wizard.
  • Hyphenated names now display properly.
  • Advance budget is marked as ineligible when a user copies an older eGC1.
0

To be able to make changes to a routing eGC1, you need to start by withdrawing it from routing. Before you withdraw your eGC1, you may want to contact approvers to let them know that you plan to do so.

You can click the Withdraw button on the Certify & Route page in the Update Application section to make an eGC1 that is routing for approval editable. Once you have made your changes, click the Route to Reviewers button on the Certify & Route page to re-route the eGC1. You must add comments when re-routing an eGC1 that has had at least one approval.

Approvers who have already approved your eGC1 will not be notified again. If you make a major change, you may add them back into the approval graph as ad hoc approvers.

Note: If you marked Yes for Ready to Submit and your eGC1 has reached In OSP status, you cannot withdraw it. Instead, contact OSP and request they return the eGC1.

Any reviewer can use the Return process to make your eGC1 editable also.  The reviewer will enter required comments which are part of the email notification to the eGC1 owners. See Return an Application in the Approvals User Guide.

Both withdrawing and returning make the eGC1 editable by its owners, those with read/write access and those with the Global Editor role.

April 2011 SAGE Budget Versioning and eGC1 Integration

New Budget Features

  • Budget period naming conventions have been enhanced to include the most common period names.
  • Budgets built in SAGE can now be connected to an eGC1, so that any updates made to the budget automatically display on the budget page of the connected eGC1.
  • Budgets in SAGE route with the eGC1 they’re connected to and anybody with access to eGC1 will also have access to the budget.
  • The worksheet in SAGE Budget displays the eGC1 number and status of connected eGC1s.
  • Fiscally responsible departments can now be specified on the setup screen for sub budgets.
  • New Budget Edit Numbers in the Budget History enable users to see when a budget has been revised and to read comments associated with those changes.
  • OSP Administrator/Coordinator now has read access to Budgets built in SAGE.
  • SAGE saves all changes to budget and assigns a unique Budget Edit number and timestamp to versions created at critical points in workflow, such as at submission or approval.
  • Users can access a read-only view of a budget at a specific point in time from the Budget History and copy, print, or export it to Excel.
  • Users can access an Excel version of a connected budget from the eGC1 Attachments page under Connected Budget Data.
  • Users with the appropriate permissions can view or withdraw the eGC1 and budget from the Budget History tab.
  • Ability to define lines that automatically adjust their amounts to make selected total match target amount.
  • Ability to enable/disable fixed fee on APL budget
  • Ability to see sub-budget information for awards where proposal includes an associated SAGE Budget.
  • Added ability to modify Administrative and Pre-Award Budget contacts regardless of eGC1 status
  • Budget title field width reduced to better match maximum characters allowed

Fixes

  • Error when opening Targets and Limits auto-adjusting entries with read-only access.
  • Cascade non-salary line items when a period is added
  • When a user adds TBD personnel to a sub budget, the salary that is created in the setup screen is not transferring to the period set up. The first period starting monthly salary should match the value defined on line setup, instead it is $0.
  • Corrected TBD personnel starting monthly salary on sub budget not copying to periods
  • Changes to how dates are calculated in SAGE Budget may cause a discrepancy between effort months and period length in a select number of budgets. Each of the affected budgets has a salary line item where the number of effort months originally calculated does not match the number of effort months that the current date calculation produces. This means that the effort months in the budget period now exceed the period length.
    • Symptom: When you click through salary details, you will see the following error message when you attempt to tab off the affected period: “Effort Months cannot exceed the number of months in the period (there are currently x months in this period). To increase the effort months, you will need to lengthen the period at the Periods tab.”
  • Changing period dates flips academic/summer months on salary lines
  • Period months incorrect when period start and end dates are in months of different durations (e.g. 28, 30, 31 days)-Current production issue discovered during Budget 2.2 user acceptance testing. When creating a period that has dates that start/end mid-month in months with a different number of days, the period months on salary lines may be calculated as a whole number where a user may otherwise expect them to be. For example: a period starting on 1/16/2011 and ending on 4/15/2011, period months comes out to 3.0161.
  • In a Grant Runner application that has been withdrawn or returned for updates, if an Appendix file is added immediately after updating the Research Strategy file, the Appendix file will appear in the Strategy section.
  • The Advanced Search for Approvals has two issues. First, if both the Date Approved After and Before fields are used to set a date range, the system will not return any results. Using just one date fields works correctly. Second, if a very large number (such as an org code) is mistakenly entered in the eGC1 Number field, an error (99) will occur.