ezfedgrants reference guide animal and plant health ... · pdf fileexternal portal (pega), the...

ezFedGrants Reference Guide

Animal and Plant Health Inspection Service

APHIS ezFedGrants Reference Guide

ezFedGrant APHIS Reference Guide 10/31/2016 1

Table of Contents Introduction ................................................................................................................................................. 2

Definitions .................................................................................................................................................... 3

Key Terms ................................................................................................................................................ 3

Role Descriptions of Internal Users ...................................................................................................... 3

Role Descriptions of External Users ..................................................................................................... 4

ezFedGrants Business Processes ............................................................................................................ 6

Overview and Navigation ....................................................................................................................... 6

ezFedGrants External Portal (Pega) .................................................................................................. 6

User Access Approval ........................................................................................................................ 7

User Profile ........................................................................................................................................ 10

Program Management .......................................................................................................................... 14

Opportunity Management ..................................................................................................................... 17

Application Management ...................................................................................................................... 21

Panel Management & Application Review Process ........................................................................... 26

Agreement Management ...................................................................................................................... 33

Claims Management ............................................................................................................................. 41

Amendment Management .................................................................................................................... 45

Report Approval .................................................................................................................................... 54

Closeout Management .......................................................................................................................... 57

FFATA Reporting .................................................................................................................................. 61

Supplementary Information ..................................................................................................................... 62

Sensitivity Review ................................................................................................................................. 62

Common System Errors ........................................................................................................................... 63

Additional Resources (in Progress) ........................................................................................................ 63

Open Questions ........................................................................................................................................ 63

https://afs365.sharepoint.com/sites/USDA%20FMMI/Lincoln/Candidate%20Systems/Enterprise%20Grants%20Training/Phase%20one%20Materials/Final%20Deliverables/1.%20Final%20Submitted%20to%20Client/APHIS%20Reference%20Guide_Final%20v1_09_14_2016.docx#_Toc461623457









The ezFedGrants system is a Grants Management system that modernizes and improves the efficiency and consistency of internal business processes. ezFedGrants increases agency compliance with Federal grant requirements and integrates with USDA’s Enterprise Financials implementation. The system’s central configuration and build introduces efficiencies through design, test, training, deployment, and O&M. ezFedGrants supports customer focused agile development with the ability to pilot simple processes with minimal development. The system’s standardization of business processes means functionality is “built once” and is available to all enterprise agencies. Overall, the base enterprise solution reduces code-driven agency customizations and allows for easy identification and containment of regression testing issues. This reference guide will detail the grants lifecycle for the Animal and Plant Health Inspection Service (APHIS) while describing agency specific differences. This guide serves as a reference for internal users and will be supplemented by relevant job aids. It will give an explanation and overview of each screen, status explanations, and the workflow descriptions for every process, all of which are necessary for users to accomplish tasks in a timely manner.

Introduction



This section provides key terms and role definitions which will be helpful when navigating this Reference Guide and using ezFedGrants.

Key Terms

External user: The individual in the recipient organization; can also be a Reviewer in a panel

ezFedGrants: The universal USDA enterprise grants management portal rolled out in 2016 that allows both internal and external users to manage their award portfolios online.

ezFedGrants External Portal (Pega): The external system for ezFedGrants that is accessible to both external users, for applications to be sent through, and to internal users, so they can continue throughout the portion of the grants lifecycle that extends from opportunity creation to application review. The system is used for creating and approving opportunities and applications, as well as for managing post-award processes such as reports and claims. For reference, Pega is the underlying technology for the External Portal.

ezFedGrants Internal Portal (SAP CRM): The internal system for ezFedGrants that is only accessible to internal users to create and approve items so they can continue throughout the grants lifecycle. Mostly used for creating and approving agreements, amendments, claims, closeouts, and programs. For reference, SAP CRM (Customer Relationship Management) is the underlying technology for the Internal Portal.

FMMI ECC: FMMI’s financial system which houses USDA and agency financials and budget information. Also called SAP ECC (Enterprise Central Component) in this document.

Internal user: The individual(s) from the USDA agency who begin the grants lifecycle by creating the opportunity and continue to complete work items throughout the grants lifecycle.

Workflow: A procedure, usually involving approvals, which is needed to finalize a business process.

Role Descriptions of Internal Users

Agency Grants Management Officer (AGMO): The Agency Grants Management Officer (AGMO) is an agency role that has access to the ezFedGrants External Portal (Pega) and the ezFedGrants Internal Portal (CRM). In the ezFedGrants External Portal (Pega), the AGMO is able to create and publish opportunities, as well as receive actionable items in the application approval workflow. The AGMO is the only user with the ability to approve external user access requests. In the Internal Portal (CRM), the AGMO is able to create programs, agreements, amendments, claims, and contacts. Additionally, the AGMO has the ability to generate award documents and initiate closeouts. The AGMO is able to update non-ECC Business Partner Recipient fields and activities, but has display-only access to ECC Business Partner Recipient fields.

FFA Transparency Reporter (FFATA Extract Processor): The FFATA Extract Processor has the ability to execute the FFATA reporting functionality. This user is able to generate the FFATA report. This role is assigned as an ‘add-on’ role which is independent of the user’s ‘core’ business role.

Financial Approver (FA): The Financial Approver (FA) is an agency role that has access to the ezFedGrants External Portal (Pega) and the ezFedGrants Internal Portal (CRM). In the ezFedGrants External Portal (Pega), the FA is mapped to the Grantor Evaluator role and has display-only access. In the Internal Portal (CRM), the FA has display-only access to all objects; s/he has a role in the agreement, amendment, and closeout approval workflows.

Funds Pre-Commitment Processor: The Funds Pre-Commitment Processor has the ability to create and update Funds Pre-Commitments in FMMI ECC. This role is assigned as an ‘add-on’ role, which is independent of the user’s ‘core’ business role.

Grantor Evaluator: The Grantor Evaluator is an agency role that has display-only access to all objects. This user may not create or update any object, and does not participate in any workflow.

Definitions



Grants Specialist (GS): The Grants Specialist (GS) is an agency role that has access to the ezFedGrants External Portal (Pega) and the ezFedGrants Internal Portal (CRM). In the ezFedGrants External Portal (Pega), the GS is able to create and publish opportunities, as well as receive actionable items in the application approval workflow. In the Internal Portal (CRM), the GS is able to create agreements, amendments, claims, and contacts. Additionally, the Grants Specialist has the ability to generate award documents and initiate closeouts. The GS is able to update non-ECC (SAP CRM) Business Partner Recipient fields and activities, but has display-only access to the program object and ECC Business Partner Recipient fields.

Program Manager (PM): The Program Manager (PM) is an agency role that has access to the ezFedGrants External Portal (Pega) and the ezFedGrants Internal Portal (CRM). In the ezFedGrants External Portal (Pega), the PM has display-only access for all objects and plays a role in the application, activity, claim, and reporting approval workflows. In the Internal Portal (CRM), the PM has display-only access for all objects with the exception of activities: the PM is able to update activities. Additionally, the Program Manager plays a role in the agreement, amendment, and claim workflows.

Program Reviewer (PR): The Program Reviewer (PR) is an agency role that has access to the ezFedGrants External Portal (Pega) and the ezFedGrants Internal Portal (CRM). In the ezFedGrants External Portal (Pega), the PR is mapped to the Grantor Evaluator role and has display-only access. In the Internal Portal (CRM), the PR has display-only access to view agreements and amendments; s/he has a role in certain scenarios of the agreement and amendment approval workflows.

National Program Manager (NPM): The National Program Manager (NPM) is an agency role that has access to the ezFedGrants External Portal (Pega) and the ezFedGrants Internal Portal (CRM). In the ezFedGrants External Portal (Pega), the NPM has display-only access for all objects and plays a role in the application approval workflow for certain scenarios. In the Internal Portal (CRM), the NPM has display-only access to all objects, with the exception of the program object.

Sensitivity Reviewer (SR): The Sensitivity Reviewer (SR) is an agency role that has access to the ezFedGrants External Portal (Pega) and the ezFedGrants Internal Portal (CRM). In the ezFedGrants External Portal (Pega), the SR is mapped to the Grantor Evaluator role and has display-only access. In the Internal Portal (CRM), the SR has display-only access to view agreements and amendments; s/he has a role in certain scenarios of the agreement and amendment approval workflows.

Signatory Official (SO): The Signatory Official (SO) is an agency role that has access to the ezFedGrants External Portal (Pega) and the ezFedGrants Internal Portal (CRM). In the ezFedGrants External Portal (Pega), the SO is mapped to the Grantor Evaluator role and has display-only access. In the Internal Portal (CRM), the SO has display-only access to all objects with the exception of the program object; s/he has a role in the agreement, amendment, and closeout approval workflows.

Role Descriptions of External Users

Access Requester: The Access Requester is an external user who does not have access to the External Portal (Pega). They are requesting access to be able to utilize the Portal. S/he has the ability to request access and to log a Pega Help ticket.

Grant Administrative Officer (GAO): The Grant Administrative Officer (GAO) is an external user with limited permissions to objects in the External Portal (Pega) and no access to the Internal Portal (SAP CRM). S/he has read-only capabilities for opportunities, agreements, amendments, award documents, as well as to update permissions for claims, financial and performance reports. The GAO can create applications and update and sign financial and performance reports. The GAO is the only external user role with the ability to approve external user access requests and may maintain/manage access for users within their organization.

Grant Processor: The Grant Processor is an external user with limited permissions to objects in the External Portal (Pega) and no access to Internal Portal (SAP CRM). S/he has read-only capabilities for opportunities, agreements, amendments, award documents, as well as the ability to update and sign financial and performance reports. The Grant Processor can create, update, and modify applications.



Recipient Signatory Official: The Recipient Signatory Official is an external user with limited permissions to objects in the External Portal (Pega) and no access to Internal Portal (SAP CRM). S/he has read-only capabilities for opportunities, agreements, amendments, as well as attachment permissions for award documents and financial and performance reports. In addition, s/he will have access to objects when a signature is required. The Recipient Signatory Official’s signature is required on applications, agreements, and amendments. S/he can serve as the Certifying Official for claims and reports (financial and performance).



Overview and Navigation

There are two major portals in ezFedGrants: the External Portal (Pega) and the Internal Portal (SAP CRM). Below is an overview of each portal, as well as its relevant screens and workflows.

ezFedGrants External Portal (Pega) The External Portal is the location where external users start the grants process, but is also accessible to internal users. The internal user is able to access pending work items that require action for the grants process to proceed to the next phase. Main Menu Screen

The Main Menu Screen is triggered when a user accesses the External Portal (Pega). The user is able to navigate to different screens and ezFedGrants objects using the links provided within these sections. Upon selecting a work center in the navigation bar, the user is directed to the respective screen(s). The following sections are present on the Main Menu Screen in the ezFedGrants External Portal (Pega). Permissions in each section will depend on user role.

Navigation Bar: o Home: This section will take the user to the Home Screen. o Worklist: This section will take the user to his/her workflow tasks. From here, s/he will be able to

view pending work items. o Applications: This section will give an internal user the ability to view applications. Upon clicking

the tab, the user will be taken to the Application Search Screen. o Opportunities: For internal users, this section will have a submenu that provides the user with

two options: Create Opportunity and Search Opportunities. When the user clicks on Create Opportunity, s/he is taken to the Create Opportunity Screen. When the user clicks on Search Opportunities, s/he is taken to the Search Opportunity Screen.

o Agreements: This section will give a user the ability to view the Agreement Details Screen. Upon clicking the tab, the user is taken to the Agreement Search Screen.

o Claims: This section will give a user the ability to view claims. Upon clicking the tab, the user is taken to the Claim Search Screen.

o Reports: This section will give a user the ability to view reports. Upon clicking the tab, the user is taken to the Report Search Screen.

o Panels: For internal users, this section will have a submenu that provides the user with options to search for reviewers, panels, and panel summaries; and create and manage panels.

Home Screen: This section contains tiles that provide high level information about pending activities for the associated user. Users have the ability to open an item within a tile, which brings them to the respective transaction (e.g. application or opportunity). Below are the tiles for the internal user: o Pending Opportunities o Pending Applications o Pending Amendments o Pending Claims o Pending Reports o Action Items (approval requests)

