Functional Design

Printed: 12/16/15

Grants Workflow
FUNCTIONALDESIGNDOCUMENT
Release:

8.9

Product:

PeopleSoft Grants

Document Information
Document Participants
Author:

Yan Wu

Contributors:

Barry Hickson, Elise Koo

Reviewers:

Barry Hickson, Julie Gustafson, Elise Koo, Fei Lin, John Fitasimmons, Ashraf Morcos

Approvers:

Barry Hickson, Julie Gustafson, Ashraf Morcos

Revision History
Version Date
24-Jan-2004
17-FEB-2004
19-FEB-2004
25-FEB-2004
27-FEB-2004
05-MAR-2004
19-MAR-2004
08-ARP-2004
28-Jun-2004

298557766.doc

Change Summary
Initial Creation of FDD
Incorporate Barry Hicksons comment
Incorporate Barry Hicksons comment
Incorporate Barry Hicksons comment
Incorporate comments from review section
Incorporate comments from Ashraf Morcos. Changes in section 1.5, 2.1.12, 2.2.2.1
Add sample data
Incorporate comments from TDD review section
Incorporate new requirements/Changes from Sales; Creating a configurable/flexible workflow
rules for Grants Component approval process.

PeopleSoft Proprietary and Confidential

Functional Design

Printed: 12/16/15

Table of Contents
1. FEATURE OVERVIEW.........................................................................................................................................................4
1.1
PROBLEM/NEED STATEMENT.........................................................................................................................................4
1.2
HIGH LEVEL FEATURE DESCRIPTION.............................................................................................................................4
1.3 ASSUMPTIONS......................................................................................................................................................................4
1.3.1
Applications Installed..........................................................................................................................................4
1.3.2
Design Assumptions..............................................................................................................................................4
1.4 FEATURE DEPENDENCIES.....................................................................................................................................................5
1.5 SCOPE...................................................................................................................................................................................5
Features in scope..................................................................................................................................................................5
Features out of scope............................................................................................................................................................5
1.6 FEATURES FOR FUTURE RELEASES......................................................................................................................................5
1.7 DESIGN VALIDATION APPROACH.........................................................................................................................................5
1.8 RELATED DOCUMENTS.........................................................................................................................................................5
Requirement Source..............................................................................................................................................................5
Other Documents..................................................................................................................................................................6
1.9 GLOSSARY............................................................................................................................................................................6
2. FEATURE DETAIL................................................................................................................................................................7
2.1 CURRENT FUNCTIONALITY..................................................................................................................................................7
2.2 PROPOSED NEW FUNCTIONALITY........................................................................................................................................7
2.2.1 Common Workflow approval/notification setup component........................................................................................7
2.2.1.1 Approval/Notification Process definition/ Routing Roles................................................................................7
2.2.1.2 Approval Rules/Detail.....................................................................................................................................10
2.2.1.3 Approval Criteria.............................................................................................................................................11
2.2.2 Milestone due Notification.........................................................................................................................................14
2.2.2.1 Milestone Notification detail processes..........................................................................................................15
2.2.3
Proposal Status Notification...............................................................................................................................18
2.2.3.1 Proposal Status Notification detail processes..................................................................................................18
2.2.4
Proposal (Component) approval process............................................................................................................18
2.2.4.1 Proposal (Component) Approval Detail Processes...........................................................................................18
2.3 ROLES, USE CASES AND TASK ANALYSIS..........................................................................................................................26
2.4 WORKFLOW.......................................................................................................................................................................27
2.5 REPORTING.........................................................................................................................................................................27
2.6 ANALYTICS.........................................................................................................................................................................27
2.7 BATCH PROCESSING...........................................................................................................................................................27
2.8 GLOBAL/REGULATORY.......................................................................................................................................................27
2.9 MULTINATIONAL/INDEPENDENT BUSINESS UNIT...............................................................................................................27
2.10 INDUSTRY.........................................................................................................................................................................27
3. ADDITIONAL SPECIFICATIONS.....................................................................................................................................27
3.1 PEOPLESOFT PRODUCTS IMPACTED AND INTEGRATIONS REQUIRED.................................................................................27
3.2 THIRD PARTY INTEGRATION..............................................................................................................................................27
3.3 PERFORMANCE...................................................................................................................................................................27
Online performance............................................................................................................................................................27
Online usability metrics......................................................................................................................................................27
Batch performance..............................................................................................................................................................28
3.4 SECURITY SPECIFICATIONS................................................................................................................................................28
3.5 OTHER SPECIFICATIONS.....................................................................................................................................................28
4. OTHER CONSIDERATIONS.............................................................................................................................................28
4.1 SYSTEM TEST CONSIDERATIONS........................................................................................................................................28
4.2 SYSTEM DATA CONSIDERATIONS.......................................................................................................................................28
4.3 SAMPLE DATA CONSIDERATIONS.......................................................................................................................................29
4.4 SALES DEMO CONSIDERATIONS.........................................................................................................................................30
4.5 INFORMATION DEVELOPMENT CONSIDERATIONS..............................................................................................................30
4.6 UPGRADE/CONVERSION CONSIDERATIONS........................................................................................................................30
4.7 INSTALL CONSIDERATIONS.................................................................................................................................................30
5. MISCELLANEOUS..............................................................................................................................................................30
298557766.doc

