FOIA and Privacy Act Tracking 14-3
■
Sub-workflows can also be used to split complex workflows into manageable parts and can be used with either a criteria or a basic workflow.
Workflows are composed of steps in which content is reviewed, approved or denied. Multiple reviewers can be assigned to approve or reject the content at each step. A set
of users and the step type must be defined for each step in the workflow. Users assigned to a step can only perform the tasks allowed for that step type.
Workflows can be customized in several ways. Tokens can be used to designate unknown users. Aliases can be used to include a group of people in a workflow step.
Jumps enable the creation of conditional statements to branch content through different paths in the same workflow or to route content to a different workflow. Exit
conditions can prevent content from moving to the next step unless essential conditions are met. Custom metadata fields can be created and used to trigger
different workflows.
For details about these customization tips and for examples of workflows, see the Oracle Fusion Middleware Application Administrators Guide for Content Server.
14.3 The FOIAPrivacy Act Workflow
The FOIAPA workflow provided with Oracle URM should be considered a starting point for the process to be used. It must be customized with users added as reviewers,
specific rules added to reflect the process in place at different organizations, and additional steps added as needed. In addition, this version of the workflow reflects
draft requirements specified by the Joint Interoperability Task Force JITC. It should be expected that these requirements will change in the future and the procedures
outlined here may then be outdated.
Only those request forms requiring approval go through a workflow process. Other necessary supporting forms must be filled out and filed in the requestor’s folder.
Those forms are linked to the main request using the Related Content functionality.
There is no set time frame for filing of those forms, but they must be completed before the workflow is completed when the request is either denied or serviced. Those forms
are not discussed in this chapter.
This section discusses the current default workflows provided with the software. It is divided into task groupings, most of which are based on the decision points in the
workflow. The finished, customized workflow at your site may have different decision points and tasks than those discussed here.
14.3.1 Processing Details
When a workflow is started to process an information request, the stages of the workflow are automatic and may branch depending on the choices made during the
process for example, a denial of the information request, or the servicing of a request. It is important to know the stage where a request is currently in process because that
will determine which workflow must be used for action.
The Active Workflows Screen
shows all types of workflows available with the system. When a user accesses a request being processed, the appropriate stage of the workflow
must be chosen. The stage of the workflow is shown on the Workflow Content Page
in the Step column.
Time limits are set according to the specification guidelines for each stage of processing. These limits are set within the workflow and be changed if needed. See the
Oracle Fusion Middleware Application Administrators Guide for Content Server for details about editing workflows.
14-4 Oracle Fusion Middleware Administrators Guide for Universal Records Management
To view current workflow assignments, click My Content Server then My Workflow Assignments
from the Main menu or click the My Workflow Assignments link on the
Active Workflows Screen .
14.3.2 Initial Required Setup
As mentioned earlier, the default workflow must be customized to add the appropriate users, steps, and decision points for your working environment. This must
be done before using this functionality.
Forms are submitted from within a record folder, so make sure to set up the category structure beforehand. Categories should be created where FOIA and PA requests will
be stored for example, Open FOIA Requests and Open PA Requests. As information requests are received, a new folder must be created for each request
within the appropriate category. This folder will house all of the paperwork associated with the request.Therefore, any people involved in the workflow process should be
those users who have the necessary rights and roles to allow them to create and move folders. Depending on how the system is set up, users will receive notification email
with links to actions that can be performed depending on the user’s rights and roles.
Categories must be created to store the finished requests. The naming and disposition rules for those categories is an organizational decision. Categories could be created
based on final outcome Granted in Full, Refused, and so on or by date for example, December 2009 requests or some other filing method.
In addition to creating folders, plan to track expenses associated with the request process. Information such as the fees collected, the staff allocated to the request, the
time and money spent servicing the request, and the final result of the request should all be tracked independently in order for final reports to be produced. As noted
previously, the workflow and reports documented here are based on the draft specification which may change in the future.
14.3.3 Begin Request Processing