News and Notes: This section displays important information to users. The information will be maintained by the AGMO, who will have the ability to create, edit, and publish News and Notes for the following groups: internal users only, external users only, or both internal and external users.

ezFedGrants Business Processes



Workflow

The user logs into the ezFedGrants External Portal (Pega) to display the Main Menu Screen. From there, the user has the ability to click any of the links to display the corresponding screen. For Reviewers, the user must click the User Name button, the Switch Roles link, and finally the Reviewers link to display their respective homepage. The Reviewer’s homepage includes a Notifications tile, an Actionable Items tile, a Pending Consensus Review tile, and a link to open the Manage Panels page. Figure 1 illustrates the standard Main Menu Workflow for the External Portal (Pega) (the silver box indicates a step done in the FMMI Portal before logging into the External Portal (Pega); the white boxes are steps in the External Portal):

Figure 1: ezFedGrants External Portal (Pega) Main Menu Screen initiation process

To learn more about navigating in the External Portal (Pega), refer to the following Job Aid:

Overview & Navigation – Pega Job Aid

User Access Approval External users must request access before they are able to use ezFedGrants, and their request must be approved by previously designated users (outlined below). The approval will allow external users to



navigate throughout the system and give them the ability to apply for opportunities in order to receive financial awards. External users will also be able to submit their recipient reporting for agency review as well as any other actionable items required. Approving an Access Request

Request Access Screen

The agency has the ability to either accept or reject the access request in the decision dropdown field. The following section is present on the Request Access Screen:

Decision: The dropdown field asks for the user to select an option – Accept or Reject – to either approve or deny an external user system access.

Workflow

When entering the Access Request Screen through the ezFedGrants External Portal (Pega), requesting users (also known as Access Requesters) must select the role that they would like to be provisioned. A user may request access for one of the following roles: Grant Processor, Signatory Official, Grants Administrative Officer, or Reviewer.

Grants Administrative Officer (GAO) role (if no GAO exists within organization): Access requests for the GAO role within an organization that does not have one will be routed to the AGMOs of the selected agency for approval. The selected agency’s AGMOs will receive an actionable item in their worklist. From the actionable item, the AGMO will be able to access the submitted request and execute a decision. Once one GAO is approved by the agency for an organization, all subsequent access requests for that organization will go to all current GAOs of the selected organization.

Grant Processor or Signatory Official role (if a GAO already exists within the organization): Access requests for these role requests will be routed to all GAOs of the selected organization, who will receive an actionable item in the ezFedGrants External Portal (Pega). From the actionable item, the GAOs will be able to access the submitted request and execute a decision.

Reviewer role: Access requests for a Reviewer role will be routed to the AGMOs of the selected agency for approval. The selected agency’s AGMOs will receive an actionable item in their worklist. From the actionable item, the AGMO will be able to access the submitted request and execute a decision.



Figure 2 illustrates the standard access request approval workflow:

Figure 2: Access request approval workflow diagram

Status Definitions

The following are common status definitions for the aforementioned workflow:

Draft: This status indicates that the access request has not yet been submitted. The status will be defaulted to Draft when a new access request is initiated by a user; the user will not have the ability to save the request in Draft status, but only submit the request for approval. From Draft, the status can only become Submitted or Submitted to Agency.

Submitted: This status indicates that a user access request for a Grant Processor, Signatory Official, or GAO role has been successfully submitted to that organization’s GAOs. From Submitted, the status can become Approved or Rejected.

Submitted to Agency: This status indicates that a user access request for an organization that has no users with a GAO role, or a reviewer request has been successfully submitted to the specified agency’s AGMOs. From Submitted to Agency, the status can become Approved or Rejected.

Approved: This status indicates that a GAO or AGMO, depending on the user requesting access, decided to approve the access request. This will grant the requesting user access to the ezFedGrants External Portal (Pega) and give all permissions relevant to the role s/he requested. An access request cannot change to any other status from Approved.



Rejected: This status indicates that a GAO or AGMO, depending on the user requesting access, decided to reject the access request. The requesting user is denied access to the ezFedGrants External Portal (Pega). An access request cannot change to any other status from Rejected.

To learn more about the access request approval process, refer to the Job Aid here:

Access Request Approval Job Aid

User Profile The User Profile Screen enables a user to identify themselves as a Reviewer. The agency can search for Reviewers based on background, skills, and expertise of an individual; however, all users must have the necessary Level 2 eAuthentication and have a role assigned to them before they are able to do this. User Profile Screen

The Profile Screen is available to anyone who logs into the ezFedGrants External Portal (Pega), specifically any internal agency user, external user, or Reviewer user. Internal users also have the ability to search for the content within the Reviewer Profile Screen when searching for Reviewers. For reference, a Reviewer is an individual who reviews an application during the Application Review Process – this role can be an internal user, external user, or neither. In order to access this user role, an Internal User must switch roles in the ezFedGrants External Portal (Pega) to the Reviewer Role. The reviewer will be involved in reviewing the application in the Conflict of Interest, Individual Review, and Consensus Review stages. The following sections are present on the User Profile Screen:

General Data

Contact Info

Organization Details

Expertise Reviewer Profile Screen

The Reviewer Profile Screen is only available to users who self-identify themselves as a Reviewer by selecting the “I want to be considered as a Reviewer for future panels” checkbox. Once checked, additional fields will appear and the agency will be able to search and add the individual to panels. The following sections are present on the Reviewer Profile Screen:

Highest Education: This is a dropdown that captures the highest degree an individual has achieved: BA, BS, MA, MD, MS, PhD, Other. Only one option can be selected.

Degree Area: This free text field captures a user’s subject area expertise, major, or concentration.

Profession Title/Rank: This is a dropdown that captures an individual’s professional title or rank.

Organization Type: This field provides a dropdown to indicate an Organization Type.

Institution Type: This field provides a dropdown to indicate an Institution Type.

Department/ Unit: This is a free text field which can capture an individual’s department/ unit.

Percent of Appointment: This is an input field giving individuals affiliated with academia the ability to enter percentages reflecting the percentage of their appointments to the following tasks: Research, Teaching, Extension/Outreach, and Administration. A warning message will be displayed if the total of the Percent of Appointment does not equal 100%.

Gender: This field provides a dropdown to indicate an individual’s gender.

Race: This field provides checkboxes to indicate an individual’s race.

Ethnicity: This field provides a dropdown to indicate an individual’s ethnicity.



What other Federal Agencies or Organizations have you served as a reviewer for?: This is a free text field which can capture a reviewer’s past affiliations with other federal agencies.

Conflict(s) of Interest (COI): This is a free text field to indicate any potential conflicts of interest. A button will allow multiple lines to be added, so only a single COI should be entered per line.

Workflow

The user selects Profile from the dropdown field to display the respective user’s profile. The user would then select the Identify yourself as a Reviewer checkbox to display reviewer-relevant fields. The user proceeds to select Update Your Info for the fields on the Screen to become editable. The user then enters all the required information and saves the updates and changes. Figure 3 illustrates the standard user profile workflow for a Reviewer:

Figure 3: User Profile actions for Reviewers

Additionally, in the ezFedGrants External Portal (Pega), agency users are able to search for reviewers using the Reviewer Search Screen. By inputting data in the available search criteria (such as reviewer name, USDA region, organization, federal agency/organization previously reviewed for, etc.), the user will be able to view all relevant search results.



Reviewers that identify themselves as an “Active Reviewer” on the User Profile Screen will be present in the search results, while those that leave the checkbox unselected will not be present in the search results. Users access the Reviewer Search Screen by clicking on Panels in the navigation bar on the Main Menu, and then clicking Search Reviewers in the resulting options. To learn more about user profiles for Reviewers, refer to the following Job Aid:

User Profile Job Aid ezFedGrants Internal Portal (SAP CRM) The Internal Portal, housed on SAP CRM technology, allows for internal users to navigate throughout the system and be able to complete any work items that will enable the grants process to continue onto the next phase. Main Menu Screen

The Main Menu Screen is triggered when a user accesses the ezFedGrants Internal Portal (SAP CRM). The user is able to navigate to different screens and ezFedGrants objects using the links provided within these sections. Upon selecting a work center in the navigation bar, the user is redirected to the respective screen. The following sections are present on the Main Menu Screen in the Internal Portal (SAP CRM). Some sections or links may not be available to all users, depending on their role:

Navigation Bar: This tabular section provides quickly accessible links on the left hand side of the page to the work center (listed below) and is present on every screen.

Home Work Center: This section allows the user to create agreements, amendments, claims, closeouts, and contacts. In addition, users can search for agreements, activities, amendments, claims, recipients, closeouts, and contacts.

Worklist Work Center: This section displays work items assigned to the user for review and action.

Program Work Center: This section allows the user to create and search for programs.

Agreements Work Center: This section allows the user to create and search for agreements.

Amendments Work Center: This section allows the user to create and search for amendments.

Activities Work Center: This section allows the user to search for activities.

Claims Work Center: This section allows the user to create and search for claims.

Closeout Work Center: This section allows the user to create and search for closeouts.

Recipients & Contacts Work Center: This section allows the user to create and search for contacts and search for recipients.

Workflow The user logs into ezFedGrants via the FMMI Portal to display the Home Screen. From there, the user has the ability to click any of the available links, which will then display the corresponding screen.



Figure 4 illustrates the standard Main Menu Workflow for the Internal Portal (SAP CRM):

Figure 4: ezFedGrants Internal Portal (SAP CRM) Main Menu actions

To learn more about navigating in the Internal Portal (SAP CRM), refer to the Job Aid here:

Overview & Navigation – SAP CRM Job Aid



Program Management Programs are necessary to drive configuration and processing, to set the terms and validity dates for a program, to manage the organization, and to set up the necessary workflows. A program must be created and set up before processing all other transactions (e.g. agreements, amendments). Creating a Program

Program Screen

The user is able to create a program by selecting Create Program from the Internal Portal (SAP CRM) Home Screen and is then responsible for filling out the required fields. The user is able to navigate to different screens and ezFedGrants objects using the links provided within these sections. Upon selecting a work center in the navigation bar, the user is redirected to the respective screen(s). The following sections are present on the Program Screen:

Program Details: Includes all the general information concerning the program.

Process Control: Allows the users to set specific dates when transactions can be created.

Process Assignments: Captures the transaction type relating to a given object (i.e. an agreement) within the program.

Expense Types: Captures the cost elements that will be allowable for the program.

Custom Attributes: Associates specific configuration to each object for a program and allows the user to define the PDF form, attachment group, workflow group, and partner group relative to object and instrument type.

Partners: Captures the employees assigned to a program, allowing them to transact within it.

Notes: Captures any notes regarding the program that the user would like to include.

Change History: Captures all the changes/edits made to a program after its initial creation. This details what changes were made and by whom.

More information on required fields and partners is below: Fields: In the Process Assignments section, the agreement (ES Grant Agreement), change request (ES Change Request), claim (ES Claim), and change request (ES Grantor Closeout) must be listed as transactions. The following expense types should be listed in the Expense Types section:

Personnel

Travel

Supplies

Construction

Fringe Benefits

Equipment

Contractual

Other The Custom Attributes section must contain information on the ES Grant Agreement Transaction Type (Cooperative Agreement, Compliance Agreement, Indemnity, Umbrella Agreement, Grant Instrument Types), as well as the ES Claim, ES Grantor Closeout and ES Change Request Transaction Types. The relevant forms and groups identified in the Custom Attributes section must parallel the object identified in the transaction type (e.g. for the ES Grant Agreement Transaction type, the PDF Form would be APHIS



Agreement form and the Workflow Group, Attachment Group, Partner Group, and Note Group would all align to the APHIS Agreement). Partners: Below is a table indicating the required program partners and how many should be populated. Please note that the Agency National Program Manager is not systematically required, but should be populated on the programs that require this role to review applications in the ezFedGrants External Portal (Pega), namely PPQ Field Ops and WS-WRC.

Partner Function Required

Agency Grants Specialist 1

Agency Financial Approver 2