PeopleSoft Proprietary and Confidential

Functional Design

Printed: 12/16/15

5.1 GAPS IN PEOPLETOOLS FUNCTIONALITY...........................................................................................................................30

5.2 OTHER NOTES....................................................................................................................................................................30
6. OPEN ISSUES.......................................................................................................................................................................30

298557766.doc

PeopleSoft Proprietary and Confidential

Functional Design

Printed: 12/16/15

1. Feature Overview
1.1 Problem/Need Statement
There is a need to provide a workflow solution that can support the business process of submitting, reviewing and
approving Proposal components with Grants. This workflow solution is intended to help in managing the Grants
Proposal approval process through its life cycle. In addition, we are looking to provide users the ability to
determine more efficiently when milestones are due and to send out notification to the appropriate person(s) as
needed.

1.2 High Level Feature Description

Grants Workflow Feature will comprise of the following:
I. Provide efficient communications between the different project roles (PI, SPO, administrator,
stakeholder, etc.) through all aspects of the proposals life cycle. This is achieved via the creation of a
workflow process using worklists and email notifications.
II. Provide the ability to select (query) milestone(s), which will be due in the near future and to send out an
email notification as needed. Users can also set up a process scheduler to run this process periodically.
III. Customer configuration options which allow them to control properties/routing of the proposal approval
process
IV. Common Approval configuration setup within a Grants Application

1.3 Assumptions
1.3.1 Applications Installed

This FDD assumes that a customer has purchased and installed the PeopleSoft Grants application.

1.3.2 Design Assumptions

298557766.doc

Using Peopletool delivered standard workflow solutions.

PeopleSoft Proprietary and Confidential

Functional Design

Printed: 12/16/15

1.4 Feature Dependencies

1.4.1

Construction of Grants Proposal

Enhancements to Grants Application in order to support/develop/implement Grants workflow
Ability to establish Grants proposal level component(s) must be implemented in order
to develop/implement Grants workflow.
Ability to associate an Institution, Major Subdivision, SPO office, Department Admin,
Department Chairman, Department Represent to a department and automatically
populate this information during Proposal Creation process.
Ability to identify a personal Workflow Eligibility
Ability to calculate and display total amount for each Proposal and Project in Maintain
Proposal component.
Ability to associate default stakeholder(s) to each component; user also will be able to
input multiple stakeholders for each component.

1.4.2

Proposal Status
Current Proposal Status needs to work in tandem with the new workflow process. In order to
implement workflow, a clearly defined proposal cycle/status is needed.

1.5 Scope
Features in scope
PT-100

Milestone Email Notification

PT-200

Milestone Email Notification Process Scheduler

PT-300

Proposal Status updates Email notifications

PT-400

Proposal (Component) Approval Process

PT-500

Approval Process at Proposal/Primary Project

Components and Project Components

PT-600

Flexable/Common Workflow Rules setup at BU level

Features out of scope

PT-700

No external notification

1.6 Features for Future Releases

1.7 Design Validation Approach
The design will be validated by internal reviews with ESA Strategists, Product Development Managers, Product
Architects, and Developers. The intent is to have ESA Sales Support review the design as well. Design prototypes
will be built and reviewed by the Usability group.

1.8 Related Documents

Requirement Source
Location
298557766.doc

Document ID

BRD #

Description

