AWE Configuration Settings

GT eForms 3.x uses PeopleSoft’s Approval Workflow Engine (AWE) to route eForms for evaluation. When GT eForms 3.x is installed, 10 delivered AWE definitions are supplied for basic workflow. Below are the default settings and general information about AWE as it pertains to GT eForms. See Peoplebooks for more information about the Approval Framework pages.

Register Transactions

An Approval Framework Process ID is created under the Transaction Registry > 'Add New Value' tab. Existing Process IDs can be found under the Find an Existing Value tab. This is the first step in configuring a Process ID. There is a delivered GT Basic Process ID that can be used for forms that follow the basic setup or as a sample in creating new Process IDs.

Navigation: Enterprise Components > Approvals > Approvals > Transaction Registry

Field	Value/Use
Process ID	Unique value set during add
Description	Text description to describe the Process ID
Owner ID	Used to filter the Process IDs in the search criteria
Cross Reference Table	G3FORMLIST_XRF should be used for all GT forms unless an override is needed at this level to meet business requirements
Notification Options	These settings enable notification and worklist items to be sent from the GT Framework and will likely always be set this way for all forms. Fields not mentioned below should be blank.
Enable Notifications	‘Enable Email and Worklist’
Notification Strategy	‘Online Processing’
Internal URL Definition	This section is left blank
External URL Definitions	This section is left blank
Default Approval Component	This value is set in the GT Forms framework. The fields are required and should be set as follows
Menu Name	G_FORM_AXXXX
Approval Component	G_FORM_AXXXX_A
Approval Event Handler Class	The values in this section will usually be set as follows unless there is a need to override the setting at the framework level to meet business requirements.
Approval Status Monitor	This section is used to indicate the configuration for the visualizer. Part of this code includes the behavior of the ad hoc functionality. See the Optional Settings section for additional information on default GT settings.
Adhoc Package	G3AWE_FORM
Adhoc Class	ClientAdHocLogic
Transaction Approval Levels	Used to define the header and line-level records that are used to determine the workflow path. The settings described below are generally used, but additional records can be added.
Level	Header
Record (Table) Name	G3FORMLIST
Level Record Key Field Label IDs	The values in this table are automatically pulled in when a record is added to the Transaction Approval Levels above
Record (Table) Name	Shows the record that corresponds to this field
Field Name	Name of the key field(s) for the indicated records
Field Label ID	Prompt will show all of the available field label choices. The selected value shows in the visualizer on the form.

Configure Transaction

Each Process ID will also have settings on the Configure Transaction page. The following describes the settings for the GT Basic Process ID. Additional Process IDs can be created to alter these settings. Process IDs cannot be added on this page. They are added on the Transaction Registry page.

Navigation: Enterprise Components > Approvals > Approvals > Transaction Configuration

Field	Value/Use
Ad Hoc Approver Options	The fields in this section are used to define the list of users that appear under the prompt search when doing an ad hoc step.
Approval User Info View	Set to PSOPERDEFN_VW. This means that the list of ad hoc users will start with all PS users.
Ad Hoc User List	The value in this field will limit the users from the view indicated above by the selected User List. The default setting allows ad hoc to any user. This can be added in as needed. If a different list of ad hoc users is needed by form, then a new Process ID will be required.
User Utilities	Blank by default
Events	Blank by default
Notifications	Blank by default

Approval Process setup

One or more Definition IDs can be added under a Process ID. The delivered GT Basic Process ID comes with Definition IDs to use for One Step through Nine Steps. If no approval is needed and the definition ID on the Form Setup Table is left blank, then the GT Basic –Zero Step is used.