Agency Program Manager 2

Agency Signatory Official 2

Agency Program Reviewer 1

Agency Sensitivity Reviewer 1

AGMO 1

Agency National Program Manager** 0

Editing a Program

Upon inputting all required information on the Program Screen, a user will be able to save the program. Once the user has navigated to the Program Screen, s/he will be able to click the Edit button in each assignment block to edit the information contained in the corresponding fields. A user can then save any changes made. Additionally, programs can be edited in Released status, but not Locked status. Program Workflow

There are two options in the New Status dropdown field on the Program Screen – Released and Locked. Selecting Released allows the user to create and edit the relevant transactional screens associated with the given program. Selecting Locked allows the user to edit the relevant transactional screens associated with the given program; however, the user will be unable to create new transactions.



Figure 5 illustrates the standard program creation workflow:

Figure 5: Program creation business flow diagram

Status Definitions


Released: This allows the user to create and edit the transactional screens associated with the given program.

Locked: This does not allow the user to create new transactions associated with the given program, but the user can edit or update existing ones.

To learn more about creating a program, refer to the Job Aid here:

Program Management Job Aid



Opportunity Management This process facilitates opportunity creation for internal users, which allows external users to submit applications. It is also necessary to enable the actions of initiating and completing tasks during the opportunity approval process, which streamlines the approval process by electronic approval. Creating an Opportunity

Opportunity Screen

Grants Specialists and AGMOs are able to create an opportunity by clicking the Create Opportunity button, which will display the Opportunity Screen. The user is then responsible for filling out the required fields and uploading attachments. To save the changes and updates to the opportunity, the user clicks the Save button. Once all the required information is entered, the user submits the opportunity. The following sections are present on the Opportunity Screen:

Summary Information of Funding Opportunity Announcement o Basic Opportunity Setup o Justification for Non-Competition

Full Text of Announcement o Funding Opportunity Announcement (FOA) o Funding Opportunity Description (FOD) o Federal Award Information o Eligibility Information o Application and Submission Information o Application Review Information o Federal Award Administration Information o Federal Award Agency Contacts (FAA Contacts) o Other Information o Opportunity Distribution List

Grants.gov Opportunity Properties o Grants.gov Synopsis o Grants.gov Application Package

Attachments o List of Attached Files

Criteria o Reviewer Instructions o Criteria (the user can add as many criteria as they like)

In addition to the above fields, the following field is required to publish an opportunity: Federal Awarding Agency Contacts:

If there is no Agency National Program Manager listed on the program in the ezFedGrants Internal Portal, then the following partners are required in the FAA Contacts section: o Type: Administrative (populate with an Agency Grants Specialist) o Type: Programmatic (populate with an Agency Program Manager)

If there is an Agency National Program Manager listed on the program in CRM, then the following partners are required in the FAA Contacts section: o Type: Administrative (populate with an Agency Grants Specialist) o Type: Programmatic (populate with an Agency Program Manager) o Type: Other (populate with an Agency National Program Manager)

There are no required attachments to publish an opportunity.



Editing an Opportunity

When the status of the opportunity is in Draft, the user can edit numerous times. This status has no impact on the opportunity approval process. If the opportunity is in Pending Modification status, detailed below, the user has the option to select the Edit option from the approval workflow decision dropdown for a Published or Closed opportunity. Opportunity Approval Workflow

The opportunity approval workflow takes place after the Grants Specialist or AGMO chooses to create or edit an opportunity. The workflow begins when the user clicks the Publish button, which will publish the document. The Grants Specialist and AGMO will be able to then edit or cancel the opportunity, which will send an email to the following users:

Programmatic FAA Contact from the opportunity

Administrative FAA Contact from the opportunity

All users that created applications against the opportunity

All users listed in the Distribution List on the opportunity

The opportunity approval workflow features no work items, and all actions are done directly through the Opportunity Screen. It is important to note that opportunities saved in Draft or Pending Modification status will appear in the work tile for users to continue working on the opportunity.

Only the Grant Specialist and AGMO will be able to modify opportunities. Modifications occur by selecting edit from the approval workflow decision dropdown, at which point, the opportunity enters Pending Modification status. Users are able to make modifications to opportunities in Pending Modification status, enter a modification reason, and click the Publish button to re-publish the opportunity.



Figure 6 illustrates the opportunity approval workflow:

Figure 6: Opportunity approval workflow diagram



Status Definitions


Draft: This status indicates that the opportunity is in draft mode. The status of the opportunity will be defaulted to Draft when a new opportunity is initiated in the External Portal. The user can save the document in this status; while the opportunity is in Draft status, the user has the ability to edit the opportunity numerous times. This status has no impact on the opportunity approval process. From Draft, the status can only be changed to Published or Cancelled.

Published: This will make the opportunity available for application submission. From Published, the status can only be changed to Closed, Pending Modification, or Cancelled status.

Pending Modification: This status indicates that a user has selected the Edit option from the approval workflow decision dropdown for a Published or Closed status opportunity. From Pending Modification, the opportunity can enter Published or Cancelled status.

Cancelled: This status indicates that a user has clicked the Cancel opportunity button present on an opportunity in a Draft or Pending Modification status, or selected the cancel option displayed when an opportunity is in a Published. The opportunity cannot change to any other status from Cancelled.

Closed: This status indicates that the opportunity has systematically been updated to Closed status when the Application Availability End Date is reached. In this status, external users cannot create or submit applications against the opportunity. From Closed status, the opportunity status can only change to Pending Modification.

To learn more about creating and approving an opportunity, refer to the Job Aids here:

Opportunity Create Job Aid

Opportunity Approve Job Aid



Application Management This process provides external users the opportunity to directly apply for grant opportunities offered by an agency and integrate the application approval process for the internal users. Once it is received and approved by agency users, the application becomes a Draft agreement in the Internal Portal (SAP CRM). Creating an Application

Application Screen

The external user submits an application against an opportunity and awaits agency approval to move onto the next phase of the grants lifecycle. The following sections are present on the Application Screen:

SF-424: This section outlines the government-wide standard application for Federal Assistance form.

SF-424A: This section contains the budget details required to be submitted with the application.

Partners: This section provides the user with the ability to assign the necessary authorized organization users to each point of contact type required for an application.

Additional Details: This section outlines the additional agency-specific information for submission.

Attachments: This section provides the user with the ability to upload the required application documentation and any additional documents, where applicable. This section also contains attachments received from applications submitted through Grants.gov.

Editing an Application

Please note that internal users are not able to edit applications; only appropriate external users can. Application Approval Workflow

The Application Workflow begins when the Grant Processor or GAO submits a draft application for review after entering all the necessary application information and attaching the following documents:

Work Plan

Financial Plan

SF-424B, Assurances – Non-Construction Programs

Conditionally Mandatory: o SPOC Letter: If “SPOC Review” is marked as “Yes” in the Additional Details section o SF-LLL, Disclosure of Lobbying Activities: If award is > $100K o Certification Regarding Lobbying: If award is > $100K

Below is an overview of the workflow “happy path” (no returns or cancellations) for an application that does not require NPM approval. This table documents the user and the status change to move the application to the next step in the workflow:

Partner Function Status Changes (From – To)

Grant Processor or GAO Draft to Pending Signature

Recipient Signatory Official Pending Signature to Submitted

Agency Program Manager Submitted to Considered

Agency Program Manager Considered to Grant Review

Agency Grants Specialist Grant Review to Accepted/Recommended

Agency Program Manager Accepted/Recommended to Approved



Below is an overview of the workflow “happy path” for an application that does require NPM approval. This table documents the user and the status change to move the application to the next step in the workflow:


Grant Processor or GAO Draft to Pending Signature

Recipient Signatory Official Pending Signature to Submitted

Agency Program Manager Submitted to Considered

Agency Program Manager Considered to Grant Review

Agency Grants Specialist Grant Review to National Approval

Agency National Program Manager National Approval to Accepted/Recommended

Agency Program Manager Accepted/Recommended to Approved



Figure 7 and Figure 8 illustrate the application approval workflow:

Figure 7: Application approval workflow diagram, part 1



Figure 8: Application approval workflow diagram, part 2

Status Definitions

The following are common status definitions for the application workflow:

Pending Signature: This status indicates that the application is awaiting the signature of the Recipient SO. This status can change to Returned by Signatory Official, Withdrawn, or Submitted.

Returned by Signatory Official: This status indicates that the Recipient SO has returned the application and a notification is sent to the agreement creator and all GAOs in the organization. This status can change to Pending Signature.

Withdrawn: This status indicates that the Recipient SO has chosen to withdraw or cancel the application in the first step. An application cannot change to any other status from Withdrawn.

Submitted: This status indicates that the Recipient SO has signed and submitted the application. This status can change to Pending Clarification, Considered, Not Considered, or Cancelled.

Considered: This status indicates that the approver has selected Consider from the decision dropdown. Once this status is selected applications that are peer review relevant will be sent to the Application Review Process (ARP). From Considered, the application can become Not Accepted, Cancelled, or Pending Clarification.

Not Considered: This status indicates that the approver has selected Not Consider from the decision dropdown. An application cannot change to any other status from Not Considered.

Pending Clarification: This status indicates that the approver has selected Return from the decision dropdown and is awaiting action from the application creator(s). This status can change to Pending Signature.



Cancelled: This status indicates that the approver has selected Cancel from decision dropdown. An application cannot change to any other status from Cancelled.

Grant Review: This status indicates that the approver has selected Accept from the decision dropdown. This status can change to National Approval, Accepted/Recommended, Returned to Program Manager, or Cancelled.

Not Accepted: This status indicates that the approver has selected Not Accept from the decision dropdown. An application cannot change to any other status from Not Accepted.

National Approval: This status indicates that the National Program Manager has selected Approve from the decision dropdown. This status can change to Accepted/Recommended status.

Accepted/Recommended: This status indicates that the approver has selected Approve from the decision dropdown. This status can change to Cancelled, Not Approved, or Approved status.

Returned to Program Manager: This status indicates that an agency approver has selected Return from the decision dropdown and is awaiting action from the agency Program Manager. This status can change to Cancelled, Not Accepted, Grant Review, or Pending Clarification.

Approved: This status indicates that the approver has selected Approve from the decision dropdown. An application cannot change to any other status from Approved. This is the final status of the application approval workflow, triggering the automatic creation of a draft agreement in SAP CRM.

Not Approved: This status indicates that the approver has selected Not Approve from the dropdown. An application cannot change to any other status from Not Approved.

To learn more about the Application Management process, refer to the following Job Aids:

Application Create Job Aid

Application Approve – External Job Aid

Application Approve – Internal Job Aid



Panel Management & Application Review Process This process provides users with the ability to manage the Application Review Process within the External Portal (Pega) where they are able to create and manage panels. It also allows users to assign applications to panels and send applications through the Application Review Process (ARP) workflow. Creating a Panel

Panels Screen

This Screen allows internal users to create and manage panels within the External Portal (Pega). It also allows internal users to begin the Application Review Process for the application to become an agreement. A user assigned with either the Program Manager or AGMO role has the ability to create a panel by clicking the Create Panels button from the navigation bar. For reference, a Reviewer is an individual, either an Internal or External user, who reviews an application during the Application Review Process. An Internal User must switch roles in the External Portal (Pega) to the Reviewer Role. The Reviewer will be involved in reviewing the application in the Conflict of Interest, Individual Review, and Consensus Review stages. Readers, the other group within panel members, can submit Reader Comments during the Individual Review but are not able to submit numerical scores. The following sections are present in the External Portal (Pega) in addition to the Create Panels Screen:

Create Panels Screen: The purpose of the Create Panels Screen is to provide internal users with the ability to create panels within the External Portal. The panels will be used to review applications submitted against competitive opportunities.

Search Panel Screen: The purpose of the Search Panel Screen is to provide internal users with the display-only view of panels. Agency users have the ability to search for previously created panels within the ezFedGrants External Portal (Pega). By inputting data in the available search criteria, the user will be able to view all relevant search results. Similar to the Reviewer Search Screen detailed earlier in the Reference Guide, the agency user can access the Search Panel Screen through the Panels tab in the navigation bar on the Main Menu. Upon launching the Search Panel screen, the user will be able to specify search criteria. The user can input search criteria including Opportunity Number, Panel ID, Panel Name, Scribe, or Panel Member Name. Depending on the input of the user, the system will display the Panels that match the search criteria selected. If no object matches the search criteria, the system will not display any results, and the system will display a message that reads “No Search Results Were Found”.