PeopleSoft Proprietary and Confidential

Owner
5

Functional Design

Printed: 12/16/15

Other Documents
Location

Document ID

Description

1.9 Glossary
Term

Definition

298557766.doc

PeopleSoft Proprietary and Confidential

Functional Design

Printed: 12/16/15

2. Feature Detail
2.1 Current Functionality
Workflow is not present within existing Grants releases.

2.2 Proposed New Functionality

The Proposed new functionality will establish an approval/notification structure, which allows the customer to manage
their approval process more efficiently. The detail of this design document will support the capabilities outlined below:
Functions/Processes
Common component to set up
Workflow
Approval/Notification Process
for all Grants Workflow
solutions
Milestone due Notification
Proposal status Notification
Proposal (Component)
approval process

Workflow

Description
Define a common workflow setup component which provides a
single user interface for configuring / structuring all Grants
workflow processes and Rules.

Email
Notification
Only
Email
Notification
Only
Worklist/Email
Notification

Sending reminder email notifications to group of roles (people)

prior to milestone due date
Sending informational email notification to group of roles
(people) when Proposal status is changed.
Generates worklist/notification requesting for approval/review
of a proposal/project.

2.2.1 Common Workflow approval/notification setup component

Grants will be providing 5 workflow solutions in the 8.9 release. A common workflow approval/Notification
setup component will provide with a single user interface for configuring/structuring all Grants workflow
solutions. Users will define their Approval/Notification Processes at the Business unit level. This setup
component contains following sections:
Approval/Notification Process definition
Routing Roles
Approval Rules/Detail
Approval Criteria
2.2.1.1 Approval/Notification Process definition/ Routing Roles

298557766.doc

PeopleSoft Proprietary and Confidential

Functional Design

Printed: 12/16/15

298557766.doc

Business Unit Contact /Award Business unit

Transaction Type Grants provides 5 workflow solutions. We define a transaction type for each
workflow solution.
o Proposal Component Approval
o Milestone Notification
o Proposal Notification
o Protocol Approval Process (See detail in FDD for Protocol Management)
o Protocol Committees meeting Notification (See detail in FDD for Protocol Management)
Workflow Type Type of workflow function provide by the workflow transaction
o Proposal Component Approval Worklist/Email notification
o Milestone Notification Email Notifications only
o Proposal Notification Email Notification only
Elements Indicate what is the key element for the workflow.
o Proposal Component Approval Component
o Milestone Notification Milestone
o Proposal Notification Proposal Status
Detail A secondary page where user defines the detail information related to the current element
(see detail in later section)
Criteria A secondary page where user defines the Criteria for the approval process. In this
secondary page users specify the conditions for requiring current element as part of approval process.
(See detail in later section)
Routing Rules Indicating who will be involved and what kind of action they can perform.
o Role list of available roles. These are user-defined roles. Requires one or more roles. List
of roles involve in each Transaction type maybe little different. Following are list of roles
involve in Proposal (Component) approval and Proposal Status Notification.

PeopleSoft Proprietary and Confidential

Functional Design

Printed: 12/16/15

298557766.doc

Roles involving Milestone notifications are Award PI and Milestone Contact(s)

Required User will be required to perform actions on the task and feedback from them
will affect the approval status. If a role is set as required, worklist must be generated for this
role. Required at least one Required approval role. This field is applied to workflow type
Worklist/Email only.
Perform Action Type of action that will be performed by the role of user. This field is
applied to workflow type Worklist/Email only.
Approve
Review
Workflow Action Type of workflow that will be generated/Type of workflow user will be
receiving. This field applies to workflow type Worklist/Email only.
Worklist/Email
Worklist only
Email Notification Only
Sequence Order receiving the workflow. It can be setup where all roles will receive the
workflow simultaneously or sequentially or a combination of both. This field applies to
workflow type Worklist/Email only. For example:

PeopleSoft Proprietary and Confidential

Functional Design

Printed: 12/16/15

In this case, Role Administrator and Co-PI will receive the workflow simultaneously.
Department head will receive the workflow after Administrator approves the workitem,
which is sequentially. This field applies to workflow type Worklist/Email only.
Pool List If this option is set then only one person from this role needs to perform an
action and the workitem will be dropped from others. This field applies to workflow type
Worklist/Email only. Example: if 3 people are assigned as Co-PI, 3 workitem will be
generated and inserted to their worklist. As long as one Co-PI approves the component, the
workitem will be dropped from the others worklist.
Reassign check if workitem can be reassigned. This field is applied to workflow type
Worklist/Email only

