**Functional Specification**

Project: SF-182

Version: 4.00

Date: June 1, 2007

Status: Final Draft for Review

Author: Ashutosh Pavaskar

**PROPRIETARY AND CONFIDENTIAL TO SABA\
FOR INTERNAL USE ONLY**

**Table of Contents**

[1 Introduction 4](#introduction)

[1.1 Purpose and References 4](#purpose-and-references)

[1.2 Audience 4](#audience)

[1.3 Assumptions 4](#assumptions)

[2 Business Requirement and Justification
5](#business-requirement-and-justification)

[2.1 Definitions 5](#definitions)

[2.2 Background/Context 6](#backgroundcontext)

[2.2.1 Core Assumptions 6](#core-assumptions)

[2.2.2 Functional Overview 6](#functional-overview)

[3 Detailed Use Case Specifications
16](#detailed-use-case-specifications)

[4 Enterprise characteristics and other requirements
17](#enterprise-characteristics-and-other-requirements)

[4.1 Notification Requirements 17](#notification-requirements)

[4.1.1 Triggered Notifications 17](#triggered-notifications)

[4.1.2 Periodic Notifications 18](#periodic-notifications)

[4.2 Performance and Scalability Requirements
18](#performance-and-scalability-requirements)

[4.3 Volume Requirements 19](#volume-requirements)

[4.4 Integration Requirements 19](#integration-requirements)

[4.5 Upgrade Requirements 19](#upgrade-requirements)

[4.6 Migration Requirements 19](#migration-requirements)

[4.7 Report Requirements 19](#report-requirements)

[4.8 Installation Requirements 19](#installation-requirements)

[4.9 I18n and l10n Requirements 19](#i18n-and-l10n-requirements)

[4.10 Auditing and E-Signature Requirements
19](#auditing-and-e-signature-requirements)

[4.11 Security Requirements 20](#security-requirements)

[4.12 Business Rule Requirements 20](#business-rule-requirements)

[4.13 Portlet Requirements 20](#portlet-requirements)

[4.14 "Saba Where You Work" Requirements
20](#saba-where-you-work-requirements)

[5 Testing 21](#testing)

[5.1 Unit Testing 21](#unit-testing)

[5.2 Integration Testing 21](#integration-testing)

[5.3 Feature Testing 21](#feature-testing)

[6 Future Enhancements 22](#future-enhancements)

[7 Out Of Scope 23](#out-of-scope)

[8 Documentation 24](#documentation)

[9 Tracking feedback and Issues 25](#tracking-feedback-and-issues)

[9.1 Open Issues 25](#open-issues)

[9.1.1 Request is submitted and the user has no approval chain
25](#request-is-submitted-and-the-user-has-no-approval-chain)

[9.1.2 Request is submitted to an inactive approver.
25](#request-is-submitted-to-an-inactive-approver.)

[9.1.3 Approval chain related issues 25](#approval-chain-related-issues)

[9.1.4 New privilege to be added in the system
25](#new-privilege-to-be-added-in-the-system)

[9.1.5 State of request submitted for approval
26](#state-of-request-submitted-for-approval)

[9.1.6 Final Owner of the request 26](#final-owner-of-the-request)

[9.1.7 Definition of Agency code 26](#definition-of-agency-code)

[9.1.8 Relationship for approvers 26](#relationship-for-approvers)

[9.1.9 Approval chain on the form 26](#approval-chain-on-the-form)

[9.1.10 Default approver in the system
26](#default-approver-in-the-system)

[9.1.11 Open issues from the PRD 26](#open-issues-from-the-prd)

[9.2 Closed Issues 27](#closed-issues)

[9.2.1 Request is submitted and the user has no approval chain
27](#request-is-submitted-and-the-user-has-no-approval-chain-1)

[9.2.2 Request is submitted to an approver who is no longer active in
the system
27](#request-is-submitted-to-an-approver-who-is-no-longer-active-in-the-system)

[9.2.3 Approval chain related issues
27](#approval-chain-related-issues-1)

[9.2.4 New privilege to be added in the system
27](#new-privilege-to-be-added-in-the-system-1)

[9.2.5 Define mandatory/optional fields on the form
27](#define-mandatoryoptional-fields-on-the-form)

[10 Change Log 28](#change-log)

[11 Document Sign-Off 29](#document-sign-off)

# Introduction

## Purpose and References

The purpose of the document is to summarize the feature enhancements
planned to introduce external learning requests with multi-level
approvals capabilities in Saba. The form to be utilized for approval
will be the SF-182 form.

## Audience

The audience of this functional specification includes the following
teams:

Product Management, Quality Engineering, User Experience and
Documentation.

## Assumptions

This document assumes familiarity with Learning requests and transcripts
functionality within Saba.

# Business Requirement and Justification

## Definitions

1.  **Learning Request:** The request that the learner will create for
    learning. Learning Request involve submitting Forms (see below) for
    approval.

    i.  **Catalog Learning Request -** If the request is for a learning
        within Saba Catalog it will be referred as "Catalog Learning
        Request"

        a.  **Public Learning Request --** is a type of form used to
            request that an Offering be scheduled where enrollment is
            open to the public. A Public Learning Request is a type of
            Catalog Learning Request.

        b.  **Private Learning Request --** is a form used to request
            that an Offering be scheduled where enrollment is NOT open
            to the public. A Private Learning Request is a type of
            Catalog Learning Request.

    ii. **External Learning Request** - requests outside the Saba
        Catalog it will be referred as "External Learning Request". This
        document deals with "External Training Request" alone and will
        be referred as "Learning Request" or "Request".

2.  **Form:** The document that gets attached with the submitted
    request.

    i.  **SF-182** -- SF-182 is a type of Form use for training
        approvals by US Federal Government. SF-182 can be used for
        either Catalog Learning Requests or External Learning Requests.

> **Note**: Saba Catalog Learning Requests use Saba web-forms.

3.  **Request Owner:** The person in the Saba application to whom the
    request is assigned for further processing/action.

4.  **Request Admin:** The Saba user having the privilege to
    create/modify requests and request definitions.

5.  **Request Submitter:** Also referred to as the "Learner", this is
    the user who submits a Request for approval.

6.  **Approval Chain:** An approval chain is a grouping of users
    (identified via approver types, see below) that must sequentially
    review and approve a form.

7.  **Approvers / Approver Types:** The following types of approvers
    that can be included in an approval chain.

    i.  **RELATIONSHIP**:  Such as "Manager" or "Second line Manager" or
        a custom role like "Military Supervisor".  If the approval chain
        is defined in this fashion, the approvers would be picked up
        from the learners profile.

    ii. **PERSON**: In this case the admin can assign a specific person
        as a approver for a particular level. Once this person is
        assigned as the approver at that level, all the requests will be
        forwarded to that user for approval.

## Background/Context 

The Federal Civilian government requires the processing of a specific
standard form called the SF-182 to manage requests for training outside
the scope of an organization's training department. The process also
tracks the cost of the training in 4 specific categories and allows for
final approval from an accounting source.

Similarly, other agencies have created new versions on the form like
DD-1556 for the army, NF 1736 for NASA. This document focuses to capture
the data elements and produce the SF-182 form request.

### Core Assumptions 

The design detailed in this document is built on the following
assumptions:

-   The on-line design of the SF-182 form and approval process will
    mirror the SF-182 form and requirements based on form NSN
    7540-01-088-3901, revised December 2006.

-   Because the SF-182 form is subject to change periodically and is
    also subject to interpretation across agencies, only the universally
    applicable rules and attributes of the SF-182 form will be
    implemented in the Saba system. As with the paper-based version of
    the form, specific agencies may chose to adapt or customize the
    on-line form or process for their own purposes. Any and all
    customizations to the Saba workflow for SF-182 or other Saba
    workflows are outside of the scope of this document.

-   For this implementation, Learning requests made via the SF-182 form
    will be valid only for the external training (i.e. trainings for
    courses not on the Saba catalog). There will be no Saba orders
    created for the learning requests logged for SF-182.

-   As with the SF-182 form, all fields will be editable at any point in
    the process. Unlike the SF-182 form, Saba will provide the
    additional ability to audit any changes to the form as it moves thru
    the approval lifecycle. By default, Saba will not "lock" any fields
    on the form so that they can not be edited, however, we will allow
    the form admin to specify which fields, when edited, will re-submit
    the form for re-approval. Saba will also allow a capability for a
    3^rd^ party interface to flag certain fields as "locked" so that
    they may not be edited at all.

### Functional Overview

Following points describe the functional requirements of this feature.

####  External Learning Request

Learners using the Saba system will have the following options to record
external training on their training record (aka, their Transcript) in
Saba:

1.  Use the ad-hoc process (an existing Saba workflow for adding
    external learning to a user's transcript). There will be no change
    to the current ad-hoc transcript flow.

2.  Use the SF-182 process (the new form and process described in this
    document)

Both of the above will be governed by security grants so an Agency can
control which roles can and cannot initiate these processes. See
security section of this document for details.

#### Request Identification 

Saba will track each of the following for each request:

+-----------------------+-----------------+----------------------------+
| [ID]{.underline}      | [Form           | [Description]{.underline}  |
|                       | at]{.underline} |                            |
+-----------------------+-----------------+----------------------------+
| Saba Generated Unique | 20 characters   | A request will be given a  |
| Request ID            | in the          | single unique ID when      |
|                       | following       | created and that ID will   |
|                       | format:         | not change throughout the  |
|                       |                 | entire lifecycle. Forms    |
|                       | ABCDE           | that are edited and        |
|                       | 000001234567890 | re-submitted will retain   |
|                       |                 | the same Request ID, but   |
|                       |                 | will be given a new        |
|                       |                 | Submission ID (see below). |
|                       |                 |                            |
|                       |                 | Note that customers can    |
|                       |                 | trim off the first 5 alpha |
|                       |                 | characters and continue to |
|                       |                 | have a unique ID. Some     |
|                       |                 | customers may wish to      |
|                       |                 | concatenate Saba's request |
|                       |                 | ID with the submission ID  |
|                       |                 | to create a unique ID for  |
|                       |                 | all re-submissions.        |
+-----------------------+-----------------+----------------------------+
| Submission ID         | 5 characters in | Every time that a form is  |
|                       | the following   | submitted for approval or  |
|                       | format:         | re-approval, this number   |
|                       |                 | will be incremented. Thus, |
|                       | 00001           | when a form is initially   |
|                       |                 | submitted, it might be     |
|                       |                 | given a Request ID of      |
|                       |                 | "12345" and a submission   |
|                       |                 | id of "1". If that form is |
|                       |                 | edited in such a way that  |
|                       |                 | the approvals are reset    |
|                       |                 | and the form must be       |
|                       |                 | routed for re-approval,    |
|                       |                 | the Request ID will remain |
|                       |                 | "12345", but the           |
|                       |                 | submission ID will now be  |
|                       |                 | "2".                       |
+-----------------------+-----------------+----------------------------+
| Last Submitted On     | Standard date   | Represents the last time   |
| Date and Time         | and time format | the form was submitted for |
|                       | for the         | approval and was given a   |
|                       | database in     | submission ID. This will   |
|                       | use.            | always print on the form   |
|                       |                 | when printed.              |
+-----------------------+-----------------+----------------------------+
| Last Edited On Date   | Standard date   | Represents the last time   |
| and Time              | and time format | any attribute on the form  |
|                       | for the         | was edited.                |
|                       | database in     |                            |
|                       | use.            |                            |
|                       |                 |                            |
|                       | []{.mark}       |                            |
+-----------------------+-----------------+----------------------------+

####  SF-182 Form Elements -- Standard 

The learning requests made using the SF-182 form will have the following
fields on the form (see attachment):

[]{.mark}![](media/image1.wmf)

[]{.mark}

[]{.mark}

1.  All List of Value (LOV) fields will be available as Saba "picker"
    icons: icons the can be clicked to view available options. When the
    user use a Saba picker to view available options, the system will
    display all information available in the SF-182 document (page
    7-14). When the user selects a value, Saba will insert the
    appropriate CODE for that item into the form.

2.  Supported field population options. Saba will support (a) field
    values that are manually entered by the user, (b) field values that
    can be defaulted into the form based on information on the User's
    record and (c) field values that can be selected based on a
    pre-defined/static list of values in Saba. To ensure that the form
    can be upgraded/revised over time, Saba will not support: (a)
    conditional values (values for one field that are validated or
    populated based on values entered into another field), (b) dynamic
    list-of-values (lists that dynamically change based on a variable in
    the process).

3.  Online form layout. The UI layout of the form will be similar to the
    hard copy layout with the appropriate data entry controls applicable
    for the fields. Note that, because they are using different
    technologies, the on-line form may not view or print exactly as the
    PDF version might.

4.  Approval chain. The approval chain is not a editable field on the
    form. The approval chain will be captured and displayed to the user
    in two formats: (a) on the form itself in the appropriate field
    and (a) in a Saba summary table. As the approvers approve the
    request, the approval information will be filled in the appropriate
    sections of the form (Section D, Section E and Section F) as well as
    summarized in the Saba table that will be displayed to the user when
    they click on the form "status" link to check status.

####  SF-182 Form Elements -- Custom

Because it is expected that each Agency may have a need to support
custom processes or data elements that are outside of the standard
process, Saba will track 10 custom attributes. Each custom attribute
will have a configurable setting to control whether it that custom
attribute should be displayed to user. Agencies can use these custom
attributes to support a wide variety of custom processes. For example,
the custom fields might track:

-   Accounting data not captured via the SF-182 form:

    -   Request Payment Status (Unpaid, Partially Paid, Fully Paid)

    -   Request Fiscal Year (2007, 2008, 2009)

-   Data required to support external system interfaces:

    -   Interface Processing Status for Request (No Errors, Error XYZ,
        Error 123)

    -   Interface Transaction Code for Request

-   User messages, Reporting Data, or other attributes specific to a
    customer and their business

#### Request Flow -- Status Summary

**Training Request Lifecycle.** The request will have the following
states:

+-----------+---------------------------+----------------+-----------+
| [S        | [Definition]{.underline}  | [Available     | [Saba     |
| tatus]{.u |                           | Action         | T         |
| nderline} |                           | s]{.underline} | ranscript |
|           |                           |                | Ex        |
|           |                           |                | ists?]{.u |
|           |                           |                | nderline} |
+-----------+---------------------------+----------------+-----------+
| Draft     | The status of a request   | User:          | No        |
|           | when the learner creates  |                |           |
|           | it but does not submit it | -   Edit \>    |           |
|           | for the next step.        |     Save Draft |           |
|           |                           |                |           |
|           |                           | -   Edit \>    |           |
|           |                           |     Submit     |           |
|           |                           |                |           |
|           |                           | Admin:         |           |
|           |                           |                |           |
|           |                           | -   Edit \>    |           |
|           |                           |     Save Draft |           |
|           |                           |                |           |
|           |                           | -   Edit \>    |           |
|           |                           |     Submit     |           |
+-----------+---------------------------+----------------+-----------+
| Pending   | The status of a request   | User:          | No        |
| Approval  | when the learner has      |                |           |
|           | entered the required data | -   Edit /     |           |
| > \- or   | in the request and        |     Resubmit   |           |
| > --      | submitted for further     |                |           |
|           | processing.               | -   Cancel     |           |
| Pending   |                           |                |           |
| Approval  |                           | Admin:         |           |
| -- Manual |                           |                |           |
|           |                           | -   Edit /     |           |
|           |                           |     Resubmit   |           |
|           |                           |                |           |
|           |                           | -   Cancel     |           |
|           |                           |                |           |
|           |                           | Section D/E    |           |
|           |                           | Users:         |           |
|           |                           |                |           |
|           |                           | -   Approve    |           |
|           |                           |                |           |
|           |                           | -   Reject     |           |
+-----------+---------------------------+----------------+-----------+
| Cancelled | The status of a request   | User:          | No        |
|           | that is not in the        |                |           |
|           | complete status and has   | -   Delete     |           |
|           | been Cancelled by the     |                |           |
|           | learner.                  |                |           |
+-----------+---------------------------+----------------+-----------+
| Approved  | The status of a request   | User:          | No        |
|           | based on the action taken |                |           |
| > --or-   | by a approver in the      | -   View       |           |
|           | approval chain for the    |                |           |
| Rejected  | request. If all the       | -   Cancel     |           |
|           | approvers in the approval |                |           |
|           | chain approve the request | Section F      |           |
|           | the status will be        | Users:         |           |
|           | "Approved", if any one    |                |           |
|           | approver rejects the      | -   Mark       |           |
|           | request the state will be |     Complete   |           |
|           | "Rejected". Form approval |                |           |
|           | is captured in Sections D | -   Cancel     |           |
|           | and E of the SF-182 form. |                |           |
+-----------+---------------------------+----------------+-----------+
| Completed | The status of the request | All:           | Yes       |
|           | once the training         |                |           |
|           | activity is mark          | -   View       |           |
|           | completed.                |                |           |
|           | Certification/Completion  | Admin:         |           |
|           | is captured in Section F  |                |           |
|           | of the SF-182 form.       | -   Edit       |           |
+-----------+---------------------------+----------------+-----------+

####  Request Flow -- Detailed

**[User Interface Flows]{.smallcaps}**

[http://sharepointrd/sites/uexp/default.aspx?RootFolder=%2fsites%2fuexp%2fShared%20Documents%2fDesigns&View=%7bDC43C8EC%2d329B%2d41A7%2d8862%2dD3920A7F7A85%7d](http://sharepointrd/sites/uexp/default.aspx?RootFolder=%2Fsites%2Fuexp%2FShared Documents%2FDesigns&View={DC43C8EC-329B-41A7-8862-D3920A7F7A85})

**[Initiate a request]{.smallcaps}**

+--------------+-------------------------------------------------------+
| [Summary]    | The step involves a learner placing a request for a   |
| {.smallcaps} | training.                                             |
+--------------+-------------------------------------------------------+
| [Status]     | The status of the request at the start of the process |
| {.smallcaps} | will be: **(null)**                                   |
|              |                                                       |
|              | The status of the request at the end of the process   |
|              | will be: **Draft** --or- **Pending Approval**         |
+--------------+-------------------------------------------------------+
| [Owner]      | The owner of the request in this state is the learner |
| {.smallcaps} | who has initiated the request.                        |
+--------------+-------------------------------------------------------+
| [Printing]   | If the form is printed at this stage, it will contain |
| {.smallcaps} | a bold red note that indicates that it has not been   |
|              | officially submitted and should NOT be used for the   |
|              | manual/offline approval process.                      |
+--------------+-------------------------------------------------------+
| [Sections]   | The following information is required to be captured  |
| {.smallcaps} | at this state:                                        |
|              |                                                       |
|              | 1.  Section A: Trainee information                    |
|              |                                                       |
|              | 2.  Section B: Training course data                   |
|              |                                                       |
|              | 3.  Section C: Costs and Billing Information          |
|              |                                                       |
|              | 4.  Section D: Approvals (validate approvers)         |
|              |                                                       |
|              | 5.  Section E: Approvals/Concurrence (validate        |
|              |     approvers)                                        |
|              |                                                       |
|              | All form sections are blank at the initiation of the  |
|              | process. When a new form is created, is will be       |
|              | automatically populated as specified in the "Form     |
|              | Elements" section of this document (2.2.2.3).         |
+--------------+-------------------------------------------------------+
| [UI          | The flow for the process is available at:             |
| Design]      |                                                       |
| {.smallcaps} | [http://sharepointrd/sites/uexp/Shared%20Doc          |
|              | uments/Designs/MySaba_SF182.vsd](http://sharepointrd/ |
|              | sites/uexp/Shared Documents/Designs/MySaba_SF182.vsd) |
|              |                                                       |
|              | (See screens: MyS1, MyS2, MyS2C)                      |
+--------------+-------------------------------------------------------+

**[Submit a Request]{.smallcaps}**

+--------------+-------------------------------------------------------+
| [Summary]    | A user can submit a request after it has been         |
| {.smallcaps} | initiated and they have filled in and/or validated    |
|              | the required information. The user can submit the     |
|              | request in one of two ways:                           |
|              |                                                       |
|              | -   manual approval process or                        |
|              |                                                       |
|              | -   electronic approval process.                      |
|              |                                                       |
|              | Note that, for either process, the user must finalize |
|              | the process on-line in Saba.                          |
+--------------+-------------------------------------------------------+
| [Status]     | The status of the request at the start of the process |
| {.smallcaps} | will be: **Draft**                                    |
|              |                                                       |
|              | The status of the request at the end of the process   |
|              | will be: **Pending Approval**                         |
|              |                                                       |
|              | Note The status of the request will be "**Pending     |
|              | Approval**" if the request has a associated approval  |
|              | chain and the learner has a minimum of one assigned   |
|              | approver in the chain (Refer to the [open             |
|              | issues](#state-of-request-submitted-for-approval)     |
|              | related to the states). If the form does not have any |
|              | approvers noted in the approval chain, the status     |
|              | will be marked as "**Approved**". However, the form   |
|              | set-up can specify that the approver fields are       |
|              | required and can not be left blank.                   |
|              |                                                       |
|              | Submitted for Manual approval:                        |
|              |                                                       |
|              | -   In case the request is submitted for manual       |
|              |     approval, the request should be shown as pending  |
|              |     approval in a "manual approval" status. If the    |
|              |     user clicks on that status, they will see all     |
|              |     approvers in the appropriate status (like to be   |
|              |     "Pending Approval" until an Admin or other user   |
|              |     updates the approvals online).                    |
|              |                                                       |
|              | Submitted for electronic approval:                    |
|              |                                                       |
|              | -   In case the request is submitted for electronic   |
|              |     approval the request will be shown as pending     |
|              |     approval with the first approver in the approval  |
|              |     chain.                                            |
|              |                                                       |
|              | Refer to the [open                                    |
|              | issues](#req                                          |
|              | uest-is-submitted-and-the-user-has-no-approval-chain) |
|              | section for the case where a user either has no       |
|              | approval chain defined or the users in the approval   |
|              | chain are no longer active.                           |
+--------------+-------------------------------------------------------+
| [Owner]      | The owner of the request in this state is the FIRST   |
| {.smallcaps} | approver listed in Section D.                         |
+--------------+-------------------------------------------------------+
| [Printing]   | On printing the form the timestamp of (a) last        |
| {.smallcaps} | submission and (b) last edit will get printed on the  |
|              | form. This will be used to indicate the version of    |
|              | the form being printed.                               |
+--------------+-------------------------------------------------------+
| [Sections]   | The user is responsible for validating the data that  |
| {.smallcaps} | will be automatically populated by the Saba system    |
|              | including appropriately completing sections A-C of    |
|              | the form and validating the approver information      |
|              | listed in sections D-F.                               |
|              |                                                       |
|              | Sections D and E of the form capture Approvals.       |
+--------------+-------------------------------------------------------+
| [UI          | [See other flows.]{.smallcaps}                        |
| Design]      |                                                       |
| {.smallcaps} |                                                       |
+--------------+-------------------------------------------------------+

**[Cancel a Request]{.smallcaps}**

+--------------+-------------------------------------------------------+
| [Summary]    |                                                       |
| {.smallcaps} |                                                       |
+--------------+-------------------------------------------------------+
| [Status]     | The status of the request at the start of the process |
| {.smallcaps} | will be: **Pending Approval** --or- **Approved**      |
|              |                                                       |
|              | The status of the request at the end of the process   |
|              | will be: **Cancelled.**                               |
|              |                                                       |
|              | At any time (prior to the training request form being |
|              | set to "complete"), the learner (or manager on behalf |
|              | of a learner) must be able to Un-Submit / Cancel a    |
|              | training request.                                     |
|              |                                                       |
|              | Canceling a training request removes it from the      |
|              | workflow routing process and sets the status to       |
|              | "Cancelled." No other attributes of the form will be  |
|              | modified or re-set.                                   |
|              |                                                       |
|              | Canceling a training request will move the request to |
|              | "**Cancelled**" status.                               |
|              |                                                       |
|              | -   If the form had not yet been submitted for        |
|              |     approvals, the form status is updated to Canceled |
|              |     and no further workflows/actions are necessary.   |
|              |                                                       |
|              | -   If the form had been submitted for approvals (and |
|              |     approvals may or may not have been finalized) all |
|              |     approval actions are left unchanged and the form  |
|              |     is moved to Cancelled status.                     |
|              |                                                       |
|              | Cancelled requests can not be re-initiated.           |
+--------------+-------------------------------------------------------+
| [Owner]      | Once the request is cancelled the owner of the        |
| {.smallcaps} | request will be initiator of the request.             |
+--------------+-------------------------------------------------------+
| [Printing]   | On printing the form the timestamp of (a) last        |
| {.smallcaps} | submission and (b) last edit will get printed on the  |
|              | form. This will be used to indicate the version of    |
|              | the form being printed.                               |
+--------------+-------------------------------------------------------+
| [Sections]   | [N/A]{.smallcaps}                                     |
| {.smallcaps} |                                                       |
+--------------+-------------------------------------------------------+
| [UI          | The flow for the Cancellation of requests is          |
| Design]      | available at                                          |
| {.smallcaps} |                                                       |
|              | [http://sharepointrd/sites/uexp/Shared%20Doc          |
|              | uments/Designs/MySaba_SF182.vsd](http://sharepointrd/ |
|              | sites/uexp/Shared Documents/Designs/MySaba_SF182.vsd) |
|              | (Screens: MyS3, MyS3a, MyS3b, MyS3c)                  |
+--------------+-------------------------------------------------------+

**[Approve (or Reject) a Request]{.smallcaps}**

+---------+------------------------------------------------------------+
| [Summar | The users in the approval chain can either Approve or      |
| y]{.sma | Reject a request.                                          |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [Statu  | The status of the request at the start of the process will |
| s]{.sma | be: **Pending Approval**                                   |
| llcaps} |                                                            |
|         | The status of the request at the end of the process will   |
|         | be: **Approved** --or- **Rejected**                        |
|         |                                                            |
|         | The status of the request will either be "**Approved**" or |
|         | "**Rejected**" based on the action of the approvers.       |
|         |                                                            |
|         | Refer to the [open                                         |
|         | issues](#request-is-submitted-to-an-inactive-approver.)    |
|         | section for the issues related to the approval step.       |
|         |                                                            |
|         | If the training is approved, and once all levels of        |
|         | approval are received and there are no rejections, the     |
|         | student can be notified by                                 |
|         | [email/notification](#notification-requirements) that the  |
|         | training is approved and the system is updated with this   |
|         | information. Note that Saba will not provide               |
|         | out-of-the-box messages for any notification events (these |
|         | are all customer configurable), but it is recommended that |
|         | this notification text should indicate that the next and   |
|         | final step is to have the form marked as complete to get   |
|         | transcript credit.                                         |
+---------+------------------------------------------------------------+
| [Owne   | If the request is rejected, the owner of the request will  |
| r]{.sma | be the Initiator of the request. If a request is approved, |
| llcaps} | the owner will be the next user in the approval chain.     |
|         | Once all approvers have approved the form, the owner will  |
|         | be the user specified in Section F.                        |
+---------+------------------------------------------------------------+
| [       | On printing the form the timestamp of (a) last submission  |
| Printin | and (b) last edit will get printed on the form. This will  |
| g]{.sma | be used to indicate the version of the form being printed. |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | [Sections D and E track approvals.]{.smallcaps}            |
| Section |                                                            |
| s]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [UI     | The flow for approvals is available at                     |
| Desig   |                                                            |
| n]{.sma | [http://sharepointrd/sites/uexp/Sh                         |
| llcaps} | ared%20Documents/Designs/MySaba_SF182.vsd](http://sharepoi |
|         | ntrd/sites/uexp/Shared Documents/Designs/MySaba_SF182.vsd) |
|         |                                                            |
|         | (Screens: MSAL1,MSAL1a)                                    |
|         |                                                            |
|         | The people admin can approve a request on behalf of any    |
|         | approver. The flow for this is available at                |
|         |                                                            |
|         | [http://sharepointrd/sites/uexp/Shared%20Documents/Desig   |
|         | ns/SF182_Approval_MS_TH_PA.vsd](http://sharepointrd/sites/ |
|         | uexp/Shared Documents/Designs/SF182_Approval_MS_TH_PA.vsd) |
|         |                                                            |
|         | (Screens PA2, PA2a, PA2b).                                 |
+---------+------------------------------------------------------------+

**[Complete a Request]{.smallcaps}**

+--------------+-------------------------------------------------------+
| [Summary]    | The user noted in Section F will mark the form as     |
| {.smallcaps} | Complete, which will result in an ad-hoc training     |
|              | record being created in the users Transcript.         |
+--------------+-------------------------------------------------------+
| [Status]     | The status of the request at the start of the process |
| {.smallcaps} | will be: **Approved**                                 |
|              |                                                       |
|              | The status of the request at the end of the process   |
|              | will be: **Completed**                                |
+--------------+-------------------------------------------------------+
| [Owner]      | Once all approvers have approved the form, the owner  |
| {.smallcaps} | will be the user specified in Section F.              |
+--------------+-------------------------------------------------------+
| [Printing]   | On printing the form the timestamp of (a) last        |
| {.smallcaps} | submission and (b) last edit will get printed on the  |
|              | form. This will be used to indicate the version of    |
|              | the form being printed.                               |
+--------------+-------------------------------------------------------+
| [Sections]   | Section F of the form captures the final              |
| {.smallcaps} | Certification / Completion information for approved   |
|              | forms, including confirming costs reflect             |
|              | actual/final cost amounts. It is important that the   |
|              | cost and other information be confirmed to be         |
|              | accurate prior to marking an approved request as      |
|              | complete.                                             |
+--------------+-------------------------------------------------------+
| [UI          | See other flows.                                      |
| Design]      |                                                       |
| {.smallcaps} |                                                       |
+--------------+-------------------------------------------------------+

![](media/image2.png){width="4.978472222222222in"
height="6.270138888888889in"}

Figure 1: Draft mapping of SF-182 to Saba Transcript (TBD)

####  Setup in Person Profile

The flow for setting up the person profile is available at

[http://sharepointrd/sites/uexp/Shared%20Documents/Designs/People%20Admin_SF182.vsd](http://sharepointrd/sites/uexp/Shared Documents/Designs/People Admin_SF182.vsd)

The learner profile can be setup for the approval process from the
people admin role as shown in screen PA1 in the flow above. The approval
chain will be associated to a person for the given set of relationships.
The people defined by relationship will be used by the approval process
for determining the next person in the approval chain.

The approvers for a learner can be set as part of creating/updating a
user's record in Saba. TBD: Saba may also support feeding the approval
chain into the system using the available data import capability.

#### Form Setup

In this release the definition of the form, the fields and the approval
chain template applicable to the form will be provided in a hard coded
file. The template will be used to paint the form and its approval chain
when a user initiates a new "External Learning Request". There will be
no user interface to modify the default approver chain definition or the
field definitions for the form.

The learner making the request can change the approver at a particular
level but cannot skip a level of approval.

####  Printing requirements

As feasible, the printed version of the form should mirror the current
hard copy layout for SF-182.

The form on the request will be printable under the following
conditions:

1.  Intermediate saves

> The learner can print the form when the form is in the "In-process"
> state. There needs to be a date and time stamp printed on the form to
> indicate the time of printing the form and that it is still in "In
> Progress" state.

2.  Manual processing

> The form should be available for printing once the user selects the
> manual processing option

3.  Electronic processing

> The form should be available for printing once submitted for
> electronic processing should be available for printing.

# Detailed Use Case Specifications

####  Use Cases for the Learner:

> **1. Learner wants to create a Learning request for external
> training:**

**Request initiation:**

> The request can be initiated by a Learner in the system. The learner
> does that via the "My Saba" role.
>
> The learner will be prompted with the form for filling the required
> information. The learner can change the defaulted information within
> the guidelines established when setting-up the form.
>
> Once the information is filled in the learner can choose to either
> "Save" the form or "Submit" the form.

a.  Save the form: If the form is saved by the learner it will be
    available to the learner for further editing and submitting for
    approval.

b.  Submit the form: If the form is submitted there will validation
    performed to check if the required fields have been entered. The
    request will then will be available to the first approver for
    approval.

> **2. Learner wants to cancel a learning request:**

**Request Cancellation:**

> A learner can cancel a request if its not in the completed state.

####  Use Cases for the Approver:

> **1. Approver want to approve/reject a request.**

**Approval of the request:**

> A designated approver can approve or reject a training request
> submitted by the learner. On approval/rejection of the request the
> user will be prompted for the audit information and a notification is
> sent to the learner.

####  Use Cases for the Approver:

1.  **Person profile setup:**

> People admin needs to setup the person profile for the approval chain.
> The admin needs to define the relationships in the approval chain and
> the associated person in the chain for that relationship.

# Enterprise characteristics and other requirements

## Notification Requirements

### Triggered Notifications 

The following notifications will be sent on approval/rejection of the
request:

**Event:** Learning request submitted for approval

> The event will be fired in the following conditions:
>
> a\. The learner has submitted the form.
>
> b\. A approver has approved the learning request and the request needs
> to be forwarded to the next approver in the approval chain.

1\. **Named Query:**

a.  Next Learning Request approver: This named query will return the
    next approver in the approval chain to whom the learning request
    will be forwarded.

b.  Initiator of the Learning request: This named query will return the
    person initiating the request.

```{=html}
<!-- -->
```
1.  **Keywords:** The following keywords will be available for the
    notification:

    a.  Initiator name: Name of the person initiating the learning
        request

    b.  Trainee name: Name of the learner.

    c.  Course Title: The title of the course for which the learning
        request is being made.

    d.  Training start date: The start date of the training

    e.  Training end date: The end date of the training

    f.  Total Cost of training: The cost field computed from the Section
        C of the SF-182 form.

    g.  Learning request status: The status of the learning request.

**Event:** Learning request Rejected

> The event will be fired in the following conditions:
>
> a\. The learning request is rejected by any one of the approvers in
> the approval chain.

1\. **Named Query:**

> Initiator of the Learning request: This named query will return the
> person initiating the request.
>
> **2. Keywords:** The following keywords will be available for the
> notification:

a.  Initiator name: Name of the person initiating the learning request

b.  Trainee name: Name of the learner.

c.  Course Title: The title of the course for which the learning request
    is being made.

d.  Training start date: The start date of the training

e.  Training end date: The end date of the training

f.  Total Cost of training: The cost field computed from the Section C
    of the SF-182 form.

**Event:** Learning request Approved by a single Approver.

The event will be fired when the data on the learning request/form is
approved by a single approver.

**Event:** Learning request Approved by a ALL Approvers.

The event will be fired when the data on the learning request/form is
approved by all approvers.

**Event:** Learning request Completed.

The event will be fired when the data on the learning request/form is
completed.

### Periodic Notifications

**Event:** Reminder for Training completion.

The notification will be fired on a daily basis to see if the training
date plus some configured number of days has elapsed since the training
was supposed to be complete. If the waiting period has expired, the
system should send the student an email reminding them to complete the
training activity. The system should send periodic reminders based upon
a configured value for a configured number of times.

**1. Named query:**

> Initiator of the Learning request: This named query will return the
> person initiating the request.
>
> **2. Keywords:** The following keywords will be available for the
> notification:

g.  Initiator name: Name of the person initiating the learning request

h.  Trainee name: Name of the learner.

i.  Course Title: The title of the course for which the learning request
    is being made.

j.  Training start date: The start date of the training

k.  Training end date: The end date of the training

l.  Total Cost of training: The cost field computed from the Section C
    of the SF-182 form.

## Performance and Scalability Requirements

N/A.

## Volume Requirements

The application will support the import of the approval chain for a
learner via the import functionality.

## Integration Requirements

N/A.

## Upgrade Requirements

None.

## Migration Requirements

Need to identify migration requirements.

## Report Requirements

N/A.

## Installation Requirements

N/A.

## I18n and l10n Requirements

N/A.

## Auditing and E-Signature Requirements

The following actions will be audited in the system:

-   The state change of the request on being submitted: the system will
    do a silent auditing of the actions taken on a learning request
    during the lifecycle of the request.

-   Any form attributes that are set to "Is Audited? = Yes" in the form
    set-up process.

## Security Requirements

[Domain-security]{.underline}

-   The form will be domain aware.

-   The default form will be setup for the world domain, so that there
    is only one version of the form for the entire application.

-   In the Multi Tenancy environment, there will be one form per
    world-let.

[Role-security]{.underline}

  ------------------------ ---------------------- ------------------------
  [New Grant]{.underline}  [Object]{.underline}   [Definition /
                                                  Use]{.underline}

  ~~Can initiate External  ~~(TBD)~~              ~~If the user does not
  Learning Request~~                              have this grant, they
                                                  can not see or initiate
                                                  an External Training
                                                  Request.~~

  (All Ad Hoc grants)                             Confirm that, if a user
                                                  does not have a
                                                  particular Ad Hoc grant,
                                                  the appropriate
                                                  links/pages do not
                                                  appear.

  Can submit form manually                        This grant will control
                                                  whether a user can
                                                  submit a form manually.
                                                  If they do not have this
                                                  grant, they will not be
                                                  able to submit manually.

  Can submit form on-line                         This grant will control
                                                  whether a user can
                                                  submit a form on-line.
                                                  If they do not have this
                                                  grant, they will not be
                                                  able to submit on-line.
  ------------------------ ---------------------- ------------------------

## Business Rule Requirements

## Portlet Requirements

N/A.

## "Saba Where You Work" Requirements

N/A.

# Testing

## Unit Testing

## Integration Testing

N/A.

## Feature Testing

# Future Enhancements

The current document defines the functionality for the requests
involving the SF-182 form. Need to enhance the functionality to support
different types of forms and workflows.

# Out Of Scope

N/A.

# Documentation

![](media/image3.wmf)

# Tracking feedback and Issues

Describe here any open issues, which still need to be addressed in this
Functional Specification. For open issues which have been closed note
down the resolution and date of resolution. Also capture any feedback
from reviewers during the review process.

## Open Issues

### Request is submitted and the user has no approval chain

In the above case we need to define the flow of the request.

The two possible solutions would be:

1.  Redirect the request to a default approver defined in the person's
    profile.

2.  Allow the form to specify the approver fields as mandatory and move
    the state of the request to the approved state if there are no
    approvers specified.

Refer to the [closed
issues](#request-is-submitted-and-the-user-has-no-approval-chain-1).

### Request is submitted to an inactive approver. 

In this case, the People Admin will need to intervene.

Refer to the [closed
issues](#request-is-submitted-and-the-user-has-no-approval-chain-1).

### Approval chain related issues

Need to define the functionality for the following scenarios:

1.  What is the state of the request when one approver has approved the
    request and is awaiting approval from the next in line approver

2.  What happens if any approver in the chain denies/rejects the request

3.  if there are 2 approvers in the chain and if the request is pending
    approval with the first approver can the second approver see the
    request in the queue and if yes can the second approver approve/deny
    the request.

Refer to the [closed
issues](#request-is-submitted-to-an-approver-who-is-no-longer-active-in-the-system).

### New privilege to be added in the system

Need to define a new privilege in the system for giving the user the
capability to associate a request type with a form and define the
approval chain for the form.

Refer to the [closed
issues](#new-privilege-to-be-added-in-the-system-1).

### State of request submitted for approval

Since the learner can submit a request either for electronic or manual
approval. There should be a way to distinguish between the methods of
submission.

### Final Owner of the request

Need to define the final owner of the request once the request is in
Complete State.

### Definition of Agency code

How do we define this for a customer..

### Relationship for approvers

Can we audience types to model the groups for the approvers

### Approval chain on the form

> If the approval chain for a form is defined as a ["Group of
> Approvers"](#group_approval), what is the chain that the learner will
> see on the form. If its only the group names that the learner will
> change, what is the flow for changing the approver.
>
> If the learner submits the form for manual approval what will get
> printed on the form in the above case.

### Default approver in the system

> Should the default approver in the system be
>
> a\. "People admin" or
>
> b\. A person with a certain privilege be designated as the default
> approver. If we go with this approach need to define the privilege.
>
> Where will the person see the requests that have be directed because
> the person is a default approver.

Refer to the [Closed
issue](#request-is-submitted-and-the-user-has-no-approval-chain-1).

### Open issues from the PRD

1\. Need to define the following requirement:

Request Status / Prerequisites - user selects either Initial,
Resubmission, Correction or Cancellation (mark appropriate box). In
SF182 these options are grouped into 2 options: Initial/Resubmission, or
Correction/Cancellation

2\. Multiple Locales:

There are fields on the form that have locale specific formats like
Name, Date, Amounts. These fields have formats that are specific to a
form and not tied to the user that is filling in the form. Are there use
cases where the same form might be used across different locales? If
yes, how do we define these forms across locales and how does the user
select the locale?

## Closed Issues

### Request is submitted and the user has no approval chain

> If a request is submitted with no approval chain, it will be
> automatically approved. The "People Admin" will see all the requests
> that are pending approval and will be able to approve a request on
> behalf of a particular role.

### Request is submitted to an approver who is no longer active in the system

In this case, the People Admin will need to intervene to approve on
behalf of that user and/or change the approver. Each organization will
accommodate this process as appropriate to their own business.

### Approval chain related issues

> The approval chain will be linear and the request will have to pass
> through all the approvers in section D and Section E of the report to
> get to the approved status. Any approver cannot see a request in the
> approval queue till the prior approver has approved it. If the prior
> approver rejects the request the next approver will not get to see the
> request.

### New privilege to be added in the system

The association of request type with the approval chain will be provided
OOB for this release. New privileges that are added are:

1.  Can approve request

2.  Withdraw from approval

3.  Can submit electronic approval for others

4.  Can submit electronic approval for self

5.  Can submit manual approval for others

6.  Can submit manual approval for self

7.  Can mark complete for self

8.  Can mark complete for others

9.  Can approve as admin

The admin approval will be privilege driven.

### Define mandatory/optional fields on the form

The fields will not be editable once the user submits it for approver.
The only fields that would be editable are marked "Yes" in the table for
the [fields mapping](#field_mapping).

# Change Log

The Change Log is used to keep a record of the changes made to the
Functional Specification. An entry only needs to be added each time it
is published, although the author may want to include intermediate
steps.

  ------------- ----------- ------------ -------------------------------------------
  **Version**   **Date**    **Who**      **Action**

  4.00          03-Aug-07   Atin         New Privileges are added

                                         

                                         

                                         

                                         

                                         
  ------------- ----------- ------------ -------------------------------------------

# Document Sign-Off

The Document Sign-Off is used to record that has reviewed and approved
the Functional Specification.

  ----------- ---------------------- -------------------------------------
  **When**    **Who**                **Department**

  mm/dd/yy    \<\>                   Product Management

  mm/dd/yy    \<\>                   Engineering

  mm/dd/yy    \<\>                   Quality Engineering

  mm/dd/yy    \<\>                   User Experience

  mm/dd/yy    \<\>                   Documentation
  ----------- ---------------------- -------------------------------------