Manage Panels Screen: The purpose of the Manage Panels Screen is to provide internal users with the ability to modify panels within the External Portal. A user will search for the panels to be able to add or remove panel members and modify the panel assignments for a panel that is not already assigned to an application, as well as change the Program Manager and Panel Manager roles

Application Decision Screen: The purpose of the Application Decision Screen is to provide internal users with the ability to assign an application to an existing panel within the External Portal. The user can assign the application to a panel, consider the application and assign the panel later, return the application (which is not applicable to Grants.gov applications), cancel the application or set the status to Not Consider.

Conflict of Interest Summary Screen: The purpose of the Conflict of Interest Summary Screen is to provide internal users with the ability to send an application to Individual Review after the Conflict of Interest phase has been concluded. This Screen is accessed by a user with the Program Manager role listed on the panel in his/her Actionable Items List. This Actionable Item is sent to a user with the Program Manager role as soon as an application is routed to a panel within their program. The internal user can execute one of three actions from the Screen: o The internal user can send the application to Individual Review o The internal user can modify a scribe and adjust panels Member Roles for an existing application



o The internal user can choose to reassign the panel and return the application to an earlier step in the workflow to be assigned to a different panel.

Individual Review Summary Screen: The purpose of the Individual Review Summary Screen is to provide internal users with the ability to send an application to Consensus Review after the Individual Review phase has concluded. The Review Summary Screen also allows the internal users to view the score cards associated with the individual reviews. The internal user can adjust panel member roles for an existing panel of an application.

Panel Overview: Scores and Ranking Screen: The purpose of the Panels Overview: Scores and Ranking Screen is to provide internal users with the ability to view how applications were scored, whether they were approved and their assigned budget. Users may view which applications have been approved, considered, or returned and the funds associated with the application

Editing a Panel

There are two methods to editing a panel:

The first is through the Manage Panels link. The internal user has the ability to edit a panel by navigating to the Manage Panels link in the navigation bar under the Panels tab. There, the user can search for the panel that they wish to edit and then click the Manage button. The user can then edit information ranging from panel name, as well as the individuals assigned to be Panel Manager, Scribe, Program Managers, Readers and Reviewers.

The second method is to edit an application’s individual panel instance on either the Conflict of Interest Summary Screen or the Individual Review Summary Screen. When sending a panel to Individual Review as well as Consensus Review, as detailed in the below “Approving a Panel” section, the internal user has the ability to adjust a panel member’s role from a Reader to a Reviewer and vice versa. Once in Consensus Review, only the Scribe can be updated. This adjusts the roles for the panel members for that specific application only.

Application Review Process

After an application is submitted by an external user against a competitive opportunity, the Program Manager (PM) listed as a Programmatic Contact on the opportunity receives an actionable item to consider or not consider the application. Once considered by the Program Manager, the application must then be assigned to a panel and from there it will go through the Application Review Process. Users also have the ability to consider an application but select the panel at a later date. The application would move to the status Pending Panel Assignment.



Figure 9 illustrates the standard panel workflow for assigning a panel:

Figure 9: ARP Workflow – assigning a panel

Upon panel assignment, the Application Review Process begins with the Conflict of Interest (COI). The respective panel Members will receive an actionable item that will require them to identify any Conflict of Interest(s) and submit. Once submitted, the Program Manager assigned to the panel must review the Conflict of Interest Summary Screen and determine whether or not to move the application forward to Individual Review. The Program Manager also has the ability to change the roles for existing panel members prior to sending the application forward if needed.



Figure 10 illustrates the standard Application Review Process Workflow for Identifying and Reviewing the Conflict of Interest(s):

Figure 10: ARP Workflow – identifying a COI

The COI identification process leads to the next section, when the Agency user is able to send the application to individual review. Figure 11 illustrates the standard Application Review Process Workflow for Evaluating the Conflict of Interest Responses:

Figure 11: ARP Workflow – evaluating a COI



After the application is sent forward by the Program Manager listed on the panel, Readers/Reviewers are notified, via a work item, that the application is available for Individual Review. They will then complete the Individual Scorecards and submit them to the Program Manager for review. The Program Manager reviews the responses in the Individual Summary Screen and must determine if the responses meet all the necessary requirements. Once the Program Manager has deemed the Individual Scorecards and Reader Comments as sufficient, it is marked as completed and will move to Consensus Review. The application reaches the final stage of the Application Review Process at Consensus Review. Once the Program Manager completes the Individual Summary and submits the Consensus Scorecard, the Panel Members (which includes the Readers and Reviewers) must approve the Consensus Scorecard after reviewing and adding comments as needed. Lastly, the Program Manager must determine that the Consensus Scorecard meets all requirements and mark it as complete.



Figure 12 illustrates the standard Application Review Process Workflow for Reviewing and Scoring a Consensus Scorecard:

Figure 12: ARP Workflow – reviewing and scoring a consensus card

Status Definitions

The following are common status definitions for the aforementioned workflows:

Pending Panel Assignment: This status indicates that the application status is Considered but a panel has not yet been selected by the agency user. From Pending Panel Assignment, the review status can be changed to Sent to Panel. The user can also choose to change the application status to Cancelled.

Sent to Panel: This status indicates that the designated agency user (e.g. PM) has successfully assigned the application to a panel. The panel members will receive a work item to identify Conflict of



Interest and the agency user will receive a work item to track the identified conflict of interest. From Sent to Panel, the review status can be changed to Pending Individual Review or Pending Panel Assignment.

Pending Individual Review: This status indicates that the agency user has initiated the Individual Review phase. All Reviewers and Readers have received a work item to complete their individual review. The agency user has received a work item to track the submitted reviews. From Pending Individual Review, the review status can be changed to Pending Consensus Review.

Pending Consensus Review: This status indicates that the agency user has initiated the Consensus Review phase. The Scribe has received a work item to complete the Consensus Review. Readers and Reviewers receive a display only view of the Consensus Scorecard. From Pending Individual Review, the Review Status can be changed to Pending Consensus Approval.

Pending Consensus Approval: This status indicates that the Scribe has completed the Consensus Review. All panel members with no conflict of interest will receive a work item to approve the Consensus Score Card. The agency user will also receive a work item to approve the Consensus Score Card. From Pending Consensus Approval, the review status can be changed to Complete Consensus Review or Pending Consensus Review if the agency user marks the Consensus Scorecard as incomplete.

Complete Consensus Review: This status indicates that all panel members (Reviewers and Readers) have approved the Consensus Score Card and that the agency user has marked the consensus score card complete. This status is the final review status. This review status cannot be changed to a different status.

To learn more about the ARP and Panel Management processes, refer to the Job Aids here:

Panel Create Job Aid

Panel Assign Job Aid

Review Conflict of Interest Job Aid

Review Individual Summary Job Aid

Review Consensus Scorecard Job Aid



Agreement Management Once an application is approved for an opportunity, a draft agreement is created in CRM. Once the agreement is finalized, the agreement is a written contract between the external organization and the federal agency regarding all stipulations and award information. Before the agreement is finalized, it must pass through the agreement approval workflow. The workflow routes the agreement through various agency users and facilitates the bilateral electronic signature of the award document. Creating an Agreement

Agreement Screen

Agreements are created and managed in the Internal Portal (SAP CRM). The agreement process begins when an agreement is manually created in the Internal Portal (CRM) or after an application is approved in the External Portal (Pega). Approved applications are transferred to CRM to initiate a Draft agreement. Once the agreement is saved in Draft status, a user can locate the existing agreement through the Agreement Search Screen. Subsequently, a Grants Specialist or AGMO must complete the draft agreement by populating all required fields, updating the status to Draft Finalized, and clicking save. Once all submission validations pass, the approval workflow begins and a work item is sent to the first reviewer. The following sections are present on the Agreement Screen:

Agreement Overview: This section outlines general information about the agreement.

Project Details: o General Details o Authorities

Justification for Non-Competition: This section captures whether the opportunity was competitively advertised on Grants.gov.

Detailed Budget List: This section outlines the detailed federal budget information for the agreement. Each detailed line item contains an expense type and a string of financial funding elements. The funding strings are determined by the Funds Pre-Commitment populated in the agreement overview section.

Budget – Party Contribution: o Total Non-Federal Funds o Total Federal Funds Awarded o Total Approved Budget

FFATA reporting: This section is also present on the Application Screen. If the agreement is retrieved from the External Portal (Pega), then the fields will automatically populate with the data from the application.

Notes: This section contains different note types that will be added to accommodate the Project Narratives. The Purpose note will always be required before the user will be able to submit an agreement.

Attachments: This section requires the user to upload any documents to submit an agreement for approval.

Change History: This section allows the user to trace all changes made to an agreement transaction.

Transaction History: This section gives a precise historical study of all relevant business transactions associated with the agreement transaction.

Partners: This section outlines the business partners associated with the agreement, and their contact information.

In addition, the following field is automatically populated for the agreement:



Federal Award Identification Number (FAIN) – The FAIN number is automatically generated by the system, and once generated it cannot be changed. The FAIN agreement is generated just prior to the agreement signature.

More details on required fields, partners, and attachments are below: Fields: In order to save an agreement in Draft status, the following fields must be populated by the user:

Payment System

Instrument Type **Please note that this dropdown will be blank until the Program ID/Name field is populated by the user**

Recipient ID/Name

Recipient Contact

Program ID/Desc.

Project Title

Fiscal Year

Period of Performance Actual Start Date

Period of Performance Actual End Date

Funds Pre-Commitment ID In order to move the agreement to workflow, the following fields must be populated by the user:

CFDA Number

Period of Performance Proposed Start Date

Period of Performance Proposed End Date

Financial Reporting Schedule

Performance Reporting Schedule

Property Reporting Schedule

Payment Schedule

High Risk Recipient

NICRA Rate In addition, the Project Details section is agency-specific. The Project Details section is split into two sections: General Data and Authorities. None of these fields are required to save the agreement in Draft status, but in order to submit an agreement to workflow, at least one authority must be selected as “Yes,” and all general data fields must be selected as “Yes” or “No.” If “Other” is selected as “Yes” in the Authorities section, then the corresponding free text field is mandatory.

General Details: o International o Politically Sensitive o Ceremonial o Precedent Setting o Benefits minority, tribal, low income, or underserved entities o SPOC Review Relevant

Authorities: o 7 USC 7701-7772 o 7 USC 8301-8317 o 7 USC 2131-2159 o 7 USC 7781-7786 o 7 USC 426-426d o 7 USC 2279g o Other



In the Detailed Budget List section, all agreements must have at least one line item before submission for approval. On the Agreement Item: New Screen, certain fields are required in order to return to the main Agreement Screen. In addition to the fields listed below, there may be agency or capability specific fields required.

Expense Type

WBS Element

Obligation Direct Cost In addition to the fields listed above, the following fields are required to save a line item:

Program Activity

Work Category Partners: Below is a table indicating the required agreement partners and how many are required:

Partner Function Required

Recipient Administrative Contact 1

Recipient Signatory Official 1

Recipient Program Contact 1

Recipient 1

Agency Grants Specialist 1

Agency Financial Approver 2

Agency Program Manager 2

Agency Signatory Official 2

Agency Program Reviewer* 1

Agency Sensitivity Reviewer** 1

Attachments: Certain attachments are required to submit to workflow: The following attachments are mandatory in the Application/Proposal Documents subset:

SF-424 – Application for Federal Assistance

SF-424A – Budget Information Non-Construction Programs

SF-424B – Assurances – Non-Construction Programs

SAM.gov Record

Decision Memo The following attachments are mandatory in the Award Package subset:

Work Plan

Financial Plan

ADODR Responsibilities The following attachments are mandatory in the Letter subset:

SPOC Letter ** SPOC Letter is only mandatory if “SPOC Review” is “Yes” on the agreement** Editing an Agreement