2.2.1.2 Approval Rules/Detail

For each workflow solution, we will provide a detail section, which only includes the information that
specific to its workflow process. User comes to this detail page by clicking on the Detail hyperlink.
Functions/Processes
Milestone due
Notification

Workflow
Email
Notification
Only

Approval Rules/Detail

o
o
Proposal status
Notification

Email
Notification
Only

298557766.doc

Days Prior to Due Date Number of days that user will need to
be notified prior to milestone due day.
Notification Text Comments that user would like to see on the
email notification.

Notification Text Comments that user would like to see on the

email notification.

PeopleSoft Proprietary and Confidential

10

Functional Design

Proposal
(Component)
approval process

Printed: 12/16/15

Worklist/Email
Notification

.
o
o
o
o

Required Approval Process Check this option if this component

is required for all proposals within current BU.
Notify When Status Changed Check this options if user wants
to receive an email notification when component status is
changed.
Self Approval if this option is checked then workitem will
consider as approved immediately if workitem generator and
receiver is the same person.
Approval Initiator Role Group of people that manage/monitor
the approval process. This group of people will be responsible for
resubmitting the component in case of send back(component
sent back for modification by approver). Note: It is very
important to identify this role; they are the people who can edit
project/budget in case of Send Back. Project/Budget will be
displayed only for others during the approval process.
Exception Approver ID He/she acts as exception Approver in
case we could not find the approver.

2.2.1.3 Approval Criteria

This section only applies to Proposal (Component) approval workflow process. User defines the criteria that
are required for requiring a component approval. Component will be inserted into the proposal automatically if all
criteria are satisfied.

298557766.doc

PeopleSoft Proprietary and Confidential

11

Functional Design

Printed: 12/16/15

Condition ID This is a system-generated value. User can set up one or more conditions for each
criterion.
o A criterion is considered as true if any condition is met. Current component will be inserted to
the Proposal and be part of required approval path.
o Component will be removed from proposal if user updates the proposal and Condition is no
longer met.
o All values within a condition must be satisfied in order to consider the condition met.
Component Name Criteria editing process will be triggered in 3 peopletool components:
GM_PROPOSAL, GM_BUD_HEADER and GM_BUD_LINE_SUM.
Monetary Criteria User can select an amount field and identify the amount limit in a specific
currency code and exchange rate as part of the condition.
o Amount Record Depending on the peopletool component, user will prompt/select a record
that is available within the current peopletool component. We deliver this information as
system data.

298557766.doc

PeopleSoft Proprietary and Confidential

12

Functional Design

Printed: 12/16/15

Note. Please Use following instruction to define system data. Set Up Financials/Supply Chain
Product Related Grants Workflow Component
Component name = GM_PROPOSAL, GM_BUD_HEADER and GM_BUD_LINES_SUM

298557766.doc

PeopleSoft Proprietary and Confidential

13

Functional Design

298557766.doc

Printed: 12/16/15

o
o

Amount Field Select a field that is in number/Amount format within the amount record
Currency Field A field that contains the currency code. For example
GM_PROPOSAL.CURRENCY_CD

o
o
o
o

Criteria Operation -Amount: -- Identify the amount limit

Currency Code The currency code for Amount. Example: USD
Exchange Rate type Currency conversion will be performed if amount filed is in different
Currency Code.

PeopleSoft Proprietary and Confidential

14

Functional Design

Printed: 12/16/15

Other Criteria User can also define other non-amount criteria.

o Record Name Identify the record name
o Field Name Identify the filed name

o
o

Operator
Value Value of the filed

2.2.2 Milestone due Notification

Summary of 8.9 Milestone notifications Functionality:
1. Users will be able to use run control searching of the milestones periodically to determine those that
satisfy the search conditions. The result will be a list of award milestone(s) being returned. Users will
then be able to trigger email notifications from the list. Email notification can be sent out for all or
only select award milestone(s).
2. Users also can set up a process scheduler to search milestones that are due on the current date and
send out email notifications automatically
The existing award milestone page will be modified to incorporate this new functionality. We will
keep track of the entire notification history. Users will be able to find all history from the Grants
Award --> page Milestone.

