Architecture

The PM schedule approval workflow uses the workflow framework provided by PeopleSoft Enterprise Components, rather than the standard PeopleTools workflow, which requires advanced technical skills in PeopleTools. Consequently, the PeopleSoft Maintenance Management workflow is easy to create and maintain. All the steps in the PM schedule approval workflow are defined using PeopleSoft pages and are designed so that functional users can easily set it up.

PeopleSoft Maintenance Management delivers the PM schedule approval workflow engine preconfigured. Oracle recommends using the delivered configuration as is, making minor modifications to suit your particular business practices. The PM schedule approval is delivered as system data, using the WM_PM_SCHD approval process ID. You can modify the definition to suit your implementation by defining your own phases, steps, and criteria. These definitions control who should approve the PM schedule, the order in which they approve it, and the method by which the system routes it to approvers. The approval process is keyed by SetID, and by using SetID sharing, each business unit can either have its own independent PM schedule approval process configuration or share the same approval process configuration with other business units. Oracle recommends that you understand the workflow technology before making any changes.

See documentation PeopleSoft Approval Framework

PM schedules are routed to approvers so that they can act on the PM schedules to approve or deny them. If the approver approves a PM schedule, then it is routed to the next approver, if any. A submitter or approver can add ad hoc approvers for the current PM schedule as well. After the PM schedule is fully approved (or no approval is required), it is available to be selected by PM and Projection processes. If the approver denies a PM schedule, than the approval process is terminated. The submitter is notified of the denial and can optionally revise the PM schedule and resubmit it.

The following elements are used in the PM schedule approval process definition and are among the items you would modify to suit your business requirements:

• Stages.

  A stage is one part of an approval process that can contain multiple parallel paths. The system executes stages in sequence where one must complete before the next one begins. A stage consists of one or more paths.

• Paths

  A path contains a sequence of steps. Within a stage, paths execute in parallel. Path entry criteria determine whether a path executes for a given PM schedule.

• Steps

  A step represents one or more approvers or reviewers. Steps within a path execute in sequence. Separate criteria for each step determine whether or not that step executes. Each step can also have a set of reviewers, who are notified about transactions pending approval by email, if configured, and through the Worklist. But the workflow proceeds without waiting for reviewers to act.

  Note:

  While the approval process configuration may require any number of approvers to approve a step before it advances, any single approver can deny a PM schedule. After a PM schedule is denied, the system stops routing the PM schedule, the approval process terminates, and the entire PM schedule is denied.

  The system notifies approvers of a pending approval by using Worklist and email. You need to define the individuals or roles that comprise a user list, and the authorized approvers. You can specify approvers by roles, queries, fixed lists, or by using custom application classes. Once the required number of approvers have approved a step, the approval workflow advances past that step.