The agreement is editable by the agreement creator until it moves to workflow. This is done via the Edit button on the Agreement Screen. In addition, the agreement can be returned to the Grants Specialist during workflow indicating that s/he has to edit or review the returned agreement.



Agreement Approval Workflow

The approval process for an agreement begins after the agreement is saved in Draft Finalized status. In the Project Details Screen, the next step is to identify if the agreement is Sensitive. International, Politically Sensitive, Ceremonial, or Precedent Setting. If International is selected, the agreement is routed to the Program Reviewer for approval. If any of the other three options is selected, the agreement is routed to the Sensitivity Reviewer for approval. After the initial approval, regardless of what dropdown was selected, the agreement is routed to the Program Manager for approval. If the application is received online it is routed to the Recipient Signatory Official and then to the Agency Signatory Official for their respective signatures. If the application is received offline it is routed to the Grants Specialist who must print out the award package for the required signatures, email the document, and then, once returned, attach the signed document to the agreement attachments section. The approval process will end with the Financial Approver and the status will be updated to Active. At the end of the approval process, the Funds Commitment (the financial obligation tied to an agreement in FMMI ECC) is generated in FMMI ECC and an Award between the Recipient and the agency is created.

For the purpose of the following tables, please use the following reference groups: o Group A: International o Group B: Politically Sensitive, Ceremonial, Precedent Setting

Below is an overview of the workflow “happy path” (no returns or cancellations) for an agreement manually created in the ezFedGrants Internal Portal (SAP CRM), with Groups A and B populated as “No.” This table documents the user and the status change to move the agreement to the next step in the workflow:


Agency Grants Specialist Draft to Routed for Approval

Agency Program Manager Routed for Approval to Pending Signatures

Agency Grants Specialist Pending Signatures to Fully Executed/Routed for FA

Agency Financial Approver Fully Executed/Routed for FA to Active

Below is an overview of the workflow “happy path” (no returns or cancellations) for an agreement sourced from the ezFedGrants External Portal (Pega), with Groups A and B populated as “No.” This table documents the user and the status change to move the agreement to the next step in the workflow:



Agency Program Manager Routed for Approval to Awaiting Recipient Signature

Rec. Signatory Official Awaiting Recipient Signature to Awaiting Agency Signature

Agency Signatory Official Awaiting Agency Signature to Fully Executed/Routed for FA


Below is an overview of the workflow “happy path” (no returns or cancellations) for an agreement manually created in the ezFedGrants Internal Portal (SAP CRM), with Group A populated as “Yes” and Group B populated as “No.” This table documents the user and the status change to move the agreement to the next step in the workflow:


Agency Grants Specialist Draft to Draft Finalized

Agency Program Reviewer Draft Finalized to Routed for Approval







Below is an overview of the workflow “happy path” (no returns or cancellations) for an agreement sourced from the ezFedGrants External Portal (Pega), with Group A populated as “Yes” and Group B populated as “No.” This table documents the user and the status change to move the agreement to the next step in the workflow:








Below is an overview of the workflow “happy path” (no returns or cancellations) for an agreement manually created in the ezFedGrants Internal Portal (SAP CRM), with Groups A and B populated as “Yes.” This table documents the user and the status change to move the agreement to the next step in the workflow:



Agency Program Reviewer Draft Finalized to Pending Review

Agency Sensitivity Reviewer Pending Review to Routed for Approval




Below is an overview of the workflow “happy path” (no returns or cancellations) for an agreement sourced from the ezFedGrants External Portal (Pega), with Groups A and B populated as “Yes.” This table documents the user and the status change to move the agreement to the next step in the workflow:









Below is an overview of the workflow “happy path” (no returns or cancellations) for an agreement sourced from the ezFedGrants External Portal (Pega), with Group A populated as “No” and Group B populated as “Yes.” This table documents the user and the status change to move the agreement to the next step in the workflow:


Agency Grants Specialist Draft to Pending Review








Below is an overview of the workflow “happy path” (no returns or cancellations) for an agreement manually created in the ezFedGrants Internal Portal (SAP CRM), with Group A populated as “No” and Group B populated as “Yes.” This table documents the user and the status change to move the agreement to the next step in the workflow:










Figure 13 illustrates the standard agreement approval workflow:

Figure 13: Agreement approval workflow diagram

The agreement workflow interacts with FMMI ECC in a few different ways. A Funds Pre-Commitment, funds designated in FMMI ECC prior to the creation of an agreement, is central to a few fields on the Agreement Screen. The Funds Pre-commitment and agreement have a 1:1 relationship; the Funds Pre-Commitment ID is a mandatory field on the Agreement Screen. In addition, the WBS Element options in the Detailed Budget List, another section in the Agreement Screen, are directly tied to the Funds Pre-Commitment ID. In addition, the Obligation, or Funds Commitment, is automatically created after the agreement is fully approved during the approval workflow. This status, identified as Active, is directly after the Pending FC Creation status, described below. The Funds Commitment document, which is automatically created after the FA approves the work item, is created in reference to the Funds Pre-Commitment and only obligates the funding allocated on the line items in the Detailed Budget List.



Status Definitions


Draft: This status indicates that the agreement is in draft mode. The status of the agreement is defaulted to Draft when an agreement is either manually initiated in the ezFedGrants Internal Portal (SAP CRM) or created from an approved application in the ezFedGrants External Portal (Pega). This status has no bearing on the agreement approval workflow; the Grants Specialist will manually change the status to Draft Finalized to submit the agreement to workflow.

Draft Finalized: This status indicates that the Grants Specialist has successfully completed and saved the draft agreement, and that the agreement subsequently passed all required validations. This status is manually selected by the Grants Specialist when submitting the agreement. If International was selected on the agreement, then the agreement will remain in this status and route to the program Reviewer. If International was not selected on the agreement, then this is an intermittent status, and the agreement will either become Pending Review or Routed for Approval, depending on the agreement scenario.

Pending Review: This status indicates that the agreement is awaiting approval from the Sensitivity Reviewer. The agreement will only enter this status if at least one of the following checkboxes is selected on the Project Details section of the agreement: Politically Sensitive, Precedent Setting, and Ceremonial. From Pending Review, the status can become Returned or Routed for Approval.

Routed for Approval: This status indicates that the agreement is awaiting approval from the Program Manager. Routed for Approval is a status for either the first or third step in workflow, depending if the International checkbox was selected on the agreement. From Routed for Approval, the status can become Awaiting Recipient Signature, Returned, or Cancelled.

Pending Signatures: This status indicates that the agreement is with the Grants Specialist, who is tasked with obtaining the bilateral signatures offline. From Pending Signatures, the status can become Fully Executed/Routed to Financial Approver, Cancelled, or Returned.

Awaiting Recipient Signature: This status indicates that the Recipient Signatory Official has an actionable item in the ezFedGrants External Portal (Pega) to sign the agreement. From this status, the agreement can become Awaiting Agency Signature or Recipient Rejected.

Recipient Rejected: This status indicates that the Recipient SO has rejected the agreement and the PM now must cancel or return the agreement. This status can change to Cancelled or Returned.

Awaiting Agency Signature: This status indicates that the agreement is awaiting approval from the Signatory Official. If the agreement is in this status, then the award document has already been signed by the Recipient Signatory Official. From Awaiting Agency Signature, the status can become Returned or Fully Executed/Routed to FA.

Fully Executed/Routed to Financial Approver: This status indicates that binary signatures have been obtained, and also that the agreement is awaiting the Financial Approver’s approval. This marks the official start of the agreement. From Fully Executed/Routed to FA, the status can only be changed to Pending FC Creation or Returned.

Active: This status indicates that the agreement has been approved by the Financial Approver and that a Funds Commitment document was successfully created in FMMI ECC.

FC Creation Failed: This status indicates that after the Financial Approver submits the agreement for the final stage of approval, the Funds Commitment creation failed. This sends an email and work item to designated agency users. The reasons behind this status include an award with expired funding (without special agency approval), an issue with the recipient organization, an outstanding issue with the Funds Commitment, or an incorrect configuration for the Funds Commitment. At this point, the user can attempt to retrigger the FC Creation to attempt to create the obligation again.

To learn more about the agreement Management process, refer to the Job Aids here:

Agreement Create Job Aid

Agreement Approval – Agency Job Aid

Agreement Approval – External Job Aid



Claims Management Once an agreement is created between an internal and external user, the awarded amount will be dispersed throughout the duration of the agreement. Claims represent any reimbursement payment requested by the external user for an existing agreement. Claims are necessary so that internal users have a means by which they can easily transfer funds to the organization. Creating a Claim

Claim Screen Reimbursement payments can be created by either a Grants Specialist or AGMO who receive an SF-270 form through the External Portal (Pega). When the SF-270 is approved in the External Portal (Pega), the claim is created automatically in SAP CRM. On the other hand, the Grants Specialist or AGMO can manually initiate the claim through SAP CRM upon receiving an offline submission of the SF-270 from the external user. To manually create a claim, the user will click on the claim link in the Create Work Center, search for the agreement that the user wants to create a claim against and click the relevant agreement Number to open the claim page. The following sections are present on the Claim Screen:

Claim Overview: This section captures all the general information concerning the claim.

Claim General Data: This section is prepopulated with data about the agreement and program the claim is in as well as the claim Date, Period Covered, and Status.

Recipient Organization: This section is prepopulated with the recipient contact information.

Claim Totals: This section is populated with data summing all of the claims made on this agreement to date.

Item List: This section displays the details of the claim. At first it will be blank. After the user itemizes each expense item on the Claim Screen list and saves, items will be created here. The Total Expenses row will sum all expenses claimed for the period specified on the SF-270 during which the claim is submitted. The user will have the option to either manually populate either the total field, causing the system to calculate the direct and indirect expense fields, or to manually populate the direct, causing the system to calculate the total field.

Attachments: This section is used to track all of the attachments that have been added to the claim.

Change History: This section tracks all changes made to the claim and by whom they were made.

Transaction History: This sections tracks documents associated to the claim including the program and agreement the claim are made on and the invoice that is created when the claim is approved.

Partners: Business partners from the agreement are pulled to this section.

Notes: This section captures any notes regarding the claim that the user would like to include. If a claim goes to Not Eligible status, a note will be required and populated here.

Editing a Claim

There are three scenarios for when an internal user wants to edit a claim:

The first is when an agency user creates a draft claim directly in the ezFedGrants Internal Portal based on a payment request (SF-270 form) they received from a recipient offline. At that time, the user can edit on the Claim Screen by clicking the Edit button.

The second is when an agency user edits a claim that has been automatically created in the ezFedGrants Internal Portal based on a payment request (SF-270 form) they received from a recipient online. The agency would usually edit the claim in this case to further specify on the claim where the funds would be originating from. At that time, the user would edit the claim through a work item they receive in the ezFedGrants Internal Portal.

Lastly, the user can edit a claim when it was returned to them during the claim approval workflow.



Claim Approval Workflow

Once the claim is created and deemed as eligible, the claim is routed to the Program Manager for approval. The Program Manager has the ability to return, cancel, or approve the claim. If approved, the status of the claim is changed to Paid. If it is returned or cancelled, it is routed back to the Grants Specialist to edit or cancel the claim altogether. Figure 14 illustrates the standard claim approval workflow:

020User completes the

claim and changes the status to Valid

030Is the claim

eligible?

010User manually initiates a claim from an offline

SF-270 submission

040The claim is routed to the Program Manager in Not Eligible status

No

130It is routed to the GS in In Progress status. GS populates line item(s)

050What does the PM

do?

060The claim is routed to

the Grants Specialist in Returned status

110Claim approved in Pega

enters CRM in Valid status

Return

070The status is updated

to Cancelled

Cancel

140What does the GS

do?

080The claim is routed to the Program Manager

in Routed for Approval

090What does the PM

do?

100The status is updated

to Paid

Approve

Return

Go to 060

Yes Approve

Go to 070

Cancel

150What does the GS

do?Cancel

Go to 020

Edit

120Is the claim

eligible?Yes

Go to 040

NoInvalid

Go to 010

Figure 14: Claim approval workflow diagram