298557766.doc

PeopleSoft Proprietary and Confidential

15

Functional Design

Printed: 12/16/15

2.2.2.1 Milestone Notification detail processes

A new milestone run control page will be created. Users can use this run control page to find out
a specific milestone(s) that satisfies certain conditions and decide if they would like to send out
an email notification to the appropriate person(s).
They can also use this page to view completed milestones but no action will be performed for
these completed milestones. Notify check box will be displayed only for completed milestones

298557766.doc

1.

Run control parameter(s)

Business Unit
Milestone type
Milestone Code
Priority (New field added to Proposal Milestone record)
Milestone Due Date From
Milestone Due Date To
Notification Due in days Milestone notification that is due within specific
days. Notification Due Date = Milestone due date Days prior to due date
Last Notification Date From
Last Notification Date to
Milestone Completed From
Milestone Completed To

2.

Return a list (Grid) of milestones that satisfies the search parameter. The list includes
the following fields
Notify Check box
Award ID -- hyperlink
Milestone type -- Display only
Milestone Code Display only
Priority Display only
Milestone Due date Display only
Last Notification Date Display only
Comments Long text (Populated with default value in field Comment from
Milestone setup page)
Note: Users can select to send an individual milestone notification or can select
Notify all uncompleted Milestones to send out multiple milestone
notifications

3.

Milestone Run Control Page

PeopleSoft Proprietary and Confidential

16

Functional Design

Printed: 12/16/15

New Milestone Run Control page:

298557766.doc

PeopleSoft Proprietary and Confidential

17

Functional Design

Printed: 12/16/15

4.
5.

298557766.doc

Milestone Notification Activity A business event will be trigger sending out the email
notification to people who are listed as receiver in the BU workflow set for Milestone
Due notification.
Milestone Notification Message
Subject Milestone (value) is due on (Due date)
Note text -- Milestone (value) is due on (Due date). Please take appropriate
actions to complete this task. Click on the following Link for Detail
information (URL Link)

6.

Running milestone notification from Process scheduler

Users can set up a process scheduler and run milestone notifications automatically. A
program is run searching for the milestones that are due on the current date and sends
out email notification automatically. The parameters for running this program comes
from the Millstone setup page:
Business Unit
Milestone Type

7.

Milestone Notification history

Maintains Milestone Notification History Users will be able to access this
information in the Award Milestone page, which includes the following information:
Notify On
From
To
Comment

PeopleSoft Proprietary and Confidential

18

Functional Design

Printed: 12/16/15

Milestone Notification History page:

Modified Award Milestone Page:

)
298557766.doc

PeopleSoft Proprietary and Confidential

19

Functional Design

Printed: 12/16/15

2.2.3 Proposal Status Notification

Summary of Proposal Status Notification Functionalities:
Provide a flexible email notification system that will be triggered when the proposal status is changed.
2.2.3.1 Proposal Status Notification detail processes
If the proposal status is changed and status is listed in the common workflow setup page, then an email
notification will be generated to the roles/person(s) listed in the workflow setup page.
o Proposal Status Notification Activity A business event will be trigger sending out the email
notification to people who are listed as receiver in the Common workflow set for Proposal
Status notification.
o Notification Message
Subject Proposal (value) Status is Updated from (value) to (value)
Note text -- Proposal (value) Status is updated from (value) to (value). Click on the
following Link for Detail information (URL Link)
o Notification History
No History will be maintained for this transaction

2.2.4 Proposal (Component) approval process

Summary of Proposal (Component) Approval Functionalities:
Provide an efficient workflow solution that supports the business process of submitting, reviewing and
approving Grants Proposal at the proposal/Primary Project component or project component level (mutually
exclusive). We will achieve this functionality by creating workitems and Email notifications.
2.2.4.1 Proposal (Component) Approval Detail Processes
1. Adding new page (identify Setup Level) to existing Grants Contract BU setup Component.
User will use the setup page to identify the approval level. Proposal (Component) approval can
be set at:
Proposal/Primary Project Level Only workflow the components that are listed in
Primary Project
Project Level
If user selects Primary Project, then only workflow the components that are listed in the
primary project, otherwise workflow all components that listed in all projects. This option
can be overwritten in Grants Proposal.
If user selects Primary Project but still enters components in non-primary project, user will
receive a warning message, which clearly explains that the component in the non-primary
project will not be part of the workflow approval process. If they want to have an
approval process for non-primary project component, they need to change the proposal
component level option in current proposal.

