Items & Relationships

In SPAERC, there is a logical hierarchy of items related to a project as it moves through time from proposal application to awarded project and eventual completion of research and close-out.

You can process these items in SPAERC:

  • Applications (eGC1s)
  • Administrative actions (NAA, PAN, PAC, CO, AA)
  • Funding actions (FA)
  • Cycles (C)
  • Subawards (SC) and their child Subaward Actions (SA)

Note: You may also see Advance Budget Number Requests (ADV) in SPAERC. The research team creates these items in SAGE. They are processed by Grant and Contract Accounting (GCA). You can view, but not modify, an Advance in SPAERC.

When an item of one type is related to another, we refer to them as parent and child. A “parent” item might be a cycle, application, or action and its “child” might be an application or another action.

The Cycle is the top of the hierarchy and so it has no parent. Cycles contain three possible types of children:

  • NAA
  • PAN
  • eGC1

Generally, but not always, the parent item is created first. You can then create child items from within the parent item. For example, you can create a funding action from within an application. If you create the child from within the parent item, it inherits basic project information (PI, sponsor, etc.) from that parent item.

Some parent-child relationships are specifically defined, while others are more general. The following table indicates the typical relationships between items, with current exceptions noted.

Item Type Parent Children
Cycle (none) NAA, PAN, or eGC1
eGC1 Cycle (1) FA, NAA, CO, AA, ADV
PAN Cycle (2) (none)
PAC FA (none)
NAA Cycle, eGC1, or FA (none)
CO eGC1 (3) (none)
AA Cycle, eGC1, or FA (none)
SC (subaward) with child SAs FA (none)
ADV (advance budget number request) eGC1 (none)

Currently, the system also allows

  1. An eGC1 to be the child of another eGC1.
  2. A PAN to be the child of an eGC1 or an FA.
  3. A CO to be the child of a Cycle, eGC1, or an FA.


You can create administrative actions and funding actions as independent items (“orphans”) rather than from a parent item. This enables you, for example, to start a Funding Action while the research team creates and routes the after-the-fact parent eGC1. Once you have access to the parent, you should related the orphan action to it.