PeopleSoft AWE - Comprehensive Interview Q&A

 

PeopleSoft AWE - Interview Q&A

Approval Workflow Engine: Core Components, Dynamic Approvers, Delegation, Troubleshooting & SQL

PeopleTools 8.50+ (EOAW) | 60+ Real-Time Q&As | 2025-26

SECTION 1 - AWE CORE CONCEPTS & ARCHITECTURE
Fundamentals
What is PeopleSoft AWE?	AWE (Approval Workflow Engine) is a PeopleTools framework introduced in PT 8.48 that enables configuration-driven approval routing without custom PeopleCode for every transaction. Functional users can manage workflows via online pages once initial developer setup is done.
How does AWE differ from classic PeopleSoft Workflow?	Classic Workflow uses PeopleCode-heavy, developer-maintained business processes. AWE is configuration-driven, reusable across modules, supports dynamic approver resolution, delegation, and ad hoc routing - all managed via online pages without code changes.
What are the prefix differences between AWE versions?	PT 8.48/8.49 (apps 9.0) uses PTAF prefix. PT 8.50+ (apps 9.1+) uses EOAW prefix. All objects, tables, and application classes were renamed. PTAF code still compiles in 8.50 but is no longer active.
What is the AWE processing flow?	User submits transaction → AWE reads Transaction Registry → identifies Process Definition → evaluates Criteria → resolves User Lists → routes to Worklist/Email → approver acts (Approve/Deny/Pushback/Hold) → Event Handler fires → transaction status updates.
What are the key AWE components?	Transaction Registry (EOAW_TXN_REGISTRY), Process Definition (EOAW_PRCS), Stage, Path, Step, User List (EOAW_USER_LIST), Criteria, Event Handler Application Class, Notification Template, and Approval Monitor.
Process Definition Hierarchy
What is a Stage in AWE?	A Stage is the top-level grouping of approval logic within a Process Definition. Multiple stages execute sequentially. Each stage contains one or more Paths.
What is an Approval Path?	A Path contains one or more Steps. Multiple Paths within a Stage execute in parallel. Paths can be Static or Dynamic.
What is an Approval Step?	A Step is a single approval level within a Path. It references a User List that resolves who must approve. Steps execute sequentially within a Path.
What is the difference between Static and Dynamic paths?	Static Path: approvers are fixed at configuration time, typically using Role-based User Lists. Dynamic Path: approver chain is determined at runtime using SQL or Application Class User Lists based on transaction data.
What step approval modes are available?	Any Single Approver Required (one approver from the list suffices), All Approvers Required (all must act), and Percentage Required (configurable threshold of the list must approve).
Transaction Registry
What is the Transaction Registry?	The central metadata store (EOAW_TXN_REGISTRY) that links a PeopleSoft transaction (e.g., ePro Requisition) to its Event Handler, Header Record, XREF Record, and Process Definition. Every transaction registered with AWE must have an entry here.
What is a Header Record in AWE?	The primary transaction record whose keys uniquely identify the transaction instance being approved (e.g., PS_REQ_HDR for requisitions). It is specified in the Transaction Registry.
What is an XREF record?	Cross-reference record (e.g., PS_REQ_APPR_XREF) that stores AWE tracking columns (EOAWTHREAD_ID, EOAWSTEP_STATUS, etc.) alongside transaction keys. It links the transaction to the AWE thread.
What is EOAWTHREAD_ID?	A system-generated unique identifier for each approval thread instance. It links all AWE tables (EOAW_HDR, EOAW_STEP, EOAW_STEPINST, EOAW_USERINST) to a specific approval run for a transaction.
Can the same transaction be registered in both AWE and legacy Workflow grids?	No. The AWE/Delegation grid and the legacy Workflow Transactions grid are mutually exclusive. Registering in both causes a system error.
Notification & Email
How does AWE send notifications?	Via Notification Templates (EOAW_NOTIFY_DEFN) configured in Configure Transactions. Templates define trigger events (On Submit, On Approve, On Deny, On Pushback, Escalation) and route to approvers via Worklist entries and/or SMTP email.
What permission lists are required for AWE?	WEBLIB_PTAF and WEBLIB_EOAW must be added to applicable permission lists with Full Access. The AWE Administrator role uses the HCCPSCAW1010 permission list.
SECTION 2 - USER LISTS
User List Types
What is a User List?	A User List (EOAW_USER_LIST) defines who the approvers are for a Step. It can be resolved via Role, SQL Definition, Application Class, or a fixed User ID.
What are the four User List source types?	1) Role - PS security role assigned to users. 2) SQL Definition - custom SQL returning OPRID. 3) Application Class - custom PeopleCode class extending UserListBase. 4) User ID - hardcoded single user.
When should you use a Role-based User List?	When approvers are static or change rarely, and are already managed via PS security roles. Simple, no code required. Functional users can maintain via User Profile.
When should you use a SQL User List?	When approvers are determined by data-driven rules that can be expressed in a single SQL query returning OPRID - e.g., fetching manager based on REPORTS_TO field, or budget approver by department.
When should you use an Application Class User List?	When approver logic is complex, requires looping, multi-level hierarchy traversal (walk-up supervisor chain), or dynamic population of an array. Required for Dynamic Paths.
What class must an Application Class User List extend?	EOAW_CORE:DEFN:UserListBase (or PTAF_CORE:DEFN:UserListBase for 9.0 apps). The class must implement the GetUsers(&bindrec As Record) method returning an array of OPRIDs.
How does AWE call an Application Class User List twice?	AWE calls GetUsers once to populate approvers when the step activates, and again during each approval action. On the second call, return an empty array if all approvers have already been set to avoid re-adding users.
What is the key behavior of Dynamic Approver User Lists with multiple levels?	The User List should return only the next approver in the chain, not all approvers at once. AWE re-calls the list after each approval action to resolve the subsequent approver dynamically.
SECTION 3 - CRITERIA (PROCESS ROUTING RULES)
What is AWE Criteria?	Criteria determines which Process Definition (or Stage/Path) applies to a given transaction at runtime. Evaluated against transaction data fields to route to the correct approval path.
What types of Criteria are supported?	1) Field-based - compare record.field to a value. 2) SQL - custom SQL returning True/False. 3) Application Class - PeopleCode class extending CriteriaBase implementing Check() method returning Boolean.
What class must an Application Class Criteria extend?	EOAW_CRITERIA:DEFINITION:CriteriaBase (or PTAF_CRITERIA:DEFINITION:CriteriaBase for 9.0). Constructor must accept a Record parameter, call %Super with criteria ID, and implement Check(&bindRec As Record) Returns boolean.
Where is Criteria configured?	Within the Process Definition (EOAW_PRCS), at Stage or Path level. Criteria can also be used in Configure Transactions (EOAW_TXN_CONFIG) to conditionally trigger notifications.
What happens if no Criteria matches at runtime?	If no matching process is found, an error is thrown or the transaction bypasses approval depending on the 'Notify Admin on No Approvers' configuration. The Administrator is notified if that flag is enabled.
SECTION 4 - EVENT HANDLER APPLICATION CLASS
What is an AWE Event Handler?	A PeopleCode Application Class registered in the Transaction Registry that AWE calls during key lifecycle events of the approval process. It bridges AWE actions back to the transaction.
What are the primary Event Handler methods?	OnProcessLaunch (called when approval starts), OnApprove (called on each approval), OnDeny (called on denial), OnFinalApprove (called when all approvals complete), OnPushback (called on pushback), OnHold/OnRelease, OnStepComplete, OnProcessComplete.
What must the Event Handler class extend?	EOAW_CORE:TXN_DEFN:AppEventHandler (or PTAF_CORE for 9.0). Only implement methods that contain business logic - do not implement unused methods.
What does OnFinalApprove typically do?	Updates the transaction status to Approved, calls Component Interface or executes Application Engine to finalize the business action (e.g., budget-check a requisition, activate a job change).
What does OnDeny typically do?	Sets transaction status to Denied, optionally sends notification to originator, and may allow resubmission depending on business rules.
What is the LaunchManager?	EOAW_CORE:TXN_MANAGER:LaunchManager - PeopleCode class used to initiate an AWE approval process for a transaction. Called typically from SavePostChange or a custom submit button FieldChange event.
What is the ApprovalManager?	EOAW_CORE:TXN_MANAGER:ApprovalManager - used to render the Approval Monitor (status display) on the transaction page, showing current approvers, history, and pending actions.
SECTION 5 - DYNAMIC APPROVERS
What makes an approval path Dynamic?	A Dynamic Path uses an Application Class User List. The Path Type is set to 'Dynamic' in the Process Definition. AWE re-resolves approvers at each step by calling the Application Class at runtime.
How is a walk-up supervisor chain implemented?	Use Application Class User List with a CONNECT BY PRIOR or self-join SQL query against PS_EMPLOYMENT or PS_JOB. At each invocation, return only the immediate supervisor. AWE calls the list repeatedly until the array returned is empty.
How do you prevent AWE from infinite-looping in dynamic resolution?	Track a flag or use a global variable to detect when the list has been called a second time (approver already activated) and return an empty array on the second call.
Can dynamic paths be created at runtime?	No. Paths are fixed at configuration. You can simulate multiple approvers on a single dynamic step by returning multiple OPRIDs from the User List array in one call, then returning empty on subsequent calls.
What is 'Check Authorization' in Path Definition?	When enabled, AWE checks whether the resolved approver has sufficient authority (e.g., signing limit). If not authorized, the system either skips that approver (Skip Unauthorized Users) or escalates based on path configuration.
What is Self-Approval in AWE?	When the transaction submitter is also on the approver list, Self-Approval setting determines behavior: Allow (counts as an approval), Deny (skips and requires another approver), or Skip (does not count the submitter).
What is Ad Hoc routing?	Allows any approver to insert additional approvers or reviewers mid-process outside the pre-configured path. Controlled by the 'Allow Ad Hoc' flag in the Process Definition. Ad hoc approvers do not affect the configured path.
What is Pushback in AWE?	The ability for an approver to send the transaction back to a previous step or the originator. The OnPushback event fires. The transaction re-enters the approval cycle from the pushed-back step.
SECTION 6 - DELEGATION FRAMEWORK
Delegation Concepts
What is PeopleSoft Delegation?	Delegation allows a user (Delegator) to grant approval authority to another user (Proxy/Delegate) for a defined period. The proxy can approve transactions on behalf of the delegator via a delegated role.
How is a transaction enabled for Delegation?	Via Set Up HRMS > Common Definitions > Delegation > Configure Transactions. You specify the AWE Process ID, delegate role, and the approval component the proxy uses to act.
What is the naming convention for delegate roles?	Oracle recommends the prefix 'Delegate_' followed by the transaction name (e.g., Delegate_REQ_APPR). Custom naming standards (e.g., ZZ_HR_DELEGATE_REQ_APPR) are also common.
How does AWE know a user is acting as a proxy?	AWE uses the HCSC_USER_UTILITIES Application Package (UserUtilities path) configured in the Transaction Configuration's User Utilities section to check delegation status at runtime.
What must be added to Transaction Configuration for Delegation?	The HCSC_USER_UTILITIES application package and UserUtilities path must be added under User Utilities in Enterprise Components > Approvals > Approvals > Transaction Configuration.
Can the same transaction be in both AWE Registry and Delegation setup?	Yes, but the AWE Registry entry and Delegation entry must be consistent. A transaction registered in the legacy Workflow Transactions grid cannot use the AWE Delegation framework.
Delegation Administration
How does a user set up delegation?	Via the Manage Delegation self-service pages (HCSC_SS_DELEGATE). The delegator selects: Proxy user, delegation period (From/To dates), and specific transactions to delegate.
What batch process activates/inactivates delegations?	The Manage Delegation batch process (HR_APPROVE / HCSC_DELEGATION AE) runs on a schedule to activate upcoming delegations and expire past ones. Delegation becomes effective when status changes to Active.
What happens when delegation expires mid-approval?	If a delegation expires while a transaction is pending the proxy's action, the transaction may become stuck. The AWE Administrator must reassign or manually process the transaction. The batch process can cause failures on old stuck transactions.
What tables store delegation data?	HCSC_DLGT_TXN (delegation transaction setup), HCSC_DELEGATIONS (active delegations), HCSC_DLGT_HIST (delegation history). These are the key tables for troubleshooting delegation issues.
What is the Workflow Transactions grid vs AWE Delegation Transactions grid?	Mutually exclusive grids on the Register Transactions page. Legacy workflow transactions go in the Workflow grid; AWE-enabled transactions with delegation go in the AWE/Delegation grid.
SECTION 7 - KEY AWE DATABASE TABLES
EOAW_HDR	Approval instance header. One row per transaction submitted. Stores EOAWTHREAD_ID, process status, submission date, submitter OPRID, and transaction keys.
EOAW_STEP	Stores each defined step within an active approval thread. Links to EOAW_HDR via EOAWTHREAD_ID.
EOAW_STEPINST	Step instance - tracks the status (Pending, Approved, Denied) of each step for a given thread. Updated as approvers act.
EOAW_USERINST	User instance - one row per approver per step per thread. Stores OPRID, action taken, action date, comments, and whether user is ad hoc.
EOAW_PRCS	Process Definition configuration table. Stores all defined approval processes with their stages, paths, and steps.
EOAW_USER_LIST	User List definitions - stores list name, type (Role/SQL/App Class), and resolution parameters.
EOAW_TXN_REGISTRY	Transaction Registry - maps each registered transaction to its Event Handler, Header Record, XREF record, and Process Definition.
PSWORKLIST	Standard PeopleSoft Worklist table. AWE creates Worklist entries here for pending approver actions. INSTSTATUS = 1 (Active), 3 (Worked).
HCSC_DELEGATIONS	Active delegation records. Stores delegator OPRID, proxy OPRID, transaction list, start/end dates, and delegation status.
SECTION 8 - TROUBLESHOOTING WITH SQL
Identifying Stuck / Pending Approvals
How do you find all pending AWE transactions for a user?	SELECT H.EOAWTHREAD_ID, H.EOAW_TXN_NAME, U.OPRID, U.EOAW_ACTION FROM PS_EOAW_HDR H JOIN PS_EOAW_USERINST U ON H.EOAWTHREAD_ID = U.EOAWTHREAD_ID WHERE U.OPRID = 'USERNAME' AND U.EOAW_ACTION = ' '  -- blank = pending ORDER BY H.DTTM_CREATED DESC;
How do you check approval thread status for a specific transaction?	SELECT H.EOAWTHREAD_ID, H.EOAW_STATUS, H.DTTM_CREATED, S.EOAW_STEPNAME, S.EOAW_STEP_STATUS, U.OPRID, U.EOAW_ACTION, U.DTTM_STAMP FROM PS_EOAW_HDR H JOIN PS_EOAW_STEP S ON H.EOAWTHREAD_ID = S.EOAWTHREAD_ID JOIN PS_EOAW_USERINST U ON S.EOAWTHREAD_ID = U.EOAWTHREAD_ID WHERE H.EOAWTHREAD_ID = 'THREAD_ID_HERE';
How do you find transactions stuck with no pending approvers?	SELECT H.EOAWTHREAD_ID, H.EOAW_TXN_NAME, H.EOAW_STATUS FROM PS_EOAW_HDR H WHERE H.EOAW_STATUS = 'P' AND NOT EXISTS (   SELECT 1 FROM PS_EOAW_USERINST U   WHERE U.EOAWTHREAD_ID = H.EOAWTHREAD_ID   AND U.EOAW_ACTION = ' ' );
How do you find active Worklist entries for AWE approvals?	SELECT W.OPRID, W.INSTANCEID, W.INSTSTATUS, W.DTTM_CREATED, W.ACTIVITYNAME, W.BUSPROCNAME FROM PSWORKLIST W WHERE W.INSTSTATUS = 1  -- 1=Active, 3=Worked AND W.BUSPROCNAME LIKE 'EOAW%' ORDER BY W.DTTM_CREATED DESC;
How do you identify AWE errors / failed threads?	SELECT EOAWTHREAD_ID, EOAW_TXN_NAME, EOAW_STATUS, DTTM_CREATED, EOAW_PROC_ID FROM PS_EOAW_HDR WHERE EOAW_STATUS IN ('E','F')  -- E=Error, F=Failed ORDER BY DTTM_CREATED DESC;
Delegation Troubleshooting
How do you check active delegations for a user?	SELECT OPRID, PROXY_OPRID, TXNNAME, FROM_DATE, TO_DATE, DLGT_STATUS FROM PS_HCSC_DELEGATIONS WHERE OPRID = 'DELEGATOR_ID' AND DLGT_STATUS = 'A'  -- A=Active AND FROM_DATE <= SYSDATE AND TO_DATE >= SYSDATE;
How do you check what transactions are configured for delegation?	SELECT TXNNAME, DLGT_ROLE_NAME, MENUNAME, BARNAME, ITEMNAME FROM PS_HCSC_DLGT_TXN ORDER BY TXNNAME;
How do you find delegation history?	SELECT OPRID, PROXY_OPRID, TXNNAME, FROM_DATE, TO_DATE, DLGT_STATUS, DTTM_STAMP FROM PS_HCSC_DLGT_HIST WHERE OPRID = 'USERNAME' ORDER BY DTTM_STAMP DESC;
User List & Approver Troubleshooting
How do you check which approvers are mapped to a Role-based User List?	SELECT U.OPRID, U.EMPLID, R.ROLEUSER FROM PSOPRDEFN U JOIN PSROLEUSER R ON U.OPRID = R.ROLEUSER WHERE R.ROLENAME = 'YOUR_ROLE_NAME' AND U.ACCTLOCK = 0;  -- only active, unlocked users
How do you trace which thread_id belongs to a specific transaction key?	-- Replace with your XREF table and key field SELECT X.EOAWTHREAD_ID, X.BUSINESS_UNIT, X.REQ_ID, X.EOAW_STEP_STATUS FROM PS_REQ_APPR_XREF X  -- replace with your xref WHERE X.BUSINESS_UNIT = 'US001' AND X.REQ_ID = 'REQ0001234';
How do you find the active step for a thread?	SELECT EOAWTHREAD_ID, EOAW_STEPNAME, EOAW_STEP_STATUS, DTTM_CREATED FROM PS_EOAW_STEP WHERE EOAWTHREAD_ID = 'YOUR_THREAD_ID' AND EOAW_STEP_STATUS = 'P'  -- P=Pending ORDER BY EOAW_STEPSEQ;
Manual Fixes / Admin SQL
How do you manually mark a worklist entry as worked (emergency fix)?	-- USE WITH CAUTION: development/emergency only UPDATE PSWORKLIST SET INSTSTATUS = 3  -- 3=Worked WHERE OPRID = 'USERNAME' AND INSTSTATUS = 1;  -- Then reset XREF and header as needed DELETE FROM PS_YOUR_XREF_TABLE WHERE [transaction keys]; DELETE FROM PS_EOAW_HDR WHERE EOAWTHREAD_ID = 'THREAD_ID';
How do you check the AWE Transaction Registry entries?	SELECT EOAW_TXN_NAME, EOAW_TXN_DESCR, EOAW_HDR_RECNAME, EOAW_XREF_RECNAME, EOAW_PROC_ID, EOAW_EVNT_HNDLR FROM PS_EOAW_TXN_REGISTRY ORDER BY EOAW_TXN_NAME;
How do you verify all configured Process Definitions?	SELECT EOAW_PROC_ID, EOAW_PROC_DESCR, EOAW_TXN_NAME, EFFDT, EFF_STATUS FROM PS_EOAW_PRCS_DEFN WHERE EFF_STATUS = 'A' ORDER BY EOAW_PROC_ID;
SECTION 9 - ADVANCED & REAL-TIME SCENARIO QUESTIONS
A transaction is submitted but no worklist entry is created. What do you check?	1) Verify Transaction Registry is complete. 2) Check XREF record has EOAWTHREAD_ID populated. 3) Confirm Event Handler OnProcessLaunch is firing. 4) Validate User List returns at least one OPRID. 5) Check PS_EOAW_HDR for the thread - if missing, LaunchManager was never called. 6) Review PeopleSoft Notification Config for worklist routing.
An approver says they don't see the transaction in their Worklist. What do you investigate?	1) Query PSWORKLIST for INSTSTATUS=1 for that user. 2) Check EOAW_USERINST for the approver's OPRID. 3) Verify Role assignment if Role-based User List. 4) Confirm user is not locked (ACCTLOCK=0 in PSOPRDEFN). 5) Check if delegation is in effect (proxy may have received it instead).
AWE is routing to the wrong approver. What are the causes?	1) User List SQL returning incorrect OPRID. 2) Process Definition Criteria matching wrong definition. 3) Stale data in EOAW_USERINST from previous stuck thread. 4) For dynamic lists, check whether the class is returning all approvers at once instead of one at a time.
How do you handle a scenario where an approver is terminated mid-approval?	Use the AWE Administration pages to reassign the pending step to another approver. Alternatively, update the User List to exclude terminated employees (join to PS_EMPLOYMENT/PS_PERS_EMPL_TYPE checking EMPL_STATUS). Add admin monitoring for terminated-user pending steps via SQL alert.
What is the difference between Reassign and Pushback?	Reassign transfers the pending step to a different approver without returning to the originator. Pushback sends the transaction back to a previous step or the submitter, restarting that step's approval cycle.
How do you implement line-level approval in AWE?	Configure the Process Definition at line level (set Approval Level to Line in Configure Transactions). Implement OnLineApprove and OnLineComplete methods in the Event Handler. Add line-level keys to the XREF record.
What causes 'No approval process registered' error?	The EOAW_TXN_NAME passed in the LaunchManager call does not exist in EOAW_TXN_REGISTRY. Also occurs after upgrade from 9.0 to 9.1 when PTAF data was not migrated to EOAW tables.
After upgrade from PT 8.49 to 8.50+, AWE stops working. Why?	All PTAF objects are renamed to EOAW. Custom Application Classes referencing PTAF_CORE must be updated to EOAW_CORE. Transaction Registry and Process Definition data in PTAF tables are not auto-migrated to EOAW tables - manual data migration is required.
How do you implement escalation in AWE?	Escalation is configured at the Path level via Path Details. Set escalation interval (hours/days) and designate the escalation recipient (via User List). AWE automatically sends reminders and can reassign if no action is taken by the deadline.
How do you test AWE without re-submitting the real transaction?	Use the AWE Approval Monitor admin pages to step through or reassign. For unit testing User Lists, call the Application Class directly from App Designer PeopleCode Tester. For SQL User Lists, execute the SQL directly in PS Query with bind values matching your test transaction.

Note: SQL queries shown use Oracle/PeopleSoft naming conventions. Replace table aliases, XREF names, and key fields with your implementation's actual object names. PTAF prefix applies to PeopleTools 8.48/8.49 (apps 9.0); EOAW prefix applies to PeopleTools 8.50+ (apps 9.1+).