298557766.doc

PeopleSoft Proprietary and Confidential

20

Functional Design

Printed: 12/16/15

New page to identify Setup Level:

2.

298557766.doc

Active/inactive Proposal (Component) workflow process at BU level.

User can active/inactive Proposal (component) approval process by enter or delete the value in
field Proposal status in the Grants Award setup Definition page. When the proposals status
changes to the status that is listed in Grants Award setup Definition page, an approval process
will be triggered, sending workitem/email notification for multi-layer(s) approval.

PeopleSoft Proprietary and Confidential

21

Functional Design

Printed: 12/16/15

3.

298557766.doc

Proposal Component can be added to Proposal pragmatically or manually

Proposal Component will be added/deleted to each Project programmatically
depending on the criterion that was set up in the Common Workflow
approval/notification Setup section. Component will be added to the
Proposal/Project if the criteria is true or deleted if proposal/project/budget is updated
and criteria is no longer true.
User can not delete any Proposal component that is added programmatically
Can not delete any None- Draft Proposal Component
User can also add Proposal Component(s) manually if they wish to have additional
approval process. This Proposal Component(s) can be deleted as long as it is in
Draft status.

PeopleSoft Proprietary and Confidential

22

Functional Design

Printed: 12/16/15

298557766.doc

Proposal Status -- Display only if Proposal (Component)

approval process is active
Proposal Status Date -- Display only field
Required Flag Proposal will consider Approved if all
Required Components are Approved. This is a display only
field and value come from Component setup.
Stakeholders User can enter multiple stakeholders for each
Proposal Component

Approval Hierarchy -- User can view all the roles that involve in
approval process by clicking on this hyperlink. All information in
this page is display only (cannot be modified). Information
shown in this page is viewed from Common Workflow
approval/notification Setup Page.

PeopleSoft Proprietary and Confidential

23

Functional Design

Printed: 12/16/15

Approval History User can view the current approval process and its
history by clicking on this hyperlink.

Submit/Resubmit This button will be active when:

1. Component Status = Send back and the current user has role of
Approver Initiator.
2. Ccomponents that is added after the approval workflow started.
Associate Approval (Routing) Roles with Approver/Reviewer
User will define the Routing Role(s) for Proposal (Component) Approval process
routing roles in the BU level and can be viewed the in the
Proposal/Component/Approval Hierarchy page.
User will associate Approval Roles to a individual emplid in Proposal/Project
Resource page:

4.

298557766.doc

PeopleSoft Proprietary and Confidential

24

Functional Design

Printed: 12/16/15

5.

298557766.doc

An emplid must be workflow eligible to receive a workitem. If you

do not wish to be part of approval process, user can uncheck
Workflow Eligible. This option can be set at Professional Data
page and defaults to the Proposal/Project Professional Grid.
User can pre-define contact(s) for each department in Department
Set up page and will be brought into Proposal Project Professional
grid automatically. User will also be able to associate Department
with Major Subdivision, Institution, SPO office and Location in
Department setup page
Approval Rules/Processes:
Proposal (Component) Approval process will be triggered when the proposals status
changes to a status that is listed in Grants Award setup Definition page. All people
involved in the approval process will receive workitem, email notification or both
depending on the setup options (see detail in section: Common Workflow
approval/notification setup component). Note: Following Peopletool Component/pages
will be un-editable during approval process: Maintain Proposal, Overall Budget and
Budget Detail.
Approval process can be simultaneous or sequential depending on setup. If approval
process is set to sequential, workitem will be generated for next layer of approver after
receiving approval from all Required approver(s)/Review(s). Feedback from nonrequired approver(s) will not affect the approval process/status. E.g.: If all required
approver(s) approved the component but not the non-required approver, Component status
will still be updated to Approved or workitem will be generated for next layer of
approver.
All Required Approval Roles must be defined in the Proposal/Project/Professional
resource grid and set to workflow eligible. User can find our which role is required by
clicking on the hyperlink Approval Hierarchy in Component page.
Only the Workflow Eligible emplid will receive a workitem.
Approver/Reviewer will receive Workitem, email notification or both during approval
process. Here is the list of action can be taken depending on the workflow setup.
o Approve
o Send Back
o Review
o Reassign (new approver/reviewer will have same authorities as original
approver/reviewer)
Component Status:
o Draft
PeopleSoft Proprietary and Confidential