After the claim is fully approved and the claim is in Paid status, a corresponding billing request and subsequent invoice are automatically created in FMMI ECC. FMMI ECC will automatically gather details from the Claim Screen such as the Recipient ID, claim total amount, and Agreement ID, as well as information from the associated Funds Commitment of the agreement. As payments are finalized, the Funds Commitment is further consumed. Below is an overview of the workflow “happy path” (no returns or cancellations) for a claim sourced from a submission in the ezFedGrants External Portal (Pega). This table documents the user and the status change to move the claim to the next step in the workflow:


(Pega) Valid to In Progress

Agency Grants Specialist In Progress to Routed for Approval

Agency Program Manager Routed for Approval to Paid



Below is an overview of the workflow “happy path” (no returns or cancellations) for a claim manually created in the ezFedGrants Internal Portal (SAP CRM). This table documents the user and the status change to move the claim to the next step in the workflow:


Grants Specialist Draft to Routed for Approval

Program Manager Routed for Approval to Paid

Status Definitions


Draft: This status indicates that the claim is in draft mode. The status is defaulted to Draft when a new claim is manually initiated in the FMMI Grantor Management Internal Portal (SAP CRM). From Draft, the status can become Valid or Invalid.

Valid: This status indicates that one of two scenarios has occurred: o The Grants Specialist or AGMO manually changed the status from Draft to Valid, at which point

the system performs a validation that there are no other claims in process for the same agreement, that the SF-270 is attached, and that there are no overdue activity reports against the associated agreement. From Valid, the status can become Routed for Approval or Not Eligible.

o The Program Manager approved an SF-270 in the FMMI Grantor Management External Portal (Pega). A Valid claim is created in the FMMI Grantor Management Internal Portal (SAP CRM), at which point the system performs a validation that there are no other claims in process for the same agreement, that the SF-270 is attached, and that there are no overdue activity reports against the associated agreement. From Valid, the status can become In Progress or Not Eligible.

Invalid: This status indicates that the Draft claim manually initiated in the FMMI Grantor Management Internal Portal (SAP CRM) by the Grants Specialist was saved with an invalid SF-270 attached. The Grants Specialist gauges that the Recipient submitted an SF-270 that is invalid. The claim would be put into Invalid status if the SF-270 submitted to the agency contains errors on the form or if the recipient requested more funds than were available based on their agreement. The SF-270 in this case was submitted offline, and the Grants Specialist manually initiated the claim in the Internal Portal (SAP CRM). This status will be manually entered by the Grants Specialist and triggers an email to the Program Manager indicating that the recipient submitted an invalid SF-270. No workflow activities follow this state, and the claim will not be editable by anyone in this status. The claim would have to manually be retriggered with a valid SF-270.

In Progress: This status indicates that the claim received from the FMMI Grantor Management External Portal (Pega) passed the Valid eligibility check. The workflow is triggered and the Grants Specialist receives a work item and email notification. From In Progress, the status can become Cancelled or Routed for Approval.

Not Eligible: This status indicates that the eligibility check conducted in Valid status did not pass. The status of the claim is automatically updated to Not Eligible and, when saved, an email and work item are sent to the Program Manager to inform him/her of the ineligibility of the claim. The ineligibility reason is displayed as a header note on the claim. The Program Manager can either return or cancel the claim. From Not Eligible, the status can become Returned or Cancelled.

Routed for Approval: This status indicates that the claim is awaiting approval from the Program Manager. From Routed for Approval, the status can become Returned, Cancelled, or Paid.

Paid: This status indicates that the claim has been approved by the Program Manager and signals the end of the workflow. A billing request and subsequent invoice in FMMI ECC are generated once this status is entered. There are no statuses that follow Paid, and the claim is not editable in this status.



Returned: This status indicates that the work item has been returned to the Grants Specialist by the Program Manager to fulfill a required action before being resubmitted for approval. From this status, the claim can either be resubmitted to workflow or cancelled using the dropdown list in the work item. o The Program Manager must include rationale within a comment in order to return a work item, in

addition to selecting a dropdown value. The return reasons are as follows: Other Debarred/Suspended Funding Changes Scope of work changes Budget/Scope of Work Clarifications Major Editing Questionable Legality Questionable Funding Inappropriate Instrument Type Funds Pre-Commitment Discrepancy Insufficient Justification Recipient Non-Compliance

Cancelled: This status indicates that the claim has been cancelled by an agency user at some point during workflow. The claim may be cancelled in workflow by the Program Manager, Grants Specialist, or AGMO when s/he has the work item. o The user must include rationale within a comment in order to cancel a claim, in addition to

selecting a dropdown value. The cancellation reasons are as follows: Budget/Scope of Work Clarifications Debarred/Suspended Funding Changes Funds Pre-Commitment Discrepancy Major Editing Other Questionable Legality

To learn more about the Claims Management process, refer to the Job Aids here:

Claim Create Job Aid

Claim Approval – Internal Job Aid

Claim Approval – External Job Aid



Amendment Management After an agreement is created and approved between the external organization and the federal agency, many changes or updates to the agreement must be made through the amendment process. Amendment(s) allow for either the internal or external user to make changes to the already agreed upon agreement. Changes can vary from the amount awarded, the duration of the agreement, as well as other financial and systematic changes. Changes that are included in the below scenarios are subject to amendments, while some changes – that are called administrative changes – are made directly on the agreement outside of the amendment process. These types of changes are not included in the below scenarios. The only exception to this rule is any administrative change made to the Notes or Partners section. These changes require no approvers – once the amendment is saved in Draft Finalized status, it will become an Active amendment. Creating an Amendment

Amendment Screen

The user can create an amendment against the agreement by selecting the agreement they wish to change through the Amendment Create Screen. The user will then need to search for the agreement they want to amend and then select the amendment form in the search results. The Amendment Screen is launched with all the fields already pre-populated from the agreement. Then, necessary changes are made, the status is changed to Draft Finalized, and the Save button is clicked to trigger the amendment approval process. Please refer to the Agreement Screen for more information on each of the sections; however, the following sections are present on the Amendment Screen as well:

Amendment Overview

Project Details o International/Politically Sensitive/Ceremonial/Precedent Setting/Benefits minority, tribal, low

income or underserved entities, SPOC Review Relevant o Authorities

Detailed Budget List

Budget – Party Contribution (each Expense Type includes Current, Change, and Proposed Value sections)

FFATA reporting

Notes

Attachments

Change History

Transaction History

Partners: The Program Manager and the Program Contact are the only partner changes that require workflow approval.

Editing an Amendment

An amendment can be edited in two instances:

The first is if an amendment is in Draft status and the internal user wants to make edits on the Amendment Screen itself. This can be done by clicking the Edit button on the desired section on the Amendment Screen.

The second instance is if an amendment is returned to the user via the amendment approval workflow, at which time the status of the amendment can become Draft Finalized, Routed for Approval, or Cancelled.



Amendment Approval Workflow

The workflow is status-driven and triggered when the status of the amendment is updated to Draft Finalized and successfully saved. Work items are sent to the proper users designated as mandatory on the Partners section of the Amendment Screen. When the user initiates an amendment, s/he determines what changes are needed. The workflow varies based on what the nature of the change in the amendment is. Once the appropriate scenario for the amendment is determined, there are required approvers as well as actions needed for each scenario. The amendment workflow interacts with FMMI ECC as well. Depending on the type of amendment, when the amendment status changes to Active, the Funds Commitment and agreement are automatically updated accordingly.

Figure 15 illustrates the amendment approval workflow scenario determination:

Figure 15: Amendment approval workflow scenario determination diagram

The following are the descriptions for each of the scenarios mentioned in the workflow above:

Scenario 1: This scenario is a no-cost extension that is triggered by the recipient. If an agreement requires non-financial changes but includes an extension to the Period of Performance End Date, then the amendment undergoes a full approval workflow that bypasses the Financial Approver. If the program of the agreement is PPQ Headquarters, then the workflow will include the Financial Approver. Only one no-cost extension is allowed per agreement. This will be denoted on the Amendment Overview section in the Amendment Type field. The user will be required to upload the following attachments before submitting to workflow: o No-Cost Extension Letter o SF-424 - Application for Federal Assistance Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment manually created in the ezFedGrants Internal Portal (SAP CRM), whose program is not PPQ-related. This table documents the user and the status change to move the amendment to the next step in the workflow:







Agency Grants Specialist Pending Signatures to Active

Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment sourced from the ezFedGrants External Portal (Pega), whose program is not PPQ-related. This table documents the user and the status change to move the amendment to the next step in the workflow:





Agency Signatory Official Awaiting Agency Signature to Active

Below is an overview of the workflow “happy path” (no returns or cancellations) for an agreement manually created in the ezFedGrants Internal Portal (SAP CRM), whose program is PPQ-related. This table documents the user and the status change to move the amendment to the next step in the workflow:






Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment sourced from the ezFedGrants External Portal (Pega), whose program is PPQ-related. This table documents the user and the status change to move the amendment to the next step in the workflow:







Scenario 2: If the Proposed Agreement Total increases or decreases, then the amendment undergoes a full approval workflow. If additional funds are needed on the Funds Pre-Commitment to execute an increase in funds, then the user will need to contact the person responsible for the Funds Pre-Commitment to have the necessary amount added. The user will be required to upload the following attachments before submitting to workflow: o SF-424 - Application for Federal Assistance o SF-424A - Budget Information - Non-Construction Programs o Financial Plan o Work Plan Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment manually created in the ezFedGrants Internal Portal (SAP CRM). This table documents the user and the status change to move the amendment to the next step in the workflow:









Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment sourced from the ezFedGrants External Portal (Pega). This table documents the user and the status change to move the amendment to the next step in the workflow:







Scenario 3: If an agreement requires non-financial changes but includes an extension or reduction to the Period of Performance End Date, then the amendment undergoes a full approval workflow that bypasses the Financial Approver. This amendment is triggered by the agency, marking its point of difference from Scenario 1. If the program of the agreement is PPQ Headquarters, then the workflow will include the Financial Approver. The user will be required to upload the following attachments before submitting to workflow: o SF-424 - Application for Federal Assistance o Work Plan Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment manually created in the ezFedGrants Internal Portal (SAP CRM), whose program is not PPQ-related. This table documents the user and the status change to move the amendment to the next step in the workflow:





Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment sourced from the ezFedGrants External Portal (Pega), whose program is not PPQ-related. This table documents the user and the status change to move the amendment to the next step in the workflow:






Below is an overview of the workflow “happy path” (no returns or cancellations) for an agreement manually created in the ezFedGrants Internal Portal (SAP CRM), whose program is PPQ-related. This table documents the user and the status change to move the amendment to the next step in the workflow:









Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment sourced from the ezFedGrants External Portal (Pega), whose program is PPQ-related. This table documents the user and the status change to move the amendment to the next step in the workflow:







Scenario 4: If the Primary Program Manager or Primary Recipient program Contact need to be updated, then the amendment undergoes a full approval workflow that bypasses the Financial Approver. An amendment FAIN will not be generated. There will be no required attachments before submitting to workflow. Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment manually created in the ezFedGrants Internal Portal (SAP CRM). This table documents the user and the status change to move the amendment to the next step in the workflow:





Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment sourced from the ezFedGrants External Portal (Pega). This table documents the user and the status change to move the amendment to the next step in the workflow:

Partner Function Status Changes