Field	Value/Use
Clone Approval Process	This is used to create a new effective date to make changes to the existing Definition ID or to create a new Definition ID using the current one as a starting point. See details in the copy approval process section below.
Preview Approval Process	A view used to preview what the visualizer for this Definition ID would look like for an existing form.
Description	Text used to describe the Definition ID
Definition Criteria	At the Definition ID level this should be set to ‘always true’
Admin Role	Set to GT Eforms Administrator or other role that will act as an indicator for the administrator of this process
Status	‘Active’
Priority	This field is not used by the GT Framework
Default Process Definition	This field is not used by the GT Framework
User Auto Approval	See the the Optional Settings section below
Router to Requester	See the the Optional Settings section below
Include Requester	See the the Optional Settings section below
Stage	Stages include one or more paths/steps that occur in sequence
Stage Number	The sequence in which the stages occur
Stage Description	Text to describe the stage
Stage Level	Header or Line. Line-level approvals mean that a particular line in the stage should be present for each line-level row.
Paths	Paths are one or more steps that occur in parallel
Path Description	Text to describe the path
Path Source	Set to static. For details on using a dynamic path see Peoplebooks.
Path Details	Timeout options and ‘Skip Prior Steps for Requestor’ are configured here using the delivered AWE setup.
Path Criteria	This should be set to ‘always true’ or criteria can be set using the delivered PS page for when it should evaluate to true. Future development will be done to add an option of using GT Visual Ifs on the Form Type Table.
Steps	A step is visually represented by one box in the visualizer. Each step could require one or more approvals, but must share a User List / GT Roster. Steps occur sequentially.
Step Description	Displays text to describe the step. It should be unique for this Definition ID
Approver User List	Select the User List that should be used to determine the list of users who can act on this step. Set to G3UserListHook for all steps where the GT Roster functionality should be enabled.
Step Details	Configure Approver Requirements and Reviewers. See Optional Settings section below. Note: Reviewers are a way that you can indicate a user should view a form, but we generally recommend using an email notification or Worklist in the GT Notifications tab instead.
Step Criteria	Should match the following configuration for each step. This enables the use of GT Visual Ifs. When this is not set, delivered PS configuration can be used to skip a step based on certain logic.

Copy Approval Process

Optional Settings

Level	Setting	Description
Process ID	Ad Hoc Settings	The following is set in the standard GT delivered settings: Only users with the Admin Role set under the Definition ID can delete existing ad hoc steps added by another user. Any users that can see the visualizer can add new steps and paths The Request Information button is always turned on.
Process ID	Ad Hoc User List	This is the list of users who can be selected for ad hoc approval or review steps. It is shared for all Definition IDs under the Process ID.
Definition ID	Timeout Options	See Peoplebooks for details on configuring.
Definition ID	Take Action on Line Completion	Only applies to line-level. Allows steps in a line to progress further than others. If this field is unchecked, it would mean that all steps in the line approvals must be completed before any steps move.
Definition ID	Include Requester	Select to enable the user to insert the requester in the event the requester is not equal to the originator.
Definition ID and Step	User Auto Approval	Once an approver has indicated approval at one step, all subsequent steps where this user is included in the user list will be automatically stamped as approved. This can be set at the Definition ID level or only on certain steps.
Definition ID and Step	Route to Requestor	This setting takes priority over the Self Approval setting and is only relevant where the form requester is included in the list of approvers at 1+ steps. Because of this, you can use either Route to Requestor or Filter Requestor but not both. When checked the requester must manually approve steps even when Self Approval is selected. If there are other possible approvers at the step, it does not require that the requester is one of them. If this check box is not selected and the requester is included in a step as a possible approver, then the self-approval settings will be used.
Path	Skip Prior Steps for Requester	Skip all steps in this path prior to the highest step in the approval process that the requester can approver
Step	Self Approval	If the Requester is in the list of possible approvers at a step, the step will be stamped as approved as long as the criteria are met. Criteria can be set to ‘always true’ or based on data specific to the transaction, ‘user configured’. Clearing the check box means that Self Approval is never acceptable. Note: If the criteria are not met and no later step exists, the system inserts an additional step. This selection is then routed to the administrator.
Step	Filter Requester	This check box is only visible if Route to Requester is not selected. When this check box is selected, the requester’s user ID is filtered from the result set whenever it is encountered.
Step	Approvals required	Each step can require approval from some or all participants in the user list. This is often set to some with the number of Approvers Needed = 1, which means only one approval is needed before the process moves on to the next step.