25

Functional Design

Printed: 12/16/15

298557766.doc

o In Progress
o Approved/Reviewed
o Send Back
Component Status will update to In Progress when Workitem is sent out to the approver
and waiting for action to be taken by the approver.
Component Status will be Approved if all required approver(s)/reviewer(s)
approve/review the component
Component Status will be Send Back if any of required approver Send Back the
Component for modification and workitem will be generated for Approver Initiator.
o Project/Budget will be editable by approver initiator only when Component
status = Send Back
o If Component Approval level is set at Project then only the Project that is
associate with the Send back component can be editable.
o If component Approval level is set at Proposal then all Project(s) are editable by
the approver initiator.
o Proposal Remains un-editable during approval cycle.
o During the process of modification (By Approver Initiator), New Proposal
Component can be added/Deleted in the Project if meet some criteria or if the
criteria no longer met
Proposal can be Canceled during the approval process. All workitem will be removed
from approver worklist.
Proposal is Approved if all Component(s) are approved.
Approved/Canceled Proposals are not editable. It is the end of Proposal process.
Workflow Process Flow:

Proposal Component Approval Activities:

1. Workitem will be generated for Approver/Review when Proposal Component is
submitted for Approval.
2. Workitem will be generated for Approver Initiator when Proposal Component is sent
back by Approver
3. Workitem will be generated for new Approver/Reviewer when Proposal Component is
reassigned by Approver/Reviewer
4. Email notification to all people who are involved with approval process when Proposal
Component status is changed
Proposal Component Approval/Review/Submit Page:
Clicking on the Workitem from the worklist will bring user to an
approval/Review/Submit page. In the approval page, user can approve all the
component(s) that are currently assigned to him/her within a Proposal/Version. User
can also come to this page though the left navigation (Proposal Proposal Component
Approval)

PeopleSoft Proprietary and Confidential

26

Functional Design

Printed: 12/16/15

Note: Depending on users authority/role, different check box(s) will be editable in this
page. E.g.: If the user is assigned to perform Approve action, he/she will see
Approve/Send Back check box active. All others will be display only. User can also use
this page to resubmit component for approval in case of Send Back
Proposal Component Notification Message:
An email notification will be generated and sent to everyone that is involved in the
approval/review process (see detail in section Common Workflow
approval/notification setup component).
Subject Proposal Component (value) is ready for Approval
Note text Proposal l Component (Value) is ready for approval by
Stakeholder (value). Click on the following Link for Detail information
(URL Link)

Grants Proposal Statuses When workflow is enabled, the proposal statuses will
have to follow the deplicted flow. See diagram below.

From Draft, user will manually change to Pending Approval which will then trigger the
workflow process. Denied by Institution can be changed by the user, however,
Institution Approved must be changed by system in the workflow approval process.
Once approved, user can change the status to Submitted. Only Submitted proposals
will be allowed to be generated, at which time the system will change the status to
Awarded.
All other statuses can be selected prior to submission. If workflow is disabled, status
functionality is unchanged from 8.8. User can select any/all statuses at any time prior to
submission.
The superuser has authorization to change a Submitted (but ungenerated) proposal back
to Not Submitted. If workflow was enabled, the proposal status will go back to
Institution Approved. If workflow was disabled, the proposal status will go back to
Draft, as is current functionality in 8.8.

298557766.doc

PeopleSoft Proprietary and Confidential

27

Functional Design

Printed: 12/16/15

2.3 Roles, Use Cases and Task Analysis

The following is a listing of Roles that will interact with Grants Workflow to some capacity.
Proposal PI
Creates, maintains and approve Grants Proposal
SPO Contact - SPO office Contact
Milestone Contact
Milestone Contact personnel
Stakeholder
Responsible for Approving/Denying a Proposal/Project component
Task Analysis:
The following section will expand the Use Cases that were introduced in the Business Requirements document (Grants
Workflow document ID XXXXX) into system specific details based on the design described in Section 2.2.3
1. Update Proposal Status (no corresponding BRD Use Case)
Actors
Proposal PI
Summary
A user wants to know when proposal status is updated
Path
1. An authorized user navigates to Grants Maintain Proposal,
2. Select a specific page.
3. User updates some information in the proposal and updates the status
System Rules
1. Proposal PI would like to know when the proposal they maintain is changed to
ensure Proposal is setup the way they envision
1. When a Proposal status is changed, People who are involved in this proposal will
receive an email notification so they have a chance to go into the system and review
the recent changes
2.