Scenario 5: If there is a change in scope, purpose, deliverables, or work plan, then the amendment undergoes a full approval workflow that bypasses the Financial Approver. If “International” is selected on the amendment, then an extra step in workflow will be needed for the program Reviewer. If “Politically Sensitive,” “Ceremonial,” or “Precedent Setting” is selected on the amendment, then an extra step in workflow will be needed for the Sensitivity Reviewer. The user will be required to upload the following attachments before submitting to workflow: o Work Plan For the purpose of the following tables, please use the following reference groups: o Group A: International o Group B: Politically Sensitive, Ceremonial, Precedent Setting



Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment manually created in the ezFedGrants Internal Portal (SAP CRM), with Groups A and B populated as “No.” This table documents the user and the status change to move the amendment to the next step in the workflow:






Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment sourced from the ezFedGrants External Portal (Pega), with Groups A and B populated as “No.” This table documents the user and the status change to move the amendment to the next step in the workflow:







Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment manually created in the ezFedGrants Internal Portal (SAP CRM), with Group A populated as “Yes” and Group B populated as “No.” This table documents the user and the status change to move the amendment to the next step in the workflow:







Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment sourced from the ezFedGrants External Portal (Pega), with Group A populated as “Yes” and Group B populated as “No.” This table documents the user and the status change to move the amendment to the next step in the workflow:








Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment manually created in the ezFedGrants Internal Portal (SAP CRM), with Groups A and B populated as “Yes.” This table documents the user and the status change to move the amendment to the next step in the workflow:










Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment sourced from the ezFedGrants External Portal (Pega), with Groups A and B populated as “Yes.” This table documents the user and the status change to move the amendment to the next step in the workflow:









Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment sourced from the ezFedGrants External Portal (Pega), with Group A populated as “No” and Group B populated as “Yes.” This table documents the user and the status change to move the amendment to the next step in the workflow:







Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment manually created in the ezFedGrants Internal Portal (SAP CRM), with Group A populated as “No” and Group B populated as “Yes.” This table documents the user and the status change to move the amendment to the next step in the workflow:








Scenario 6: If funds are reallocated on the same Cost Center, WBS Element, Functional Area, and Budget Period and there is a net zero funding change, then the amendment will undergo direct execution and become Active upon submission. If the agreement total exceeds $150K, then any net



zero change over 10% of the total will require approval from the Program Manager and Signatory Official. An amendment FAIN will not be generated. If the 10% threshold is exceeded, then the user will be required to upload the following attachments before submitting to workflow: o SF-424A - Budget Information - Non-Construction Programs o Financial Plan Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment that does not cross the threshold. This table documents the user and the status change to move the amendment to the next step in the workflow:


Agency Grants Specialist Draft to Active

Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment that does cross the threshold. This table documents the user and the status change to move the amendment to the next step in the workflow:



Agency Program Manager Routed for Approval to Awaiting Agency Signature


Scenario 7: If funds are reallocated between different Cost Center, WBS Element, Functional Area, and Budget Period combinations and there is a net zero funding change, then the amendment will undergo only financial approval before becoming Active. If the agreement total exceeds $150K, then any net zero change over 10% of the total will require additional approval from the Program Manager and Signatory Official. An amendment FAIN will not be generated. If the 10% threshold is exceeded, then the user will be required to upload the following attachments before submitting to workflow: o SF-424A - Budget Information - Non-Construction Programs o Financial Plan Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment that does not cross the threshold. This table documents the user and the status change to move the amendment to the next step in the workflow:


Agency Grants Specialist Draft to Fully Executed/Routed for FA


Below is an overview of the workflow “happy path” (no returns or cancellations) for an amendment that does cross the threshold. This table documents the user and the status change to move the amendment to the next step in the workflow:



Agency Program Manager Routed for Approval to Awaiting Agency Signature



Status Definitions




Draft: This status indicates that the amendment is in draft mode. The status of the amendment is defaulted to Draft when an amendment is manually initiated in the ezFedGrants Internal Portal (SAP CRM). The Grants Specialist will click Submit, and the status will change accordingly based on the amendment scenario being executed.

Draft Finalized: This status is only relevant for Scenario 5 when “International” is selected in the New Value column of the Project Details section of the Screen. It is irrelevant for all other scenarios. From Draft Finalized, the status can become Routed for Approval, Pending Review, or Returned.

Pending Review: This status is only relevant for Scenario 5 when “Politically Sensitive,” “Precedent Setting,” or “Ceremonial” is selected in the New Value column of the Project Details section of the Amendment Screen. From Pending Review, the amendment can become Routed for Approval, Awaiting Agency Signature, or Returned.

Routed for Approval: This status indicates that the amendment is awaiting approval from the Program Manager. From Routed for Approval, the status can become Awaiting Recipient Signature, Awaiting Agency Signature, Cancelled, or Returned.

Pending Signatures: This status indicates that the amendment is awaiting the Grants Specialist to obtain bilateral signatures offline. The Grants Specialist must attach a “Complete Award Package” document with the required signatures to the amendment in order to approve the amendment to Fully Executed/Routed for FA. From Pending Signatures, the Grant Specialist can change the amendment to Fully Execute/Routed for FA or Returned.

Awaiting Recipient Signature: This status indicates that the Recipient Signatory Official has an actionable item in the External Portal (Pega) to sign the amendment. From this status, the agreement can become Awaiting Agency Signature or Recipient Rejected.

Awaiting Agency Signature: This status indicates that the amendment is awaiting approval from the SO. From this status, the status can become Active, Amendment Fully Executed, or Returned.

Amendment Fully Executed/Routed for Financial Approval: This status indicates that the amendment is awaiting the Financial Approver’s approval. From Amendment Fully Executed, the status can only be changed to Active or Returned.

Active: This status indicates that the amendment has been fully approved through workflow. A call to FMMI ECC will be made to update the Funds Commitment document, if necessary. There are no further statuses for an amendment after Active.

Returned: This status indicates that the work item has been returned to the Grants Specialist at some point during the workflow. A work item is generated with this status, and an email is sent out to the Grants Specialist indicating that s/he has to edit/review the returned amendment. From Returned, the status can become Draft Finalized, Routed for Approval, or Cancelled.

Recipient Rejected: If the Agreement was created from an application in the External Portal (Pega), any valid amendments that require workflow approval must obtain approval or rejection from the recipient through the External Portal (Pega) as well. This status indicates that the Recipient opted to reject the amended award document from the associated actionable item. From Recipient Rejected, the Project Manager can changed to Returned or Cancelled.

Cancelled: This status indicates that the draft amendment has been cancelled by the agency. The Grants Specialist, Program Manager, and AGMO will be the only users with the ability to cancel an amendment. Whenever the Grants Specialist or Program Manager has a decision to make, s/he will have the option to move the work item along or cancel the amendment all together. After an amendment enters Cancelled status, no changes are allowed, and the status cannot be changed to any other status. If an amendment is in Cancelled status, then the user will be allowed to create a new amendment for the same agreement.

To learn more about the Amendment Management process, refer to the Job Aids here:

Amendment Create Job Aid

Amendment Approve – SAP CRM Job Aid

Amendment Approve – Pega Job Aid



Report Approval The report approval workflow is triggered when an authorized external user clicks the Submit button on a draft Report Submission Screen. The external user specifies the Certifying Official(s) from their organization who will sign the report in the Signature section of the report. This allows for external users to specify different Certifying Officials depending on the type of report. Note that a user can also list themselves as the Certifying Official. Upon the Certifying Official’s approval, the report is routed to agency users for review. The report allows for internal users to ensure that the funds provided are being used in accordance to the agreement created between the agency and recipient organization. Creating a Report

Report Screen

The agency user will navigate to the Pending Reports tile in the External Portal to view all reports submitted against agreements within their programs that are in Submitted status. The following sections are present on the Report Screen:

Pending Reports: Grants Specialists will see Reports in Submitted and Returned to Agency Reviewer status in the Pending Reports tile. AGMOs will see all Reports submitted against agreements within their programs that are in the Submitted or Submitted to AGMO status.

Actionable Items: The Recipient Project Director and Recipient Authorized Representative that are listed in the associated agreement will see reports that that are in Draft, Returned by Certifying Official, or Acceptance Pending Edits status. GAOs will see all reports for their organization in Draft, Returned by Certifying Official, or Acceptance Pending Edits status. The user(s) listed as a Certifying Official on the report will see reports in Draft Pending Signature status.

Notifications: Reports that are in Accepted status will display to the Recipient Project Director, Recipient Authorized Representative, all organization GAOs, and the signing Certifying Official.

Editing a Report

In the ezFedGrants External Portal, the report must be returned by the Certifying Official in the first step or the Program Manager/AGMO in the second step in order to be edited by the report originator. In the ezFedGrants Internal Portal, the activity can be edited when submitting an offline “activity,” which is an object in the ezFedGrants Internal Portal directly associated with the report. Internal users will have the option to complete the activity and add any relevant notes. Report Approval Workflow

Once an external user completes and submits their financial and/or performance report, a notification is sent to the Certifying Official to indicate their signature is needed. The Certifying Official may either sign and submit or return the report where it will be routed back to all GAOs of the specific recipient organization as well as the report creator. If the report is signed and submitted, it will be routed to the Program Manager and all AGMOs within the program, where it have the option to approve or disapprove the work item. Once approved, the report status updates to Accepted and the associated “activity” in the Internal Portal (SAP CRM) is marked complete. Below is an overview of the workflow “happy path” for a report. This table documents the user and the status change to move the report to the next step in the workflow:


Grant Processor Not Started / Draft to Draft Pending Signature

Certifying Official Draft Pending Signature to Submitted

Agency Program Manager Submitted to Accepted



Figure 16 illustrates the standard report approval workflow:

Figure 16: Report approval workflow diagram

Status Definitions


Not Started: This status indicates that the report submission request has transferred from the Internal Portal (SAP CRM) to the External Portal (Pega), but no Grantee/Recipient (external) user has started working on it yet. The status of the report will be defaulted to Not Started when a new report is generated in the External Portal (Pega) as an actionable item. While the report is in Not Started status, the external user has the ability to edit the report. This status has no impact on the report approval workflow. From Not Started, the status can only be changed to Draft or Draft Pending Signature status.

Draft: This status indicates that the report is in draft mode. The status of the report will be defaulted to Draft when an external user saves the report for the first time. While the report is in Draft status, the external user can make edits and save an infinite number of times. This status has no impact on the report approval workflow. From Draft, the status can only be changed to Draft Pending Signature status.



Draft Pending Signature: This status indicates that the report has been successfully saved and submitted by the Recipient external user. This status also indicates that the Certifying Official(s) specified on the report is required to take action: “Sign and Submit” or “Return.” From Draft Pending Signature, the status can only change to Submitted or Returned by Certifying Official status.

Returned by Certifying Official: This status indicates that the Certifying Official selected Return from the report workflow decision dropdown, requesting the originator to make edits to the report. From Returned by Certifying Official, the status can only be changed to Draft Pending Signature.

Submitted: This status indicates that the Certifying Official selected “Sign and Submit” from the decision dropdown and is awaiting the appropriate agency user’s action: “Accept” or “Return.” From Submitted, the status can only be changed to Accepted or Accepted Pending Edits status.

Accepted Pending Edits: This status indicates that the appropriate agency user has selected “Return” from the decision dropdown and is awaiting action from recipient personnel. From Accepted Pending Edits, the status can only be changed to Draft Pending Signature status.

Accepted: This status indicates that the appropriate agency user has selected the “Accept” option from the decision dropdown. A report cannot change to any other status from Accepted. This is the final status of the report approval workflow, triggering the automatic completion of the associated activity in the Internal Portal (SAP CRM).

To learn more about the report process, refer to the Job Aid here:

Agency Approval of Reporting Job Aid



Closeout Management Closeout Management facilitates the reviews required to close an agreement between an internal and external user after the end date is reached and all the processes, including claims, reports, and amendments, specified under the award have been completed. Creating a Closeout

Closeout Screen:

The creation of the closeout is initiated by either the Grants Specialist or AGMO where all activities must be marked as complete if eligible. The Grants Specialist or AGMO has the ability to either Approve, Cancel, or Reject the closeout. The closeout cannot be saved in Draft status, as it can only be saved in Routed for Approval or Rejected status. Upon submitting the closeout, the status is changed to Pending Signatory Official Closeout triggering the closeout Approval process. The following validations must be met for eligibility of the closeout:

Period of Performance End Date: The closeout can only be initiated if the Period of Performance End Date has passed for the agreement. For a terminated agreement, this Period of Performance End Date validation does not apply.

Third Party Active Audit / Pending Litigation: The system will prevent a closeout from being created against an agreement that has a third party active audit or a pending litigation; such an agreement is identified by the “Third Party Active Audit / Pending Litigation” checkbox being checked.

Closeout in Progress: The system will prevent a closeout from being created for agreements with a closeout already in process. Closeouts in progress are identified by statuses other than Rejected or Closed.

Agreement Status: The system only allows the user to create a closeout for agreements that are in Active or Terminated status.

Amendment in Progress: The system will prevent a closeout from being created against an agreement that has an amendment in process. Amendments in process are identified by statuses other than Active and Cancelled.

Claim in Process: The system will prevent a closeout from being created against an agreement that has a claim in process. Claims in process are defined by statuses other than Paid, Invalid, and Cancelled.

Activity Reports Not Completed: The system will prevent a closeout from being created against an agreement that has open/past due progress reports. This will be a hard stop for Open/past due reports identified by activities with a status other than Completed.

The following sections are present on the Closeout Create Screen:

Closeout Overview: This section captures all the changes requested to general agreement information. The section contains display only fields, representing pre-populated agreement data from the Agreement Screen.

Detailed Budget List: This section displays the Budget Item List from the agreement being closed out and specifies the agreement’s obligated amount and the open balance at the time of the closeout.

WBS Totals: This section displays the aggregate of the items referenced in the Detailed Budget List section along with the open balance for each combination listed.

Budget – Party Contribution: This section displays the Budget Party Contribution table from the agreement. The data is captured solely for information purpose.

Partners: This section captures all the Business Partners associated with the closeout which are identified from the corresponding agreement.



Notes: This section captures any notes made by the user. Upon saving the closeout, the notes captured in the Screen are saved in the closeout object. If the “Notes” field exists in the header, entering notes within the field automatically populates this section.

Attachments: This section is used to upload attachments during the closeout creation. The user is prompted to enter the “Type,” “Title” and “Date Received” information when uploading an attachment. Upon attaching documents in the form, the documents are uploaded and displayed under the Attachments section.

Transaction History: This section gives a precise historical analysis of all relevant business transactions associated with the closeout transaction.

Change History: This section allows the user to trace all changes made to a closeout transaction. Editing a Closeout

The agreement and closeout attachments section will only be editable by the AGMO while the closeout is in progress. The other sections of the Agreement screen will be read-only while the closeout is in Pending SO Closeout, Closed Pending FA or Closed status. When the agreement and closeout are in Closed status, the AGMO and Grants Specialist may add, but not delete, attachments to the Closeout and Agreement Screens. Closeout Approval Workflow

The approval process for the closeout begins once the Grants Specialist or AGMO submits the closeout to workflow. The status of the closeout changes to Pending SO Closeout, which notifies the respective Signatory Official to indicate their approval or rejection. Once the Signatory Official approves the closeout, the status changes to Closed Pending FA and notifies the respective Financial Approval. The Financial Approver is the final stage of the approval process where the closeout and agreement statuses are Closed, indicating the end of the agreement between the internal and external user. Below is an overview of the workflow “happy path” for a closeout. This table documents the user and the status change to move the closeout to the next step in the workflow:



Agency Signatory Official Routed for Approval to Closed Pending FA

Agency Financial Approver Closed Pending FA to Closed



Figure 17 illustrates the standard closeout approval workflow:

Figure 17: Closeout approval workflow diagram

The closeout workflow interacts with FMMI ECC in a critical way. When the closeout is fully approved, the Funds Commitment (Obligation) and preceding Funds Pre-Commitment are automatically set to completed. Any open balance funds for the Funds Commitment will return to the highest WBS level where the funds were originally stored. The funds are essentially “de-obligated,” shown above. Status Definitions


Pending SO Closeout: This status indicates that the Closeout has been successfully submitted for approval by the AGMO or GS and is awaiting SO (Signatory Official) approval. From this status, the agreement can only be changed to Active, Terminated or Closed Pending FA.

Closed Pending FA: This status indicates that the Closeout has been successfully submitted for approval by the SO and is awaiting FA (Financial Approver) approval. From this status, the agreement can only be changed to Closed.



Pending SO Closeout: This status indicates that the Closeout has been successfully submitted for approval by the AGMO or GS and is awaiting SO approval. From this status, the Closeout can only be changed to Rejected or Closed Pending FA.

Closed Pending FA: This status indicates that the Closeout has been successfully submitted for approval by the SO and is awaiting FA approval. From this status, the Closeout can only be changed to Closed.

Rejected: This status indicates that the Closeout has been rejected. From the Rejected status, the Closeout cannot be changed to any other status.

Closed: Once the closeout is closed, the interface between the Internal Portal (SAP CRM) and FMMI ECC is triggered, at which time adjustments to the Funds Commitment are automatically made.

To learn more about the Closeout Management process, refer to the Job Aids here:

Closeout Create Job Aid

Closeout Approve Job Aid



FFATA Reporting FFATA Report Internal users are required to provide a report on the financial assistance awards under the Federal Funding Accountability and Transparency Act (FFATA). The purpose of the report is to provide full disclosure on the respective agencies’ spending to the public. Creating a FFATA Report

FFATA Screen

To generate the FFATA Extract (form) in ezFedGrants, the designated user, with the proper access, will be provisioned the FFATA Extract tab on their home Screen. On the FFATA Extract, the user will select the agency’s Business Area code in the Agency Name field and include information on the date range on the selection Screen. Once the selection has been made, the user will be prompted to save the file locally. The output file will be in comma-separated-value (csv.) format. Each individual FFATA record is contained within a single row on the file. Once the report is generated and locally saved, the user will update those elements which are not stored in FMMI. Upon completion of updates by the agency, the FFATA extract will be uploaded to the NFC mainframe. The extract will select agreements and amendments that have entered Active status within the date range selected. The content of the FFATA extract includes a log of fully approved agreements their relevant administrative changes and amendments. All the required data is located within the Agreement Screen, Amendment Screen, and Recipient Business Partners Section. Workflow

The workflow for FFATA reporting begins in the FMMI Portal, where the user can input specific data on the report that they would like to run. Then, offline, they save the file locally, input manual components, and submit to the NFC Main Frame website. Figure 18 illustrates the standard FFATA workflow for running a report (the black boxes indicate steps done in the FMMI Portal; the blue boxes indicate steps done outside the FMMI Portal):

Figure 18: Running a FFATA report diagram

To learn more about running a FFATA report, refer to the Job Aid here:

FFATA Run report Job Aid



Sensitivity Review

Overview

The Sensitivity Reviewer (SR) is an internal role that has access to the ezFedGrants External Portal (Pega) and the ezFedGrants Internal Portal (SAP CRM). In the External Portal (Pega), the SR is mapped to the Grantor Evaluator role and has display-only access. In the Internal Portal (SAP CRM), the SR has display-only access to view agreements and amendments; s/he has a role in certain scenarios of the agreement and amendment approval workflows. Sensitivity Review for agreements

There are four dropdowns contained within the Project Details section of the Agreement Screen that can drive an alternate workflow: Politically Sensitive, Ceremonial, Precedent Setting, and International. If Politically Sensitive, Ceremonial, or Precedent Setting is checked, the agreement will have an extra approval step for the Sensitivity Reviewer. If International is checked, the agreement will have an extra approval step for the Program Reviewer. Both the Sensitivity Reviewer and the Program Reviewer are listed as partners in the Partners section on the Agreement Screen. Multiple checkboxes can be selected on an agreement, and if this is the case, then there will be a maximum of two additional approval steps during workflow. The Sensitivity Reviewer will receive a work item and an email. The AGMO(s) will receive a work item. If the status of the agreement is in Pending Review, this indicates that the agreement is awaiting approval from the Sensitivity Reviewer. The agreement will only enter this status if at least one of the following checkboxes is selected on the Project Details section of the agreement: Politically Sensitive, Precedent Setting, and Ceremonial. From Pending Review, the status can become Returned or Routed for Approval. The Sensitivity Reviewer (SR) can either approve or return the agreement. If the SR approves, then the agreement is in Routed for Approval status, and if they return, the agreement is in Returned status. Sensitivity Review for amendments

There are four fields contained within the New Value column of the Project Details section of the Amendment Screen that can impact workflow: “Politically Sensitive,” “Precedent Setting,” “Ceremonial,” and “International.” If “Politically Sensitive,” “Precedent Setting,” or “Ceremonial” is marked as “Yes,” the amendment will have an extra approval step for the Sensitivity Reviewer, if the amendment is abiding by Scenario 5, detailed in the amendment Section above. If “International” is marked as “Yes,” the amendment will have an extra approval step for the program Reviewer, if the workflow scenario constitutes that approval level. Multiple selections can be selected on an amendment, and if this is the case, then there will be a maximum of two additional approval steps during workflow if the workflow scenario constitutes that approval level. The user will be required to upload a Work Plan before submitting to workflow.

Supplementary Information



The following are common system errors in both the ezFedGrants External Portal and Internal Portal.

ezFedGrants External Portal (Pega) Common System Errors

Category System Error Methods to Resolve Error 1. Issues when

creating panels Missing Opportunity field or Panel

Name field

Missing Program Manager field

A Panel Manager or a Reviewer must be selected to create a panel

Ensure that program role requirements are met before creating a panel

Review the Reviewer Search Screen

accessible through the ezFedGrants External Portal (Pega) navigation bar to scan reviewers before creating a panel

2. Missing items when sending an object for approval

Missing Federal Agency Contacts (for Opportunities)

Missing funding requirements and Criteria (for ARP-relevant opportunities)

Missing attachments

Ensure that all required fields on the relevant screen are filled before moving to workflow

Have complete documents saved locally in order to easily upload them as attachments

3. Issues when saving

Missing fields such as Funding Opportunity Title, CFDA Number (for Opportunities)

Missing Program ID (for Opportunities)

Ensure that the object is successfully linked to a program

Ensure that all required fields are filled

4. Interface errors for agencies that utilize Grants.gov

When manually retrieving applications from Grants.gov into the ezFedGrants External Portal, no applications retrieve. In the page that is displayed after clicking the Retrieve Applications button, there is no

number after the “Retrieved Applications” header.

The user receives an error on the Opportunity Screen

The web service is down. The user should contact the relevant network administrator or try again to re-trigger the retrieval

The Award Floor must be greater than the Award Ceiling. When this is not the case, Grants.gov rejects the Opportunity Synopsis that is sent from the ezFedGrants External Portal

5. Issues when approving

During the final step of the application approval workflow, the user receives an error when approving

Confirm that the application – received from Grants.gov into the ezFedGrants External Portal – is tied to a recipient organization

Common System Errors



ezFedGrants Internal Portal (SAP CRM) Common System Errors

Category System Error Methods to Resolve Error 1. Financial

validations Obligation (Funds Commitment)

must be less than or equal to the Funds Pre-Commitment

The user cannot utilize expired funding without approval to bypass the error

The sum of all claims must be less than or equal to the Obligation (Funds Commitment)

Review ezFedGrants Funds Pre-Commitment Job Aids before creating the Funds Pre-Commitment

Review agreement and claim details before submitting to approval workflow

2. Missing items when sending an object (agreement, amendment, etc.) for approval

Missing fields

Missing attachments

Missing notes

Missing partners

Ensure that all required fields on the relevant screen are filled before moving to workflow

Have complete application and award package documents saved locally in order to easily upload them as attachments

3. Issues when creating transactions

The user attempting to create a transaction is not in the program

Attachments must be the correct file extension and within the size limitation

There is already an existing transaction in workflow

Reports are presently open and/or past due

Closeout creation issues

Ensure that all users are in the appropriate program before creating transactions

Confirm attachment file extensions and size before uploading

Confirm that before creating transactions (such as amendments or closeouts) that other critical transactions are not in process (reports, other amendments, etc.)

4. Issues when editing transactions

The transaction is not editable Ensure that the transaction is in an editable status for the user role

Ensure that the user is in the program of the transaction



For additional information and insight on the ezFedGrants Business Processes for APHIS, refer to the helpful links below.

ezFedGrants Training Library

Grants.gov Online Help

Additional Resources (in Progress)

http://www.grants.gov/help/html/help/index.htm?callingApp=custom#t=Get_Started%2FGet_Started.htm



Accenture POC

Question

Page

Client POC

Resolution

Danny Cohanpour Which client logo to use in the Header?

All

Open Questions