Component Approval Process (BRD Use Cases 1, 2, & 3)

Actors
Summary
Path

System Rules

Proposal PI, Proposal Sponsor and Stakeholder

A Proposal is ready for approval by component Stakeholder
1. User navigates Grants Maintain Proposal Search
2. PI updates the proposal status from Draft to Pending Approval
3. Workflow process kicks off when PI saves the Proposal
4. Component Stakeholder(s) receive Workitem/Email notification request for approval
5. All Components(s) are approved by stakeholder(s).
1. All components must be approved in order to update the proposal to Approved.
2. Once a component is approved, it remains approved during the whole Proposal
cycle.
3. A Send back component can be submitted again for approval

2.4 Workflow
See detail in this FDD documents.

2.5 Reporting
No requirements identified at this time.

2.6 Analytics
No requirements identified at this time.

298557766.doc

PeopleSoft Proprietary and Confidential

28

Functional Design

Printed: 12/16/15

2.7 Batch Processing

No requirements identified at this time.

2.8 Global/Regulatory
No requirements identified at this time.

2.9 Multinational/Independent Business Unit

No requirements identified at this time.

2.10 Industry
No requirements identified at this time.

3. Additional Specifications
3.1 PeopleSoft Products Impacted and Integrations Required
No requirements identified at this time.

3.2 Third Party Integration

No requirements identified at this time

3.3 Performance
Online performance
Meet Peoplesoft performance standard

Online usability metrics

No requirements identified at this time.

Batch performance
No requirements identified at this time.

3.4 Security Specifications

No security for Workflow

Peoplesoft standard page security
Grants Security

3.5 Other Specifications

No requirements identified at this time.

4. Other Considerations
4.1 System Test Considerations
This section highlights some areas that should be focused on for Grants Workflow.
Feature

Test Emphasis

2.1.1.2 Milestone Notification

Grants > Interactive Report > Milestone Notification > Run Control

298557766.doc

Fill update run control parameters Business unit, Milestone Type, Milestone Code, Days
Prior to Due date
Click on Search button
A list of milestones will be returned in the grid
PeopleSoft Proprietary and Confidential

29

Functional Design

Feature

Printed: 12/16/15

Test Emphasis

2.2.1.2 Proposal Workflow

Click Notify All

Put some comments to the comment box
Click Save
Send email notification to award PI, sponsor and milestone contact

Grants Maintain Proposal > Select an existing Proposal

Update the Proposal Status from Draft to Pending Approval

Click Save
Notify Proposal PI, Sponsor that proposal status is updated (email notification)
Component Stakeholder receives Workitem/email notification requesting for approval
Stakeholder accesses the approval page from his/her worklist
Stakeholder approves the component
All components are approved
Proposal status updated to Approved

4.2 System Data Considerations

No special requirements at this time.

298557766.doc

PeopleSoft Proprietary and Confidential

30

Functional Design

Printed: 12/16/15

4.3 Sample Data Considerations

See above sections for more details.
Milestone Priority

Component Approval Roles

PI, Admin, SPO, stakeholder, Authorized, CO-Mentor, COPI, Dept.Head, Key Personal, Mentor, Other

298557766.doc

PeopleSoft Proprietary and Confidential

31

Functional Design

Printed: 12/16/15

4.4 Sales Demo Considerations

Create at least two Proposals with at least two component(s). Create at least two milestone(s) that are due in
the near future
Scenario:
o Update Proposal status to trigger email notification and workitem
o Run milestone report, send milestone email notification

4.5 Information Development Considerations

Clearly defined Proposal Status and rules on who can update status.

4.6 Upgrade/Conversion Considerations

No special requirements at this time.

4.7 Install Considerations

No special requirements at this time.

5. Miscellaneous
5.1 Gaps in PeopleTools Functionality
5.2 Other Notes

6. Open Issues

298557766.doc

PeopleSoft Proprietary and Confidential

32