This appendix lists embedded workflows in Oracle E-Business Suite, as well as Oracle's support policy towards the customization of embedded workflows, events, and subscriptions.
This appendix covers the following topics:
You can use Oracle Workflow to customize the predefined workflow processes listed below. A full description of each workflow is documented in its respective product's User's Guide or Implementation Guide, if one is available.
Note: Some Oracle E-Business Suite products use the Account Generator feature to dynamically create accounting flexfield combinations. The Account Generator has generic predefined workflow functions that each Oracle E-Business Suite product uses in its own predefined Account Generator process. The Account Generator processes for each product are not listed in this section, but are documented in more detail in each respective product's User's Guide. A general discussion of the Account Generator feature is also available in the Oracle E-Business Suite Flexfields Guide.
Related Topics
Oracle Workflow Support Policy
Advanced Planning Exception Message Process - Sends notifications to suppliers, customer contacts, or internal personnel that inform them of advanced planning exceptions and lets the recipients initiate appropriate action to correct the planning exception.
Error Notifications for Excel Import of Forecast/Supply Process - This process sends notifications when you conduct flat file or XML loads to Oracle Collaborative Planning and when loading a supply/demand flat file or loading an XML file adhering to 000_sync_forecast_001.dtd.
User Defined Exception Workflow Process - In this process, a user-defined custom exception is run and generates a number of results (exceptions). For each generated exception, a notification is sent to the recipient of the exception. The workflow is called for each generated exception. The recipients and subject of the notification can be specified in the Custom Exceptions recipients page.
Supply/Demand Mismatch Process - This process is the Supply Chain Event Manager Exceptions notification workflow.
Oracle Collaborative Planning VMI Replenishment Process - This process is the workflow for the VMI replenishment engine.
Start ASCP Engine Process - This process facilitates the automation of launching an ASCP plan after receiving an order forecast or supply commit from Oracle Collaborative Planning.
DP Receive Forecast Process - This process facilitates receiving forecasts from Oracle Demand Planning into Oracle Collaborative Planning.
Publish Order Forecast Process - This process facilitates the automatic launch of the Publish Order Forecast program from the Planner Workbench.
Publish Supply Commit Process - This process facilitates the automatic launch of the Publish Supply Commit program from the Planner Workbench.
Start Receive Supplier Capacity Process - This process facilitates the automatic start of the Receive Supplier Capacity program when a supply commit is loaded into Oracle Advanced Supply Chain Planning.
Start SCEM Engine Process - This process facilitates the automatic launch of the supply chain event manager when an order forecast or supply commit is loaded into Oracle Collaborative Planning.
MSD Demand Planning Cycle Process - The MSD Demand Planning Cycle manages all background processing during a Demand Planning cycle. It is made up of several stages, each of which initiates a specific workflow process to govern a task that is performed during that stage. Each stage is initiated from the Demand Planning Administrator page. Notifying the administrator and user community of relevant processing status as the workflow progresses through its many stages is a central benefit.
The Demand Planning processing cycle is made up of the following five stages, which correspond to processes:
Downloading data from the Planning Server - Manages the transfer and transformation of data from the Demand Planning Server to the Express Server Demand Planning Engine for analytic processing.
Populating measures - Runs the statistical forecast and populates each measure that has been defined.
Distributing to planners - Makes data available to the community of demand planners and notifies each planner that their data is ready.
Collecting and consolidating data from demand planners - Collects submitted data from demand planners and consolidates data in the Demand Planning Engine. This process can iterate until the date you specify to end the collection period.
Uploading the consolidated data to the Planning Server - Transfers transformed data back to the Planning Server.
At any time during the Demand Planning processing cycle, the Demand Planning Administrator may choose to run a special process called "Collect Available Submissions Now." This process collects any waiting submissions of data for review prior to the end of the cycle.
The Demand Planning Administrator may choose to run a master workflow process called ODP Master that manages all five stages together by running a concurrent request to launch and manage this master process. This concurrent request is called "Demand Planning Engine Master Workflow Process."
Allocated ATP Process - Sends notification to planners if there was any stealing between different supply sources to satisfy an Order Promising request or if the Order Scheduling process failed.
Oracle Application Object Library provides a set of standard function activities that you can use to incorporate concurrent manager processing into any Oracle E-Business Suite workflow process. The standard function activities are associated with the Concurrent Manager Functions item type. See: Concurrent Manager Standard Activities.
The following Oracle Common Application Components modules include predefined workflows.
JTF Calendar Workflows - Tracks and routes calendar requests to the Calendar Administrator for new group and public calendar approvals and to Group Calendar Administrators for existing group calendar subscription approvals. The process also sends invitations for appointment invitees and attendees.
JTF Task Reminder - Picks up appointment reminders for scheduled appointments. For example, if the user selects "15 minutes Before" from the Remind Me drop-down list while creating an appointment, then that user receives a workflow notification 15 minutes prior to the start of the scheduled meeting.
Reactive Escalation Notification Workflow - Sends notifications to inform the escalation owner, the owner's manager, and optionally any customer or employee identified in the escalation document when an escalation document is created, or when certain document attributes such as status, level, owner, and target date are updated.
Business Rule Monitor Main Process - This process services the Business Rule Monitor looping workflow, which in turn checks all the active business rules and identifies whether any rule has been violated.
Business Rule Monitor Task Process - This process is used only when the Business Rule Monitor Main Process identifies a violated business rule that is related to a Task object. The Business Rule Monitor Task process services the subsequent activities based on the workflow information identified for the rule. For example, if the Escalate a Task (notification only) workflow is selected for a business rule, then a workflow notification will be sent to the person identified in the workflow attributes window.
Business Rule Monitor Service Request Process - This process is similar to the Business Rule Monitor Task process, except that it is used only when the Business Rule Monitor Main Process identifies a violated business rule that is related to a Service Request object.
Business Rule Monitor Defect Process - This process is similar to the Business Rule Monitor Task process, except that it is used only when the Business Rule Monitor Main Process identifies a violated business rule that is related to a Defect object.
Workflow - Task Manager - Task Manager uses the Workflow - Task Manager process to send notifications to inform personnel when tasks are created or changed.
Task Manager supports sending notifications to groups or teams. If a task is assigned to a group or team, then the workflow process will send a separate workflow notification to each member of the group, rather than sending only one notification to the e-mail address listed for the group.
Notifications can be sent either automatically for both the HTML and Forms versions of Task Manager, or manually for the Forms version only.
Manual Workflow Notifications (Forms only) - After a task is created with owner and assignee information, click the Launch Workflow button in the Tasks window to manually send notifications to the owner and assignees about task creation or updates.
Automatic Workflow Notifications - Workflow notifications can be automatically sent if one of the following conditions is met:
The Auto Notification check box for a task is selected in the Forms-based Tasks window before saving the task.
The Notify check box is selected in the HTML-based Create Task window.
The Notification check box is selected in the Task Types setup window.
If automatic workflow notifications are enabled, task workflow notifications are automatically sent in the following cases.
When a task is created or deleted, the owner and all assignees will receive notifications.
When a task is reassigned to a new owner, the old and new owners will receive notifications.
When the assignees for a task are changed, whether by adding, reassigning, or deleting, the owner and the old and new assignees will receive notifications.
When updates are made to the task status, priority, type, and planned, scheduled, or actual start and end dates, the owner and all assignees will receive notifications.
When the task owner updates his or her status, the owner and all assignees will receive notifications.
If you do not want to use the default workflow process for Task Manager, you can define a new workflow process using Oracle Workflow and assign your custom workflow to a task type.
JTF Calendar Workflows - Tracks and routes relevant workflow notifications to an appointment owner when an invitee accepts or rejects an invitation.
JTF Task Reminder - Picks up appointment reminders for scheduled appointments. For example, if the user selects "15 minutes Before" from the Remind Me drop-down list while creating an appointment, then that user receives a workflow notification 15 minutes prior to the start of the scheduled meeting.
Oracle XML Gateway leverages Oracle Workflow to publish and subscribe to application business events of interest in order to automatically trigger message creation or consumption. Seeded Workflow functions are provided for use in Workflow processes to interact directly with the XML Gateway Execution Engine to generate outbound or to consume inbound messages. The outbound messages generated by the Execution Engine are made available to the downstream Workflow activity for processing. The Execution Engine consumes the inbound messages passed to it by a Workflow process.
Two item types are delivered with the XML Gateway: the XML Gateway Standard Item Type and the XML Gateway Error Processing Item Type.
XML Gateway Standard Item Type - The XML Gateway Standard Item Type includes the Raise Document Delivery Event, which is used to raise a business event from an existing Workflow process. This allows you to seamlessly integrate your existing Workflow process with Oracle XML Gateway to create an outbound XML message. The functions included with the XML Gateway Standard Item Type are Consume XML Document, Generate XML Document, Generate Trading Partner XML Document, Send Document, Transform XML, and Transaction Delivery Required.
Configure the seeded events and event subscriptions delivered by the Oracle E-Business Suite for pre-built XML messages in support of Business-to-Business or Application-to-Application integration.
XML Gateway Error Processing Item Type - The XML Gateway Error Processing Item Type contains error handling processes to manage errors detected by the Oracle Workflow Business Event System or Oracle XML Gateway. The error processes are: Default Error Process, ECX Engine Notification Process, ECX Main Error Process, ECX Main Inbound Error Process, ECX Main Outbound Error Process, Error Handling for Inbound Messages, and Error Handling for Outbound Messages.
The XML Gateway Error Processing Item Type supports two event activities: Receive Error and Receive Send Notification Event. The Receive Error event is used by the XML Gateway to indicate that the XML Gateway execution engine has detected an error. The Receive Send Notification Event is used to indicate that the execution engine has identified a need to send a notification for errors related to an inbound process.
Oracle Workflow error handling provides active error notification to the XML Gateway System Administrator or Trading Partner with support for the Workflow retry and reprocess features. The functions provided by the XML Gateway Error Processing Item Type are: ECX Reprocess Inbound, ECX Resend Outbound Message, Get ECX In Error Details, Get ECX Out Error Details, Get System Administrator Role, and Get Trading Partner Role.
For more information, see: Oracle XML Gateway User's Guide.
BIS Management by Exceptions Process - This generic workflow process is a template for BIS customers to use as part of their Performance Management Framework. When actual performance does not meet expected performance, this process sends a basic corrective action notification with an embedded report URL. All other processes under the OBIS Corrective Action item type are similar to this generic process.
Process Manufacturing Inventory Turns Process - Sends notifications to the designated responsibilities whenever the actual values of the inventory turn do not fall within the targeted values defined in the Inventory Turn Report. The Inventory Turn Report is part of Process Manufacturing BIS.
Fulfillment Header, Fulfillment Line, Work Item, Fulfillment Action, and Message Error Workflows - These workflow processes are initiated whenever Oracle Service Fulfillment Manager is invoked to fulfill a network or provisioning request. The header workflow identifies the fulfillment line items and invokes child workflows for each one. Similarly, the line workflows spawn work item workflows, which in turn spawn fulfillment action workflows that actually perform the provisioning tasks. In case of any errors in processing fulfillment messages, the Message error workflows are spawned. Certain types of interaction between Order Management and Installed Base modules use Oracle Service Fulfillment Manager.
XNB Entity Flows - This workflow includes the Account Publish process, Account Update process, Sales Order Publish process, Group Salesorder Publish process, and Item Publish process. These processes are initiated whenever entities related to Oracle Telecommunications Billing Integrator, such as accounts, sales orders, and items, are to be published to a third party billing application. Each process generates an XML message and enqueues it to a JMS-compatible queue.
The Account Publish process and Group Salesorder Publish process are initiated from the OM Order Header workflow, and the Sales Order Publish process is initiated from the OM Order Line workflow. These processes require an implementation step. For more information, please see the Oracle Telecommunications Billing Integrator Implementation Guide.
The Item Publish process is initiated by the Telecommunications Billing Integrator Items Publish concurrent program.
The Account Update process is initiated whenever a party or account is updated in Oracle Trading Community Architecture and the related events are selected using the Oracle Telecommunications Billing Integrator Account Update Events window.
Service Request Creation Workflow - An event can be set up against a service contract line so that when the associated condition has been met, this workflow can be used to automatically create a service request. A notification containing details of the service request will also be created, which can be viewed from the inbox of the contracts launchpad.
Service Contracts Negotiation Workflow - This workflow is launched when a Service, Extended Warranty or Subscription contract is created through the Authoring, Copy Contract, or Renewals process.
If the contract is newly created through Authoring or Copy functionality, the renewal process type is always set to manual.
For renewal contracts, the workflow first determines the renewal process type. The type can be manual, online, or evergreen. The workflow then routes the contract according to the renewal type.
For a manual renewal, the contract is routed to the sales rep. The sales rep can manually activate the contract or submit the contract for online acceptance.
For an online renewal, the contract is routed to the customer. The process runs a QA check for the contract, derives a communication template set to use for generating a quote (draft contract) and cover letter, and then e-mails the customer. The customer logs into an online portal and reviews the contract. The customer can accept or reject the renewal contract and also has the option to request assistance from a sales rep. The customer can choose to pay using various available payment options such as PO, Commitment, Credit Card, and so on. After the customer accepts the quote, a notification is sent to the contract salesperson or a generic Help desk contact. Depending on the Approval Type setting, the contract is automatically submitted for approval or sent to the salesperson to review and activate the contract. If the customer accepts the contract quotation and decides to pay the contract amount using a PO, the workflow sends a notification to the contract salesperson to review before activating the contract.
If approval is required for an evergreen contract, the workflow routes the contract to an approver. If approval is not required, the workflow activates evergreen contracts. The negotiation status is updated at each step to reflect the state the contract is in at a particular time. The workflow also sends alerts and notifications to customer contacts and internal contract administrators during the contract negotiation.
Approval Workflow - This workflow is launched from within the negotiation workflow process when a contract is submitted for internal approval. The process derives the internal approver using the approvals management engine and routes the contract to the approver for a response.
Installed Base Transactions Notification Workflow - If the system profile 'OKS: Enable Install Base Integration Messages' is set to 'Yes', this workflow will send notifications to the user identified in the system profile 'OKS: User name to Send Install Base Messages' during certain transactions. These include when a new item instance is created, when it is terminated, when it is transferred to a new owner, when it is replaced or returned, or when the quantity of items instances are split.
Deliverables Notification Workflow - Users can create deliverables in the contract terms library or in the Contract Repository or during the contract authoring process. Users can also enable notifications to be sent to a user or group of users for various events. This workflow handles sending out notifications for the following events:
When a deliverable becomes overdue
Reminder notifications to perform the deliverable prior to the due date
When the status of a deliverable is updated
Contract Clause Approval Workflow - Users can create clauses in the contract terms library and submit them for approval. This workflow sends notifications to the designated approver when the users submit clauses requesting approval. In addition, this workflow also handles the following scenarios:
Send a notification to the contract administrator when the clause is approved or rejected
Send a notification to the contract administrators of local organizations when a global clause becomes available for adoption or when a global clause is automatically adopted in a local organization
Contract Template Approval Workflow - Users can create contract templates in the contract terms library and submit them for approval. This workflow sends notifications to the designated approver when users submit contract templates requesting approval. In addition, this workflow also sends a notification to the contract administrator when a contract template is approved or rejected.
Repository Contracts Approval Workflow - Sends a notification to designated approvers when a contract is submitted for approval in the Contracts Repository. The approvers as well as approval rules for contracts created in the Contracts Repository are set up in Oracle Approvals Manager (AME).
Repository Contracts Expiration Notifications Workflow - If a contract created in the Contracts Repository has an expiration date, users can set up a notification to be generated prior to the expiration date. Based on the number of days set up, this notification is generated and sent to a user role defined in the contract. Notifications are sent to all users who perform this role.
Oracle Enterprise Planning and Budgeting (EPB) lets you define and run business processes, which are groups of tasks that the user can select and order for planning and budgeting purposes. These business processes correspond to and are run by workflow processes.
The Business Process Scheduler process defined in the EPB Business Process Scheduler item type controls the running of Oracle Enterprise Planning and Budgeting business processes, which are groupings of workflows. These Oracle Enterprise Planning and Budgeting task workflows are defined in a different item type, EPB Business Process, and can be selected and ordered in a flexible configuration for any business process definition.
Review Business Process - Sends a response notification to specified users requesting the parameters for the business process to be reviewed before allowing the business process run to continue. The actions permitted for this process are Continue Processing or Pause Processing.
Load Data From Relational Schema - Transforms selected Oracle Enterprise Performance Foundation data and makes the data available to an Oracle Enterprise Planning and Budgeting business process within an Oracle OLAP Analytic Workspace. The workflow notifies the owner when the task is completed.
Wait Task - You can place this workflow between tasks to send a response notification to the owner to pause processing at a desired processing point. The workflow pauses for a set period of time but allows the user to respond to continue processing as an override.
Solve Task - Aggregates and solves a select set of data based upon defined criteria at the desired point within the business process run.
Notify - Sends an FYI broadcast defined by the owner to selected users at the desired point during the run of a business process.
Create Event - Signals that a specific position has been reached in the task sequence for a business process, causing this point to be the starting point to run another business process. The Start Event Cycle Workflow process from the EPB Business Process Scheduler item type starts that additional business process. The supplementary business process will have its own list of workflow tasks defined to run as specified by its definer.
Set Current Process Run - Business processes can spawn overlapping processing runs, which are are separate instances of data generated by each run of a business process. This task marks the process run order and maintains the current process for versioned views. For example, documents created with the current view will always point to the most recent data.
Exception Alert - Sends a notification when a specified condition has been met. You can use this task to alert yourself or others about favorable or adverse conditions within your business environment. For example, you might define an exception that generates an alert when the value for a line exceeds a specified threshold. Either response-rqeuired notifications or FYI notifications can be sent.
Explanation Required Parent - Supports response notifications. When exception criteria have been met, this workflow starts and manages child workflows designated for target users based upon the primary Exception Alert definition. For the Exception Alert task to complete, these child workflows must end with a user response or a timeout, allowing the business process to continue.
Explanation Required Child - This process is launched by the Explanation Required Parent when the exception criteria have been met. The process sends and manages response notifications for target users based upon the primary Exception Alert definition. The user must respond, or else the process ends with a timeout.
Further Explanation Requested - This process provides an additional level of nested interaction, allowing lower-level users to participate in the analysis and dialogue for the Exception Alert.
FYI Exception Alerts - This process can alternatively be run if the Exception Alert is defined simply to broadcast the list of items that have met the criteria for the Exception Alert. No response is required.
Set View Restriction - By default, when a view is generated or appended as the result of a business process run, it becomes available to all users of the business area. The Set View Restriction task enables you to set and remove restrictions on the access that analysts and other business process administrators have to the view that is generated by a business process run.
Publish Task - Integrates Oracle Enterprise Planning and Budgeting with Oracle XML Publisher to generate a custom document and distribute it to specified users. You can use this task to create and distribute high-level documents for annual reports, directors' meetings, or quarterly business reviews.
Publish Workflow - Assists in the generation and distribution of the documents to users.
Generate Template - This task creates a data collection template and specifies the distribution method for worksheets generated by the template.
Distribute Template - This task automatically distributes a worksheet that has been created by a Generate Template task.
Manage Submission - This task moves data for one or more data collection worksheet templates to the shared Analytic Workspace corresponding to an Oracle Enterprise Planning and Budgeting business process. The task completes the data collection process for these templates.
Event Process Will Not Be Initiated - When an event task is deleted, this process finds all owners of Event business processes that reference the Event task being deleted and sends them notifications indicating the deletion. An Event task can be directly deleted or it can be deleted as part of the deletion of an entire business process.
Calculation Synchronization Notification Process - When a user logs on and starts Oracle Enterprise Planning and Budgeting, this workflow notifies the user if any shared calculations have been added or removed.
Next Task Process - Manages the transition from one Oracle Enterprise Planning and Budgeting task, implemented as a workflow, to the next. This process starts the next task if any tasks are pending, or ends the business process run if all tasks for the business process are completed.
Start Business Process By Workflow Event (EPB Business Process Scheduler item type) - This workflow is called by the external scheduling of business process API, which allows any valid Oracle E-Business Suite user to start a business process run using a business process draft that has been defined and made effective in Oracle Enterprise Planning and Budgeting. This feature allows any application to start a business process run through its own user interface in order to process its data without requiring users to log into Oracle Enterprise Planning and Budgeting. It also allows any application to start a business process run on its own schedule, rather than using one of the schedule frequencies provided by Oracle Enterprise Planning and Budgeting.
Manual Distribute Template - Distributes an Oracle Enterprise Planning and Budgeting worksheet to target users when the manual distribution button is selected. Based upon the data collection definition at some higher levels, worksheets can be distributed automatically to target users; however, at lower levels manual distribution is the available option.
Submission Process - Submits a worksheet for collection and processing after a user finishes entering data into the worksheet. Based on the definition, the Submission process can recalculate data, validate against targets, and send notifications for approval. The process also manages the review of the submitted worksheet based on the data collection definition. The process sends notifications requiring the target recipient to approve or reject the worksheet.
Worksheet Approval Process - Sends a notification indicating that the worksheet and data are approved.
Worksheet Rejection Process - Sends a notification indicating that the worksheet and data are rejected.
Enterprise Planning and Budgeting Error - This process is used to manage workflow exceptions raised in any of the Oracle Enterprise Planning and Budgeting scheduling or task workflows. This process aborts the current errored workflow, sets a status in Oracle Enterprise Planning and Budgeting indicating an error condition, and sends a notification to the user set as the workflow administrator in the WF_ADMINISTRATOR attribute.
Business Rule Approval - Controls access to production data within the Oracle Enterprise Performance Foundation. Business rules defined in Oracle Profitability Manager and Oracle Transfer Pricing can make changes to the production data based on their approval status. While rules with the status approved can write results to production data, rules that have not been approved can write results only to non-production data.
Advanced Global Intercompany System (AGIS) is a new product in Release 12 and replaces the Global Intercompany System feature provided by Oracle General Ledger in Release 11i. AGIS provides an environment for companies to exchange intercompany transactions.
Intercompany Workflow - The Intercompany workflow process is triggered when the initiating company submits a transaction to the recipient company. This process handles the following actions:
Notifies the recipient company when the transaction requires approval.
Generates intercompany accounts for the initiator and recipient on transaction approval.
Transfers the transaction to Oracle General Ledger if invoices are not required and the system options indicate that transfer to Oracle General Ledger is online.
Transfers the transaction to Oracle Payables and Oracle Receivables if invoices are required and the system options indicate that transfer is online.
Notifies the initiator company when the recipient company rejects the transaction.
The Intercompany workflow uses the setup in Oracle Approvals Management to determine the list of approvers and contacts to whom notifications must be sent.
Bank Account Signing Authority Approval - Sends a notification to the list of approvers defined in Oracle Approvals Management (AME) for the approval of Signing Authority. This workflow process is started when a new signer record is created and saved and the system parameter Signing Authority Approval is set to Workflow Enabled.
CE Statement Transmission Notifications Process - This workflow sends a transmission status e-mail notification to the designated user defined in the Bank Transmission Details window. This workflow process is initiated when you submit the Retrieve Bank Statement program to transmit bank statement files from your bank to your local directory.
CE Exception Report Transmission Notification Process - This workflow sends a transmission status e-mail notification to the designated user defined in the Bank Transmission Details window. This workflow process is initiated when you submit the Retrieve Payment Exceptions program to transmit payment exceptions reports from your bank to your local directory.
Process XML Bank Statement Workflow - This workflow begins once the import process is launched. Notifications are sent to the designated Cash Manager to say whether or not the import process was launched successfully and whether or not the import process was a success.
Bankruptcy Status - When an account is flagged as bankrupt, several processes begin:
Approval is sent to the specialist or manager (HTML user interface) to work the bankruptcy, gather details, and determine if the bankruptcy will be pursued. A bankruptcy strategy is ultimately assigned.
The delinquency status is set to Bankruptcy for all delinquencies.
All other items in the case or for that customer (that is, delinquencies) are set to Bankruptcy.
A No Contact flag is set in TCA for all contacts of the organization, or, in the case of consumer collections, the No Contact flag is set for the guarantor or co-signer.
For Lease Management Collections only, a notification is sent to the appropriate party who will review and make the necessary changes to stop invoicing.
For Lease Management Collections only, a Default Bankruptcy Notice of Assignment is sent to the appropriate party.
The Bankruptcy Status workflow is initiated when a collector (Forms user interface) creates a new status of Bankrupt for a single delinquency from the Delinquency tab in Oracle Collections.
Delinquency Current Status Notice - This workflow sends notifications about the status of a delinquency to the agent and the agent's manager when the status changes. For example, when the delinquency is closed (that is, when it is considered "current") or when a new status such as Bankruptcy or Write-Off is created for a delinquency, a notification is sent to describe the change in status.
Collection Delinquent Credit Hold - A collector can request that a credit hold be placed on a customer by checking the corresponding check box on the Delinquency tab. A notification is then sent to the appropriate manager to review and approve or deny the request. Routing to the appropriate manager for approval is done through the reporting hierarchies as defined by Oracle Resource Manager. After the request is approved, the Approval check box on the Delinquency tab is checked so collectors can confirm that their requests have been approved. The actual setting of a credit hold is a manual process, however.
Collection Delinquent Service Hold - A collector can request that a service hold be placed on a customer by checking the corresponding check box on the Delinquency tab. A notification is then sent to the appropriate manager to review and approve or deny the request. Routing to the appropriate manager for approval is done through the reporting hierarchies as defined by Oracle Resource Manager. After the request is approved, the Approval check box on the Delinquency tab is checked so collectors can confirm that their requests have been approved.
Notify a Third Party for Repossession - When a specialist assigns a third party organization to repossess an asset, an e-mail notification is sent to that organization with the details about the asset or assets, repossession, and other information. The specialist assigns the third party through the HTML interface.
Delinquency Status Approval - A collector can recommend that various strategies or statuses should be initiated for a delinquency: repossession, write off or litigation. (Bankruptcy is handled separately.) However, these statuses require review and approval by a manager before the corresponding strategy is initiated. The Delinquency Status Approval workflow is initiated when a collector clicks the New button on the Delinquency tab, selects a new status, enters the details to start the process, and saves the new status. The workflow routes the request according to the resource's hierarchy as defined by the system.
Delinquency Asset Workflow - A specialist can request that an asset valuation be provided for the assets related to a delinquent case. This workflow sends a notification to the appropriate manager to review the request, obtain the information and forward it back to the specialist. The request is initiated on the asset selection window from the Delinquency tab and write off window.
Strategy Fulfillment Mailer - As part of a strategy, a request may be made to the 1-to-1 Fulfillment Server to send e-mail documentation such as a dunning notice, a dunning reminder, copies of delinquent invoices, and so on, to the delinquent party. This workflow manages this request.
Strategy Custom Workflow - If customers want to implement a custom work item as part of strategy in order to use a different implementation from the seeded workflows, they can customize the custom strategy workflow. The custom strategy work item workflow is an example of what parameters are expected to be identified in a custom workflow and what must be identified after the work item is completed.
Collection Strategy Workflow - A strategy is a series of collections work items grouped together to create a collections plan. Each work item may have a workflow as part of the completion process. The Collection Strategy workflow is the main workflow process that drives the completion of all the workflows that are tied to the collections work items for each strategy.
Journal Approval Process - You can require journal batches to be approved before posting. Create an approval hierarchy and define authorization limits for each user. The Journal Approval process is initiated when you try to post a journal batch. The process automatically routes journals to the appropriate user for approval, based on the approval hierarchy.
AutoAllocations Process - When you generate step-down AutoAllocations, the workflow process initiates the AutoAllocation process and validates and generates the Mass Allocation and Recurring Journal batches that are defined in the AutoAllocation. The workflow process also determines whether journal approval is required for each generated journal batch, submits the batches to the appropriate users for approval if required, and notifies the appropriate users of the approval results. If an error occurs during the AutoAllocation process, the designated user or users can choose to roll back the AutoAllocation process, which reverses any posted journals.
Global Consolidation System Cross Instance Data Transfer - You can automate the Global Consolidation System to consolidate data from remote subsidiary ledger database instances to a central consolidation database instance and optionally use workflow notifications to notify users of the cross instance consolidation status. Each notification provides the user with consolidation transfer details including source database name, mapping rule, set of books, group IDs, and concurrent request ID. When a user chooses to automatically run Journal Import or AutoPost on the central consolidation database, the workflow notification cites the status of success or failure of the concurrent request. If the Journal Import or AutoPost process fails, the workflow notification recommends reviewing the request log on the central consolidation database for further details.
Grants Accounting Workflow Process - The Grants Accounting Workflow process notifies key members when an installment is activated, an installment is approaching its end date, or a report is due. The Budget Subprocess notifies the budget approver or award manager that a budget is submitted for approval.
The workflow process is initiated at the following points:
installment is activated
installment is approaching its end date
report is due
budget is submitted
budget is approved or rejected
budget baseline version is created or rejected
AMW: Generic Approvals - This process is initiated when a user submits risks, controls, or audit procedures for approval.
AMW: Generic Common Utilities - This workflow sends the Information Technology Audit message, which encapsulates information about a change to a setup parameter from an Information Technology Audit.
ICM Reminder - This workflow includes the Process Certification Reminder notification and the Violation notification for Segregation of Duty.
Expenses - Oracle Internet Expenses uses the Expenses workflow process to process the manager approval and accounting review of expense reports entered in Internet Expenses. The Expenses process begins when a user submits an expense report, and finishes when an expense report is rejected, or when a manager has approved and accounting has reviewed an expense report. If approved and reviewed, the workflow process makes the expense report available for the Payables Invoice Import program. The Expenses process notifies employees at key event points during the manager approval and accounting review processes.
Credit Cards Workflow - The Credit Cards Workflow process consists of independent workflow processes and notifications that perform various activities. The Credit Cards Workflow process contains the following processes:
Aging Credit Card Transactions - This process notifies employees and managers of outstanding transactions by aging bucket. The process also escalates manager notification.
Inform Manager of Inactive Employee Transactions - This process notifies managers of unsubmitted transactions for employees that are terminated or on temporary leave. It also automatically assigns and unassigns the securing attribute to facilitate transaction submission.
Payment to Card Issuer - This process notifies employees when payments are made to the credit card issuer.
Payment to Employee - This process notifies employees when payments are made to them.
Payment to Employee by Check - This process notifies employees when payments are made to them.
Process Invalid Credit Card Transactions - This process notifies the system administrator when invalid transactions are detected during the import and validation process.
Process Unassigned Credit Cards - This process notifies the system administrator when new credit cards are created. The process also attempts to match new accounts to employees, and can be defined to automatically activate new accounts if a unique match is found.
Unapproved Expense Report - This process notifies managers of unapproved expense reports that contain credit card transactions.
Unused Credit Card Transactions - This process notifies managers and employees of unsubmitted credit card transactions.
The following procurement card workflow processes enable your self-service employees to verify and approve procurement card transactions.
AP Procurement Card Employee Verification Workflow Process - The AP Procurement Card Employee Verification Workflow process notifies and confirms procurement card transactions with card holders. This workflow process is initiated when you submit the Distribute Employee Card Transaction Verifications program from Oracle Payables. The process notifies an employee of transactions charged to the employee's procurement card, and optionally requires the employee's manual verification.
AP Procurement Card Manager Approval Transaction Process - The AP Procurement Card Manager Approval Transaction workflow process notifies and confirms verified procurement card transactions with a card holder's manager. This workflow process is initiated when you submit the Distribute Manager Card Transactions Approvals program from Oracle Payables. The AP Procurement Card Employee Verification Workflow process must first complete for transactions before the manager workflow process is used. The process notifies managers, and optionally requires their manual approval, of procurement card transactions incurred by employees.
AP Open Interface Import Process - This workflow automates verification and validation of data in the Payables Open Interface invoice tables. For example, this process can be modified to validate all accounting code combinations in the Payables Open Interface invoice tables. Notification of any invalid code combinations can be sent to a specified user for correction. Optionally the process can be set up to override any invalid code combinations with a designated default value. You can use Oracle Workflow to include additional workflow rules that meet the specific requirements of a business. Once an invoice has passed this process it is ready to be imported into the Oracle Payables application tables. To initiate the Open Interface Import process, submit Payables Open Interface Workflow from the Submit Requests window.
Invoice Approval Workflow - This workflow routes invoices to designated individuals for approval. This workflow uses the approval rules that you define in Oracle Approvals Management (OAM) to determine if an invoice requires approval. If the invoice requires approval, the workflow sequentially asks each approver on the approval list to approve the invoice online. For example, you can define a rule so invoices over $100,000 require CFO approval and then CEO approval.
For more information about related workflows in Oracle Internet Expenses, including expense reports and procurement cards, see Oracle Internet Expenses.
Distribute Worksheet Workflow Process - The Distribute Worksheet Workflow Process distributes worksheets and notifies users that a worksheet has been distributed. The process is initiated when distributing a worksheet.
Submit Worksheet Workflow Process - The Submit Worksheet Workflow Process submits worksheets. Based on user-defined parameters, the process performs constraint validations, worksheet operations, copying, and merging. The process moves worksheets from one budget stage to the next and routes the worksheets through an approval process for required approvals. The process also freezes and unfreezes worksheets. Notifications are sent to users who initiate a process and to approvers.
The process is initiated at the following points:
validating a worksheet constraint
freezing a worksheet
unfreezing a worksheet
moving a worksheet to the next stage
copying a worksheet
merging a worksheet
submitting a worksheet
Distribute Budget Revision Workflow Process - The Distribute Budget Revision Workflow Process distributes budget revisions and notifies users that budget revisions have been distributed. The process is initiated when distributing a budget revision.
Submit Budget Revisions Workflow Process - The Submit Budget Revisions Workflow Process submits budget revisions. Based on user-defined parameters, the process performs constraint validations and other budget revision operations. The Submit Budget Revisions process routes budget revisions through an approval process and updates the status and baseline values for budget revisions. The process also performs funds reservation and posts revisions to General Ledger. The process freezes and unfreezes budget revisions. Notifications are sent to users who initiate a process and to approvers.
The process is initiated at the following points:
validating a budget revision constraint
freezing a budget revision
unfreezing a budget revision
submitting a budget revision
Credit Memo Request Approval Process - This workflow routes a credit memo request for approval using an organization's internal management hierarchy or approval limits defined in Oracle Receivables. If the request is approved, a credit memo is automatically created in Oracle Receivables. Otherwise, the process notifies the requestor with an explanation of why it was not approved.
You initiate the Credit Memo Request workflow from iReceivables. iReceivables is a Web-based, self-service application that enables registered users to access their Receivables account information using a standard Web browser. When an iReceivables user chooses the Dispute a Bill function, Receivables places the specified amount in dispute and initiates the Credit Memo Request process to route the request for approval.
Document Transfer Message Workflow - This workflow creates an XML invoice document and sends it to your customer. This workflow consists of two item types.
AR Transfer Document item type - In Oracle Receivables, users run the Document Transfer Scheduling and Document Transfer concurrent programs to send XML documents. The Document Transfer Scheduling Program schedules transactions for transmission. The Document Transfer program raises a business event that is subscribed to by a workflow process, which calls Oracle XML Gateway to create and transmit the documents.
AR Notification item type - If the Document Transfer concurrent program encounters technical or transmission errors, then the transmission status changes to Failed and the program sends a workflow notification to the system administrator or Receivables user for exception handling.
In addition, Receivables users can receive via Oracle XML Gateway confirmation messages sent from their customers' payables departments. These messages confirm the document import statuses. The Receivables program receives the messages and, where necessary, automatically sends workflow notifications to Receivables users for exception handling.
AR Credit Management Application Process Workflow - This workflow manages the collection and analysis of account or prospect credit data, as well as the making and implementation of credit decisions.
The workflow is started when a credit request is generated, either by a credit event, such as an order hold, or by the submission of a credit application. The workflow first tries to automatically complete the credit review process. If, for any reason, a failure occurs in the workflow functions, then the workflow routes the credit analysis to the appropriate credit analyst for action.
If an organization requires that credit recommendations be reviewed and approved by other personnel, then the workflow routes the recommendations through an approval hierarchy.
If the recommendation is approved by the appropriate personnel, then it is automatically implemented.
If the recommendation is rejected as it is routed through the approval hierarchy, then notifications are sent to the appropriate personnel and the case folder is updated with the credit decision.
Limits Workflow - Oracle Treasury generates an event limit notification if a deal is recorded that violates one of the rules that you have defined. You can design event assignments to generate notifications for specific limits violations, such as combinations of specific deal types, companies, counterparties, and limit amounts.
Budget Execution Transaction Approval Process - Routes budget transactions through the approval process. Oracle Workflow uses the approval controls and hierarchies defined in the Define Budget Users window within Budget Execution to route documents for approval. The Budget Execution Transaction Approval process is initiated in the following windows by clicking the Approve... button:
Enter Appropriation
Enter Funds Distribution
Re-programming Transactions
Budget Transactions Summary
When a transaction is submitted for approval, the funds checking process is initiated to validate that sufficient funding is available. The transaction cannot be approved if it fails funds checking. A transaction must be approved before it can be transferred to General Ledger.
Oracle Student System includes workflows for academic records, admissions, advising, enrollment, financial aid, program structure and planning, student finance, and system wide services.
Attendance Submission Notification - Notifies the lead instructor of a unit section that attendance for the unit section is submitted. This workflow is triggered from the Review Attendance Self Service page.
Change Grade Request - Notifies the user who initiated a change of grade request and seeks resolution of the change of grade request for final and early final grading periods from the lead instructor of the unit section. This workflow is triggered from the Review Change of Grade Self Service page for final and early final periods.
Grade Submission Notification - Notifies the lead instructor of a unit section that final grades for the unit are submitted. Institutions are allowed to customize only the SELECT_APPROVER process of the Grade Submission and Change of Grade workflows to satisfy their specific needs. The remaining steps of the workflow must remain unchanged. This workflow is triggered from the Review Enter Grade Self Service page.
IGS Degree Audit - Delivers the XML document to the trading partner taking advantage of Oracle XML Gateway callback functionality. The callback feature allows the messaging system, Oracle Transport Agent, to report the message delivery status back to the workflow process that initiated the message creation. If the delivery fails, a notification is sent to the System Administrator defined in Oracle XML Gateway.
Inform Instructor about Assessment Item Grades Release to Student - This workflow is triggered by a business event.
Inform Instructor That Unit Section Grades Have Been Submitted - This workflow is triggered by a business event.
OSS: Missing Academic Record Transcript Production - Notifies the student when an administrator manually updates the details of a completion date of a missing academic records transcript. This workflow is triggered when an administrator manually updates the details of a completion date of a missing academic records transcript.
OSS: Notify About Missing Academic Record - Notifies the administrator about missing academic records when a transcript request is placed by a student or by an administrator. This workflow is triggered when a transcript request by a student or administrator indicates missing academic records.
OSS: Notify Admin About Transcript Production - Notifies the administrator about the production of the transcript.
OSS: Notify Student About Transcript Production - Notifies the individual student who placed an order about the production of the transcript. This workflow is triggered when the system prints the academic records order placed by the student.
OSS: Notify Students About Transcript Hold - Notifies the student about a transcript hold when an administrator requests a transcript and if the student has a transcript hold.
Outcome Status - Sends notifications to users alerting them of a change in the student progression outcome status. This workflow is triggered when the student progression outcome status is changed and saved.
Receive Error - This workflow is triggered if there is an error in the receipt of a reply from the Degree Audit trading partner.
Receive Reply - This workflow is triggered on receipt of a reply from the Degree Audit trading partner.
Saved Transcript - This workflow is triggered by a business event.
Submit Request - This workflow is triggered when a request is submitted on the Degree Audit Review Request Self Service page to signal Oracle XML Gateway to begin processing the outbound degree audit request.
Transcript Change Validation - When a new transcript is created in Admission, this workflow validates advanced standing records to check if the existing advanced standing still applies for the student. If not, then the advanced standing records are deleted or updated and a notification is sent to the staff member.
Admission Enforce Single Response Notification - Sends a notification when the offer response status is "Accepted" and the admission period category is set for single response. The notification is sent to all applications instances for the person that is using an admission period category that is set for single response. This workflow is triggered when the Offer Response business event is raised and you are enforcing single response.
Notify Academic Index Change - Sends a notification to the subscriber alerting them to a change in the Academic Index. Users can then use this information to make decisions about admission applications. This workflow is triggered when the Academic Index Modification business event is raised.
Notify Admission Offer Response Status Change - Sends a notification every time the offer response status changes for an application instance. This workflow is triggered when the Offer Response business event is raised.
Notify Admissions Requirements - Notifies applicants that there are additional documents or missing items that are needed to complete the application. The Admission Requirements Notifications concurrent process triggers this workflow.
Notify Evaluators About Unevaluated Applications - Allows administrative users to notify application reviewers about applications that are complete and are ready for review. This workflow is triggered when the Notify Evaluators business event is raised.
Notify Post Admission Requirements - Allows administrative users to notify applicants of the additional documents or missing items that are required by the institution even after the admission application process is complete. The Admission Requirements Notifications concurrent process triggers this workflow.
Notify Self-Service Applicants to Complete Requirements - This workflow sends both an e-mail message to the applicant and a notification accessible in the Applicant Home Self Service page. An applicant can have multiple incomplete applications. One e-mail message is sent every time the workflow is initiated by the concurrent manager request, regardless of the number of incomplete applications the applicant may have. The workflow process can be initiated multiple times within a single period. The Incomplete Applications concurrent process triggers this workflow for applicants with incomplete Self Service applications.
Pre-create Application - When the applicant or the administrator clicks the Continue button in the Create Application page, the Derivation and Pre-Create business event is raised. That event invokes this workflow, which you can customize to derive the application type and application fees from the data entered in the Create Application page components. The data entered in the Create Application page can also be used by the workflow to pass values to the Admission Application Pre-create Public API and Admission Application Instance Pre-create Public API.
Notify Advisor About Advising Group - Notifies each advisor when he or she is assigned to or removed from an advising group. This workflow is triggered when an advisor is assigned to or removed from an advising group.
Notify Student About Advising Group - Notifies each student when he or she is assigned to or removed from an advising group. This workflow is triggered when a student is assigned to or removed from an advising group.
Notify Student About Being Placed on an Advising Hold - Notifies each student when he or she has been put on an advising hold for an advising group. This workflow is triggered when a student has been put on an advising hold for a particular advising group.
Confirmation of Registration - This workflow is triggered when the Confirmation of Registration business event is raised. This workflow notifies the student, the student's supervisors, and an administrator of the registration of the student for the research candidacy.
Key Program Change - This workflow is triggered when the oracle.apps.igs.en.prog.keyprim event is raised. This workflow notifies an administrator when a student's key program changes.
Milestone - This workflow is triggered when the Milestone business event is raised. This workflow notifies the student, the active student's supervisors, and an administrator of additions and changes to milestone information for the research candidacy.
Milestone Notification - This workflow is triggered when the Milestone Notification business event is raised. This workflow notifies the student, the active student's supervisors, and an administrator of additions and changes to milestone notification information for the research candidacy.
OSS: Change in Supervisor Attribute - This workflow is triggered when a supervisor is assigned to a research candidacy or when certain attributes of the candidacy's supervision change. These attributes are the Person Number, Start Date, End Date, Supervised %, Supervisor Type, Organizational Unit, or Replaced Person Number. This workflow notifies students and administrators of supervisors.
OSS: Check Overdue Submission - This workflow is triggered when a submission is overdue, that is, when the student goes beyond the maximum submission date without submitting the work and the status of the thesis is still Pending. The workflow notifies students and administrators of an overdue submission date.
OSS: Intermission Return Condition Status Change - Sends a notification to the user alerting them to a change in a student's intermission return condition status. This workflow is triggered when the intermission return condition status is changed and saved.
OSS: Notify Program Transfer Details - This workflow is triggered when a program transfer is committed, that is, when the transfer itself is committed, whether or not the units or unit sections are transferred as part of the program transfer. The workflow notifies students and administrators of program transfer changes. This workflow is not triggered if unit attempts or unit set attempts are transferred later in a separate transaction.
OSS: Notify Student About Intermission - This workflow is triggered when an intermission is committed or when an intermission that requires approval is committed or committed and approved. The workflow notifies students and administrators of the intermission and intermission changes.
OSS: Notify Student for Program Discontinuation - This workflow is triggered when a program attempt is discontinued. The discontinuation can occur as the result of Discontinuation in Enrollment, as the result of transferring from a secondary program to a new primary program, or as the result of a progression outcome from progression. The workflow notifies students and administrators of program discontinuation.
OSS: Notify Student Program Offering - This workflow is triggered when a program offering option is changed, which occurs when an administrator commits the change for a program offering option. For example, the administrator could use the Program Change button on the Student Enrollments window to change and commit the change of a program offering option. The workflow notifies students and administrators of changes to program offering options.
OSS: Research Topic Modification - This workflow is triggered when a research topic is entered, changed, or approved. The workflow notifies students and administrators of changes to research topics.
OSS: Thesis Topic Creation - This workflow is triggered when a thesis topic or title is entered, changed, or approved, which occurs when an administrator enters or changes the information for the thesis topic or title and saves the changes. The workflow notifies students and administrators of changes to thesis topics.
Thesis Exam - This workflow is triggered when the Thesis Exam business event is raised. The workflow notifies the student, the student's supervisors, and an administrator when the thesis has been submitted or resubmitted for the research candidacy.
Thesis Result - This workflow is triggered when the Thesis Result business event is raised. The workflow notifies the student, the student's supervisors, and an administrator of a change in the thesis result for the research candidacy.
CommonLine Loan Guarantee Amount Difference - Sends a notification when the FFELP - Upload Origination Acknowledgments request set is run and the school receives a response with a guarantee amount or approved amount that is different from the loan amount (award amount accepted).
CommonLine Loan School Certification Request - Sends a notification when the school receives a response containing a school certification request while running the FFELP - Upload Origination Acknowledgments request set. School certification requests are issued to the school for certifying loan applications initiated outside of the system.
CPS Pushed ISIR Processing - Sends a notification when the Central Processing System (CPS) pushes an Institutional Student Information Record (ISIR) to the school for financial aid processing and the student's verification process is complete.
Document for a To Do Item Received - Sends a notification when a student uploads a document for a To Do Item in Student Self Service.
Financial Aid Institutional Application Submitted - Sends a notification when a student submits a Financial Aid Institutional Application in Student Self Service.
Financial Aid To Do Item Completed - Sends a notification when a student completes a To Do Item in Student Self Service.
FISAP Part II and Part VI HTML Report - Sends a notification when the FISAP (Fiscal Operations Report and Application to Participate) process is run for an award year. The workflow generates the report in HTML format and sends it to the user as a notification.
ISIR Import Person Demographic Data Change - Sends a notification when a person's demographic data is updated as a result of the importing of an Institutional Student Information Record (ISIR). The notification highlights these updated attributes: Social Security Number, First Name, Last Name, Gender, Date-of-Birth, Email Address, Address, City and Postal Code.
Student Employment Notification - Sends a notification when a student employee's remaining work-study award falls below a threshold defined for the work-study fund in the Fund Manager setup. This workflow is triggered by the Student Employment Upload Payroll Information concurrent process or when the payroll details are updated directly in the Student Work Award Progress window.
Staff Exceed Workload - Allows you to notify staff members when they exceed the expected workload. This workflow is triggered when staff members exceed the expected workload.
OSS: Notify Financial Aid about Waiver Transaction Creation - This workflow notifies a financial aid administrator if a new waiver transaction is created in the system. A waiver transaction can be created manually in the Waiver Transactions Self Service page or by using the Process Student Waivers concurrent program. Alternatively, for computation based waiver programs, waiver transactions are created automatically if the Auto Calculation of Waivers profile option is enabled. If the Generate Notification to Financial Aid system option parameter is set, then this notification is sent to the financial aid user as set up in the Waiver Notification Viewer profile option.
Academic Intent - This workflow is triggered whenever any changes are made to the Academic Intent details of a person. The workflow sends a notification to the system administrator by default.
Address Change - This workflow is triggered by an Oracle Trading Community Architecture business event. A notification provides old and new values for an updated address record. Use an Oracle Trading Community Architecture business event for creation or update of a Party Site and Location to route the Address Change workflow notification to a designated person. The workflow sends a notification to the system administrator by default.
Generate New User - This workflow is triggered through the batch user creation job. The job creates new user accounts for the assigned person. During the Self Service User Registration process, this workflow is used to send a notification when a former student or alumnus cannot be found in the Oracle Student System.
IGS SEVIS Workflow - This workflow generates the XML file for a SEVIS batch. XML can be generated for both Exchange Visitor and Non Immigrant batch types. The workflow is triggered through the IGS: SEVIS Generate Batch XML concurrent request. If the generation of the XML document fails, then the workflow sends a notification to the system administrator defined in Oracle XML Gateway.
Residency Event - This workflow is triggered when any changes are made to the residency details of a person. The workflow sends a notification to the system administrator by default.
Set or Release External Hold - Third party software or an external system can raise an Oracle Student System designated business event to insert or update a hold type into Oracle Student System. This workflow is triggered by third party software to apply or release an external hold.
Create Portfolio Account - Sends a notification to the designated approver when a Portfolio Account request for users is submitted for approval. After approval, user accounts are created or updated with the requested responsibilities and the user is notified.
Deactivate Portfolio Account - Sends a notification to the user about the changes to the Portfolio Account when one or more responsibilities associated with the user's Portfolio Account are end dated.
IGP: Portfolio Template Publication - Sends a notification to the designated approver when Portfolio Template Publications are submitted for approval. After approval, the templates are published to the Portfolio Users and the initiator is notified of the approval.
IGP: Notify Viewers for Portfolio Assignments - Sends a notification to the registered viewers when the author or career center assigns them to a Portfolio.
IGP: Add Non Registered Viewer - Sends a notification to the non-registered viewers when the author assigns them to a Portfolio. The notification details include the URL and the PIN to access the Portfolio.
IGP: Inform Author about Portfolio Assignment - Sends a notification to the Portfolio author when the career center assigns the Portfolio to the registered viewers.
IGP: Assignment Removal Notification: Career Center - Sends a notification to the career center when the Portfolio access for the registered viewers is removed or an invalid Portfolio assignment to the registered viewers is attempted by the career center.
IGP: Assignment Removal Notification: Author - Sends a notification to the author when the registered viewer or career center removes the Portfolio access for the viewer.
GHR Personnel Action Process - Enables the routing of the Request for Personnel Action (RPA) Form for data entry, signature, and review before the final approval and update to the database. Based on the agency's practices, the user can route the RPA to an individual, groupbox, or routing list within the routing group. As the RPA is routed, the system maintains a history of actions. By referring to the history, users can learn what action was taken, by whom, and on what date.
GHR Position Description Process - Enables the routing of the Position Description form for data entry, signature, review and classification. Based on the agency's practices, the user can route the Position Description form to an individual, groupbox, or routing list within the routing group. As the Position Description form is routed, the system maintains a history of actions. By referring to the history, users can learn what action was taken, by whom, and on what date.
GHR Within Grade Increase Process - Enables the automatic processing of Within Grade Increase (WGI) actions without any manual intervention. The default WGI process automatically notifies the Personnel Office of the WGI approval and requires no response. WGI process can be configured during implementation in many ways based on the agency's practices.
Task Flow Item Type - Oracle Human Resources provides a predefined workflow item type called HR Task Flow that you can use to set up your task flows. The HR Task Flow item type includes a function activity for every HR application window that is allowed to be incorporated into a task flow. You can use these predefined function activities to model a workflow process for each task flow. Moreover, each function activity includes activity attributes that you can set to create button labels and position buttons on its corresponding application window.
The HR Task Flow item type provides you with an alternative to using forms to set up and maintain your task flows. By integrating with Oracle Workflow, you can use the graphical Oracle Workflow Builder to help you design and diagram the sequence of your windows.
PA Timecard Approval Process - This process is initiated when an employee submits a timecard in Oracle Internet Time. The workflow can be configured to either automatically approve all timecards or route the timecard through a pre-determined approval process. The approval process sends notifications to managers and employees, ensures timecards adhere to company policy, and checks manager approval levels. The status of submitted timecards can be monitored throughout the approval process.
iRecruitment (IRC_WF) - Manages general notifications in Oracle iRecruitment. Notifications are sent when certain actions occur in Oracle iRecruitment, for example, when a manager refers a candidate to another manager or when a candidate registers with Oracle iRecruitment.
iRecruitment Offer Processes (IRCOFFER) - Enables managers and recruiters to use the offers functionality. Using this workflow, managers can:
Create and send offers to applicants.
Place offers on hold.
The workflow also enables applicants to respond to offers online. Applicants can either accept or decline offers.
The iRecruitment Offer Processes workflow generates notifications for the offer transactions.
iRecruitment Ex-Employee Registration (IRC_REG) - When an ex-employee provides details for registration, iRecruitment matches the information with the existing records and if it finds the appropriate record, initiates the Registration Request (REG_REQUEST) process within the IRC_REG item type. This process sends an e-mail to the ex-employee about the new user account and the password that they can use to log in to iRecruitment.
iRecruitment Notification Workflow (IRC_NTF) - This workflow sends notifications when following transactions occur:
Managers change the status of job applications.
Candidates apply for jobs or withdraw applications.
Candidates request for reverse termination of their applications.
Managers reverse the termination of applications.
Recruitment communication occurs.
Employees create candidate profiles using the Employee Referral function.
Employees apply for jobs on behalf of candidates using the Employee Referral function.
Managers plan and change the interview status. iRecruitment also sends notifications when primary interviewers update interviews with their feedback.
Candidates provide incorrect employee referral information.
External candidates register from the external recruitment site.
Managers update referral information in candidate profiles or job applications.
Effort Report Notification Process - Workflow functionality in Labor Distribution automatically routes effort reports throughout the organization and delivers electronic notifications to users regarding effort reports that require their attention or processes that are completed.
The Effort Report Notification workflow process includes the following subprocesses:
approval
notification
The Effort Report Notification workflow process is initiated in Labor Distribution when an effort report is created.
Notification is sent to approvers of the effort report. When the effort report is approved, the effort report is sent to a supervisor for certification. The creator of the effort report can monitor the status of the effort report.
Distribution Adjustment Approval Notification Process - Workflow functionality in Labor Distribution automatically routes distribution adjustments approval notifications throughout the organization and delivers electronic notifications to users regarding distribution adjustments that require their attention or processes that are completed. The process is initiated when a distribution batch is submitted.
Oracle Learning Management Workflow Process - Includes workflows for class enrollment, external learning, competency updates, Order Management, learning paths, learning certifications, instructors, tests, evaluation, mandatory enrollments, and forum postings.
Enroll in a Class
Checks to see if an existing class is full, then notifies learner of enrollment or placement on waiting list
If enrollment cancellation occurs too close to the class, cost transfer can take place, charging the customer for the enrollment
When Oracle Learning Management is set to cross charge automatically, notifies class owner when it cannot find the Transfer From or Transfer To values; warns Administrator that they must manually create finance headers and lines
Notifies enrollment request creator of changes to enrollment status
Notifies learner and supervisor of enrollment cancellation
Notifies learner of enrollment cancellation caused by approver rejection
If a class is cancelled too close to its scheduled date, reminds class owner to move enrollees to waitlist manually
Notifies Learning Administrator of database errors that prevent automatic enrollment
Notifies System Administrator of database errors following enrollment approval
External Learning
Notifies a learner that the record of their attendance in a specific event has been recorded, updated, or deleted
Competency Update
Notifies learners and managers of automatic competency updates following successful class completion
Notifies managers of the need for manual competency updates
Manages competency update approvals and rejections
Learning administration through Order Management
Enables invoicing from the order line only after the student has completed the class
Notifies student of class or enrollment cancellation
Notifies class owner of enrollment or order line cancellation, and can enroll students from the waiting list
Reminds owner of cancelled class to manually delete booked resources
Notifies class owner when the maximum number of class attendees has increased
Notifies class owner when a customer has switched enrollments from one class to another
Learning Paths and Learning Certifications
Notifies learner of learning path completion
Notifies manager and/or creator of learning path completion
Notifies learner of completion target for self-subscribed, self-created, manager-subscribed, and manager-created learning paths and components
Notifies learner of successful subscription or unsubscription to learning path
Notifies learner of upcoming certification due date
Notifies learner of certification completion, renewal, expiration, or cancellation
Notifies learner of subscription or unsubscription to a certification
Instructors
Notifies instructor of class bookings, confirmations, and cancellations
Reminds instructor of booking
Notifies instructor of change in class location
Test results
Notifies manager or learner of learner test results
Evaluation
Notifies learners of completing mandatory evaluation, if any, after they finish offline or online courses
Notifies learners of completing evaluation (voluntary), if any, after they finish offline or online courses
Mandatory enrollments
Notifies class owners of mandatory enrollments after the Process Mandatory Enrollments program completes
Forum postings
Notifies learner of new message posted to forum
Payroll Process Workflow - Enables you to complete the entire individual payroll process by submitting a single request. The Payroll Process Workflow brings together Batch Element Entry, RetroPay, the Payroll Run, Payroll Reporting, Checkwriter, NACHA, Deposit Advice, and Costing. You run the Payroll Process Workflow from the Submit Request window.
Canadian Payroll Process Workflow - Enables you to complete the entire individual Canadian payroll process by submitting a single request. This workflow brings together Batch Element Entry, RetroPay, the Payroll Run, Payroll Reporting, Checkwriter, Deposit Advice, and Costing. You run the Payroll Process Workflow from the Submit Request window.
Korean Payroll Process Workflow - Enables you to complete the entire individual Korean payroll process by submitting a single request. This workflow brings together Batch Element Entry, RetroPay By Element, the Payroll Run, Prepayments, Bank Transfer, Payslip Archive, Payslip Reporting, and Costing. You run the Payroll Process Workflow from the Submit Request window.
Assignment Costing Workflow - Enables managers to use the Assignment Costing functionality. This functionality provides a way to configure approvals to control ad-hoc employees' assignment costing updates. The workflow generates notifications when a manager changes employees' assignment costing details. Only on approval of these notifications, the application reflects the changes in employees' assignment records.
Appraisals Processes - The appraisals workflows enable both managers and non-managers to use the appraisals functionality. Managers can create appraisals for their direct reports and generate notifications of the appraisal to the appraisee and any other appraisers. When a standard or 360-Degree appraisal has completed, the workflow can automatically trigger an update to the appraisee's competency profile. The workflow also generates a Performance Review event. SSHR includes the following appraisals workflows:
Appraisal Details Process
Appraisal Approved Process
Appraisal Rejected Process
Main Appraiser/Appraisee Notification Process
Notify Participants Process
Apply for a Job Process - You use this process to enable SSHR users to submit an application for a job. If the application is successful and the recruiter accepts the application, the supervisor of the vacancy receives a notification and the workflow completes.
Approvals Process - You can configure your SSHR workflow processes so that some transactions, for example, a change to an address, require approval whereas other transactions, for example, a change to a phone number, do not require approval. Related processes include:
Approval Initialisation
Approval Notification Process
Approved Process
Commit Transaction Data Process
Dynamic Approvals Process
OnApproval Validation
Rejected Process
Approvals Process with Correction - In addition to the standard approvals functionality, this process also enables an approver to return an SSHR transaction to the initiator for correction of information or for additional information. The Approvals Process with Correction is the base process for approvals routing and notifications.
Approvers Notification Process (HR_APPROVAL_NTF_PRC) - This notification process provides all the functionality of the Approvals Process with Correction workflow, and also functionality that enables users to send notification to any workflow role supported by AME, such FND, PER, POS, RESP and so on. Additionally this new process incorporates the workflow notification timeout feature with AME callback functionality for surrogate approver.
Change Extra Information Types/Change Special Information Types - These processes provide navigation for Extra Information and Special Information pages connecting to review, confirmation and approval processes. You can include the Extra information and Special information functions in other workflows to capture additional information if required.
Check Salary Basis Change in Mid-Pay Period - This process enables a SSHR manager to change the salary basis for a direct report during a pay period. The workflow generates a notification for the Payroll Contact who can then approve or reject the change.
Compensation Distribution - This process enables an SSHR manager to assign a one-time or recurring award to an employee or worker. Non-manager users can use this workflow to set up voluntary contributions.
Employee Review Process - This process enables a user to search for an existing review or create a new review. When the review is created, the workflow initiates the approval process.
Events and Bookings Processes - These processes generate notifications for users in the following situations:
If a user has been added to an event (Event & Bookings: Added to an Event)
If a user has been designated the internal contact for an event (Event & Bookings: Notify Internal Contact)
If a user has been removed from an event (Event & Bookings: Remove from an Event)
FYI Notification Process (HR_FYI_NOTIFICATION_PRC) - This process provides the ability to send FYI notifications to approvers returned from AME of types, 'Pre Approval Notifier', 'Authority Notifier', and 'Post Approval Notifier'. This new feature is introduced in Release 12.
Hiring Processes - The hiring processes control the sequence of events that occur when a recruiting manager hires a new employee or worker. The recruiting manager enters personal and assignment information for the new hire and then defines the pay and the new manager. The workflow processes are currently:
Hire or Placement
French Hire
HR Background Cleanup Process - This process removes workflow processes that are left running if a system crashes or if a user ID is disabled or removed.
JP Commutation Information - In Japan, most companies pay employees the required expense for commuting to the office, which is commonly known as Commutation Allowance. This module supports the use of approval process, which is enabled by the common Review page function and some other common functions of the SSHR workflow definition (HRSSA.wft).
Manage Employment Events Processes - SSHR includes several workflows to enable SSHR managers to perform Manage Employment Events transactions. For example, a manager can change the location, pay, or working conditions for an employee or contingent worker. The delivered workflows enable you to change the following information for an employee or contingent worker, either individually or as a combination:
Assignment
Cost Center
Hours
Job
Location
Manager
Pay
Role
The Manage Employment Events processes are built so that you can combine particular sets of pages and build a process with or without approval and with specific sequence of functions to control the page navigation.
New Employee Registration Processes - These processes combine to enable a new employee to register and enter personal and other information using SSHR. The new user can also create a new user name and password for SSHR. The processes include:
COBRA Registration Process
Create User Name Process
New Employee Registration Address Process
New Employee Registration Assignment Process
New Employee Registration Contacts Process
New Employee Registration Process
Notification Process for Approvers and Notifiers (HR_NOTIFICATION_PRC) - This workflow is a comprehensive approval notification process that provides all the functionality listed in the Approvers Notification Process and FYI Notification Process and additionally incorporates the RFC Notification Process functionality. Also, this process provides notification callback functions to archive the notification actions and transaction data to Oracle Human Resources tables for auditing and history.
Notification Processes - These processes determine whether a user receives a notification on approval of a transaction or on submission of the transaction. The processes are:
OnApproval Notification Process
OnSubmit Notification Process
Organization Manager - The Organization Manager processes enable an SSHR manager to view or update organization managers.
Personal and Professional Information - SSHR includes workflows to enable users of SSHR (managers and non-managers) to enter, update, and delete personal and professional information. Users can currently enter, update, and delete information in the following areas:
Personal Information
Address (secondary and main)
Basic Details
Contacts
Phone Numbers
Professional Information
Academic Rank (US)
Competences
Education and Qualifications
Professional Awards
Tenure Status (US)
Process Payroll Payments Process - This process controls the Manage Payroll Payments function which an employee can use to determine how a salary is paid. If the user changes the payment method, SSHR calls the Change Payment Method Process.
Release Information for Transfer - This process enables a SSHR user to use the Release Employee Information function to share information about themselves with another user, often a manager, who would not usually have access to their records. Similarly, a manager can use this function to share information about one of their employees or workers with a second manager.
Return for Correction Process - This workflow process enables an Oracle Self-Service Human Resources user to return a transaction to the initiator for correction. This process is introduced in Oracle Self-Service Human Resources version 5 and controls notifications if they are returned for correction.
Self Service Generic Approval Process (HR_GENERIC_APPROVAL_PRC) - This approval process supplied by Oracle Self-Service Human Resources is used across HRMS products such as Oracle iRecruitment, Oracle Training Administration, Oracle Talent Management (Appraisal), and others, as well as by Oracle Self-Service Human Resource. The Self Service Generic Approval Process provides extensive capability including the features delivered through the Notification Process for Approvers and Notifiers. This generic approval process can be invoked directly from BC4J Java code by passing mandatory attributes for AME callback. Also it provides callbacks for dynamic notification message subject generation with product specific-callbacks.
Self-Service HR Standard Error Process - This workflow process is triggered if a system error occurs. The workflow generates a notification to the SSHR Administrator to inform them of the system error.
Tax Processes
Online Tax Forms Notification Process - This process sends a notification to an employee or other contact person if W4 tax records are changed.
W4 Information Processes (US) - The Federal W4 Notification and Change W4 Information processes enable a US user to view W4 information and update the information if necessary. The standard setup for these processes does not require approval.
Employee W2 Process (US) - This process enables a user to view tax information using SSHR. If the user requests a paper copy of the information, the workflow generates a notification for the HR or Payroll Representative to inform them of the request.
Training Enrollment Processes - The training enrollment processes enable users to search for training, enroll in a training offering, and cancel training. If appropriate, you can configure the processes to enable approvals by a manager or another person, for example, an HR administrator. The processes are:
Cancel Enrollment Process
Complete Enrollment Process
Enroll in Training
External Training
Training Link Access
OTL Seeded Approval Workflow - Oracle Time and Labor provides a single workflow that routes timecards to the appropriate person or people for approval. You use this workflow as a template to create as many workflows as you need for the approval styles you define.
OKL CS Equipment Exchange - The workflow is used for Equipment Exchange Requests to update equipment details after receiving necessary approvals: 1. Notify Rejection of Equipment Exchange; 2. Notify to follow up with Customer about Temporary Exchange; 3. Notify modify contract for equipment exchange request. The workflow is initiated from the Requests tab.
OKL CS Transfer Assumption Request - The workflow is used for Transfer and Assumption Requests to notify the Contract Administrator after receiving necessary approvals: 1. Received Customer Approval? 2. Received Vendor Approval? 3. Notify Credit Departments. 4. Notify Collections for Approval. 5. Notify administrator to restructure contract. The workflow is initiated from the Requests tab.
OKL CS Billing Correction Request - The workflow is used for Billing Correction Requests to notify the Contract Administrator to approve billing correction requests. The workflow is initiated from the Transactions tab.
OKL CS Billing Refund Request - The workflow is used for Billing Refund Requests to notify the Contract Administrator to approve billing refund requests. The workflow is initiated from the Account tab.
OKL CS Convert Interest Type - The workflow is used to convert Interest Requests to notify the Contract Administrator of changes in the interest type from Lease Center. The workflow is initiated from the Structure tab.
OKL CS Contract Lease Renewal - The workflow is used for Renewal Quotes to notify the Contract Administrator to approve contract lease renewals: 1. Notification for Lease Renewal; 2. Notification for Lease Renewal Rejection. The workflow is initiated from the Requests tab.
OKL Stream Generation - Outbound - The workflow is used to initiate the outbound XML Pricing Engine transaction for Stream Generation: 1. Receive raised Business Event to send the outbound XML document; 2. Call XML Gateway API to check for validity of the generated XML document; 3. Report error, if applicable; 4. Call XML Gateway API to send the document to the Pricing Engine server. The workflow is initiated from the Stream Generation Process.
OKL Stream Generation - Inbound - The workflow is used to manage the inbound XML Pricing Engine transaction for Stream Generation: 1. Capture the Business Event for inbound XML message; 2. Process the streams returned by the Pricing Engine server. The workflow is a continuation of the Stream Generation Process.
OKL - INS Gather Third Party Insurance Information - The workflow creates a task to gather third-party information when a customer fails to provide insurance proof by the due date and the lessor cannot sell insurance. The workflow is initiated from the insurance placement process.
OKL Account Generator - You can use this workflow to generate account combinations instead of the seeded sources. The workflow is initiated from the Accounting Engine.
OKL - AM: Approve Contract Portfolio - The workflow routes a contract portfolio for approval. The workflow is initiated from Contract Portfolio.
OKL - AM: Notify Contract Portfolio Execution - The workflow notifies the Remarketer (Assignment Group) contract portfolio execution. The workflow is initiated from Contract Portfolio.
OKL - AM: Approve Restructure - The workflow routes a restructure for approval. The workflow is initiated from Restructure Quote.
OKL - AM: Shipping Instructions - The workflow is used to notify the lessee of shipping instructions for an asset. The workflow is initiated from Communicate Quote.
OKL - AM: Notify Internal Transport Department - The workflow is used to notify the internal transport department of the shipping details for an asset when the lessee accepts the transport management option. The workflow is initiated from Communicate Quote.
OKL - AM: Send Quote - The workflow is used to notify the requestor of an Asset Quote. The workflow is initiated from Communicate Quote.
OKL - AM: Repurchase Acceptance - The workflow informs users of the acceptance of a Repurchase Quote. The workflow is initiated from Quote Acceptance.
OKL - AM: Termination Quote Acceptance - The workflow informs users of the acceptance of a Termination Quote (Pre-Proceeds Termination Quote, Post-Proceeds Termination Quote). The workflow is initiated from Quote Acceptance.
OKL - AM: Restructure Quote Acceptance - The workflow informs users of the acceptance of a Restructure Quote. The workflow is initiated from Quote Acceptance.
OKL - AM: Notify Remarketer - The workflow informs the remarketing team of a new asset assignment. The workflow is initiated from Asset Return.
OKL - AM: Notify Collections - The workflow informs the collections agent of updates on returns in the case of a Repossessed Asset. The workflow is initiated from Asset Return.
OKL - AM: Notify Repossession Agent - The workflow informs the external repossession agent of a new repossession request. The workflow is initiated from Asset Return.
OKL - AM: Asset Repair - The workflow routes asset repair requests for approval. The workflow is initiated from Asset Condition.
OKL - AM: Request Title Return - The workflow requests the third party titleholder to return the title on expiration of the contract. The workflow is initiated from Remarketing.
OKL - AM: Remarketing Order Cycle - The workflow defines the order cycle in Order Management for remarketed assets. The workflow is initiated from Remarketing.
Credit Application Request - The workflow notifies the Lease Credit Approver to approve the recommendation. The workflow is initiated from Credit Management's recommendation business event.
Lease Funding Approval - The workflow is used to obtain approvals required for funding request approval. The workflow is initiated from the Funding Request submit button.
Lease Contract Booking Approval - The workflow is used to obtain approvals required for contract booking and activation. The workflow is initiated from the Approval button in Authoring.
OKL - AM: Notify Internal Transport Department - The workflow notifies the Transport Department when the lessee accepts the transport management option. The workflow is initiated from the shipping instruction.
OKL - AM: Notify Manual Termination Quote Request - The workflow notifies the representative of a manual termination quoting request. The workflow is initiated from the manual termination quote.
OKL - AM: AM Service Contract Integration - The workflow initiates Service Contract Integration. The workflow is initiated from the asset return.
Notify linked lease on asset return. The workflow is initiated from the asset disposal.
Notify linked lease on asset disposal. The workflow is initiated from the termination and billing.
Notify termination and subsequent contract billing. The workflow is initiated from the delinking at termination.
Notify delink and termination. The workflow is initiated from the termination.
Notify delink error and termination. The workflow is initiated from the Transaction tab.
OKL: CS Credit Memo - The workflow is used for getting approval before processing credit memos, with a notification for approving Credit Memo Request. The workflow is initiated from the Transaction tab.
OKL: Customer Service Principal Paydown - The workflow is used to send notifications about Principal Paydown, with a notification for Contract Rebook after paydown. The workflow is initiated from the Request tab.
OKL - SS: Request Termination Quote - Sends a notification to the Lease Center Agent that a quote has been requested. The workflow is initiated in Customer Self Service when a user creates a termination quote.
OKL - SS: Make a Payment - Sends a notification to the Lease Center Agent that a payment was made. The workflow is initiated in Customer Self Service when a user makes a payment.
OKL - SS: Request Repurchase Quote - The workflow creates a repurchase quote for the contract and sends out a notification for approval. The workflow is initiated in Customer Self Service when a user creates a repurchase quote.
OKL - SS: Cancel Insurance - Sends a notification to the Lease Center Agent that a policy has been cancelled. The workflow is initiated in Customer Self Service when a user cancels an insurance policy.
OKL - SS: Update Serial Number - The workflow sends out an approval notification and updates the serial number of the asset if approved, and sends a notification to requestor, whether the workflow is approved or declined. The workflow is initiated in Customer Self Service when a user requests a serial number update.
OKL - SS: Update Asset Location - The workflow sends out an approval notification and updates the location of the asset if approved, and sends a notification to requestor, whether the workflow is approved or declined. The workflow is initiated in Customer Self Service when a user requests an asset location update.
OKL - SS: Request Billing Change - The workflow sends out an approval notification and updates billing information of the contract if approved, and sends a notification to requestor, whether the workflow is approved or declined. The workflow is initiated in Customer Self Service when a user requests a billing change.
OKL - SS: Submit Third Party Insurance - If the insurance company does not already exist, the workflow sends out a notification to create a new party. The workflow creates an insurance policy once the notified user inputs the new party ID into the notification. The workflow is initiated in Customer Self Service when a user submits information on a new provider or when a user submits insurance policy details.
OKL - SS: Request For Invoice Format Change - The workflow sends out an approval notification and updates the invoice format if approved. The workflow sends a notification back to the user with the approval decision. The workflow is initiated in Customer Self Service when a user requests an invoice format change.
OKL - SS: Claim Notification - Sends a notification to the Lease Center Agent that a claim has been created. The workflow is initiated in Customer Self Service when a user submits a new insurance policy claim.
OKL - SS: Asset Return -The workflow notifies another user (the role selected in a setup step) to create a new asset return request. The workflow is initiated in Customer Self Service when a user submits a request for asset return.
OKL - SS: Request Renewal Quote - The workflow notifies the Lease Center Agent that a new renewal quote has been created. The workflow is initiated in Customer Self Service when a user creates a renewal quote.
OKL: Collections Approve Refund - The workflow is used to approve a vendor refund. The workflow is initiated from the Request Details.
OKL: Collections Approve Cure Request - The workflow is used to approve a Cure Request. The workflow is initiated when a user accepts a lease quote payment plan.
OKL - SO: Quote Acceptance - The workflow notifies another user that the quote payment plan has been accepted.
OKL - SO: Payment Plan Approval - The workflow routes the payment plan for approval. The workflow is initiated when the user submits a payment plan for approval.
INV: Move Order Approval - Sends notifications and reminders to approvers for approval of move orders, and sends notifications of the proposed move to requesters and people on the notification list associated with the subinventories.
Material Shortage Message - Sends a notification to planners every time a receipt transaction is done for an item with material shortages. The workflow notification will be initiated from a concurrent program that checks all material transactions that have been marked by the transaction manager.
MTL Transaction Reasons Workflow - Transaction reason actions provide the user with an alternative customizable function flow when an exception happens. This workflow currently has two workflow processes seeded:
Cycle Count - Requests a cycle count on a location with a quantity discrepancy and then send out a notification.
WMS N Step Putaway - Allows the user to putaway items to an intermediate location that is different from the location suggested by the system. The system then creates another task to move the item from the intermediate location to the suggested location.
EAM Work Request Approval Process - If this process is enabled within the Enterprise Asset Management parameters (Auto Approve check box), every user with a responsibility that is assigned to the work request's asset's current owning department will receive an electronic notification to take action on the work request created. These notifications can be viewed within eAM's Maintenance User, within the responsibility used to log in. Everyone receiving the notification can access the work request to change its status or add additional information to the work request's log. Once one user approves the work request, the notification will be removed from the Worklist of other users belonging to that same approval group. You can also reassign a notification to another user for approval or additional information.
If this process is enabled, work requests are created with a status of Awaiting Work Order (approved). Otherwise, work requests are created with a status of Open.
The Discrete Manufacturing product family includes the following workflows.
Account Generation Extension - The Account Generation Extension workflow is designed to provide a graphical user interface to the Client Extension. The workflow enables you to specify the accounts for distribution based on the type of transaction or to define your own business functions to generate the desired accounts. The Account Generation Extension workflow is called from the Account Generator Client Extension.
Engineering Change Orders Process - Submits an engineering change order to the appropriate people for approval.
Change Line Workflow Routing Step - This process is made up of several specific workflow processes, each of which is activated when assignees complete a particular step in the Change Line Workflow Routing process. The specific workflow processes include:
Request Response - Sends a Change Line Level notification to the specified assignees for sharing the documents as Change Line Attachments. It also automatically provides document access to the assignees.
FYI - Sends an FYI notification to the specified assignees on the Workflow Routing page. Once the step is completed, the workflow returns control to the parent Workflow Routing Agent workflow. This workflow is started from the Workflow Routing Agent based on the definition of the workflow routing.
Request Comment - Sends a comment request notification to the assignees specified on the Change Line Workflow Routing page and controls comment requests. If the assignees do not respond by the specified period, the workflow sends a reminder notification. Once the step is completed, the workflow returns control to the parent Workflow Routing Agent workflow. This workflow is started from the Workflow Routing Agent based on the definition of the workflow routing.
Document Lifecycle Workflow Routing Step - This process is made up of several specific workflow processes, each of which is activated when assignees complete a particular step in the Document Lifecycle Workflow Routing process. The specific workflow processes include:
Request Approval - Sends an approval request notification to the assignees specified on the Document Workflow Routing page and controls approval requests. If the assignees do not respond by the specified period, the workflow sends a reminder notification. Once the step is approved, the workflow returns control to the parent Workflow Routing Agent workflow. This workflow is started from the Workflow Routing Agent based on the definition of the workflow routing.
FYI - Sends an FYI notification to the assignees specified on the Workflow Routing page. Once the step is completed, the workflow returns control to the parent Workflow Routing Agent workflow. This workflow is started from the Workflow Routing Agent based on the definition of the workflow routing.
Request Comment - Sends a comment request notification to the assignees specified on the Document Lifecycle Workflow Routing page and controls comment requests. If the assignees do not respond by the specified period, the workflow sends a reminder notification. Once the step is completed, the workflow returns control to the parent Workflow Routing Agent workflow. This workflow is started from the Workflow Routing Agent based on the definition of the workflow routing.
Planning Exception Messages - Enables you to automatically process exceptions in order to take corrective action quickly when generating materials and resource plans. Exception messages are routed to key contacts for specific responsibilities. Recipients can be supplier and customer contacts as well as internal personnel.
Indirect/Capital Project Definition Process - This process is part of the Project Manufacturing Project Definition process navigator flow. This process guides users through all the necessary sequence of steps for setting up an Indirect- or Capital-type project for use in Oracle Project Manufacturing.
Contract Project Definition Process - This process is part of the Project Manufacturing Project Definition process navigator flow. This process guides users through all the necessary sequence of steps for setting up a Contract-type project for use in Oracle Project Manufacturing.
Employee Notifications - Notifies employees that have registered interest for a particiular event on a designated Defect or Enhancement.
Critical Defect - Notifies the owner that they have recently been assigned a critical defect.
Intermediate Shipment - Enables tracking the outside processing assemblies from the shop floor to the shipping dock, and then to the supplier. The Intermediate Shipment workflow is activated when you move assemblies into the Queue intraoperation step of an Outside Processing operation with a PO Move resource charge type, or if the outside processing operation is the first operation.
WIP Exception Notification Workflow - Sends notifications of Discrete Execution Workstation exceptions.
The Process Manufacturing product family includes the following workflows.
Oracle Process Manufacturing components include the following workflows.
Sales Order Batch Reservations - The Sales Order Batch Reservations workflow sends notifications to the Customer Service Representative for changes in the production warehouse, quantity, completion date of the batch, and batch status.
Product Development Status Approval Workflow - When you activate the Product Development Status Approval Workflow, formulas, routings, recipes, validity rules, and operations require a series of approvals that result in reassigning their statuses through a predefined approval process. The workflow presents each approver with an electronic notification so action can be taken online. Laboratory Approval is optional in this workflow.
If the workflow is enabled, then formulas, routings, recipes, validity rules, and operations use the following statuses:
Approved for Laboratory Use - The status changes to Request Approval for Laboratory Use until all approvers have accepted, at which time the status changes to Approved for Laboratory Use.
Approval for General Use - The status changes to Request Approval for General Use until all approvers have accepted, at which time the status changes to Approved for General Use.
If the status is Approved for Laboratory Use, then you can only use formulas, routings, recipes, validity rules, and operations in laboratory batches and cost rollups for laboratories.
If the status is Approved for General Use, then you can use formulas, routings, recipes, validity rules, and operations in production batches and cost rollups.
Sample Creation Notification - Sends a notification to draw a physical sample as required by the associated sampling plan for the specification and specification validity rule in effect. This workflow can be triggered by an inventory quantity increase, receiving transaction, batch step release, or lot expiration or retest. The notification lists the sampling plan information and includes a link to the Samples window, where information about the sampling event is populated.
Testing Notification - Sends a notification to prompt you to perform a test and enter its result against a particular sample. This workflow is initiated by the creation of a sample that is already associated to a specification or selection of the result action for retesting a certain test. Each tester for a given sample in process receives a notification for the expected test result.
Sample Disposition Notification - Prompts for assignment of the final disposition for a sample once testing has completed. The sample disposition can be changed to accepted, accepted with variance, or rejected when all tests (if required by the associated specification) have recorded results that have been evaluated and finalized.
Composite Results Notification - Asks you whether to composite the results across a set of samples within the same sampling event. This workflow is initiated when testing of all the samples in a sampling event (based on the number of samples required by the sampling plan) is complete and each sample has a final sample disposition. The notification provides a link to the Composite Results window, where information about the sampling event is populated.
Sample Group Disposition Notification - Notifies you that the sampling event requires a final disposition, based on the number of samples required by the sampling plan. This workflow is launched when all the samples within a sampling event have a final disposition of accept, accept with variance, reject, or cancel.
Spec Status Change Approval Notification - The Spec Status Change Approval Notification workflow notifies the contact person when the specification status has changed. The workflow is activated for processing the status change. Typically, workflow approval is activated for status changes to Approved for Lab Use and Approved for General Use. The other statuses can be processed without requiring workflow approval.
Spec Customer Validity Rule Status Change Approval - The Spec Customer Validity Rule Status Change Approval Notification workflow notifies the contact person when the customer specification validity rule status has changed. The workflow is activated for processing the status change. Typically, workflow approval is activated for status changes to Approved for Lab Use and Approved for General Use. The other statuses can be processed without requiring workflow approval.
Spec Inventory Validity Rule Status Change Approval - The Spec Inventory Validity Rule Status Change Approval Notification workflow notifies the contact person when the inventory specification validity rule status has changed. The workflow is activated for processing the status change. Typically, workflow approval is activated for status changes to Approved for Lab Use and Approved for General Use. The other statuses can be processed without requiring workflow approval.
Spec Supplier Validity Rule Status Change Approval - The Spec Supplier Validity Rule Status Change Approval Notification workflow notifies the contact person when the supplier specification validity rule status has changed. The workflow is activated for processing the status change. Typically, workflow approval is activated for status changes to Approved for Lab Use and Approved for General Use. The other statuses can be processed without requiring workflow approval.
Spec WIP Validity Rule Status Change Approval - The Spec WIP Validity Rule Status Change Approval Notification workflow notifies the contact person when the WIP specification validity rule status has changed. The workflow is activated for processing the status change. Typically, workflow approval is activated for status changes to Approved for Lab Use and Approved for General Use. The other statuses can be processed without requiring workflow approval.
Spec Monitoring Validity Rule Status Change Approval - The Spec Monitoring Validity Rule Status Change Approval Notification workflow notifies the contact person when the monitoring specification validity rule status has changed. The workflow is activated for processing the status change. Typically, workflow approval is activated for status changes to Approved for Lab Use and Approved for General Use. The other statuses can be processed without requiring workflow approval.
Sample Group Rejection Notification - The Sample Group Rejection Notification workflow notifies the contact person that either a monitoring sample group or a stability study time point sample group is rejected.
Stability Study Change Status Notification - The Stability Study Change Status Notification workflow notifies the study owner of status changes in the stability study. The process of changing status from New to a status of Completed involves a series of workflow notifications. Oracle E-Records operates with this workflow to enforce the stability study status control business rules. The cancellation of a stability study is also controlled by the workflow.
Stability Study Lot/Sublot Sample Notification - When the stability study is approved, and specific lots or sublots of the item to be tested exist, then the Stability Study Lot/Sublot Sample Notification workflow notifies the stability study contact person to obtain samples for all required material sources. In the notification, the contact person is designated to draw and store the specified samples, and to update the sample records accordingly.
Stability Study Batch Creation Notification - When the stability study is approved, and specific lots or sublots of the item to be tested do not exist, then the Stability Study Batch Creation Notification workflow notifies the stability study contact person to request that a batch be created for the study.
Stability Study Testing - The Stability Study Testing workflow is a master workflow that governs the Stability Study Time Point Scheduling Notification workflow, and the Stability Study Late Time Point Scheduling Notification workflow. This workflow runs as a background process to monitor for any time point test that requires a workflow notification, or a late workflow notification. The workflow raises the appropriate event for either scheduled or late time point tests.
If the stability study is canceled or the scheduled time point testing date changes, then a workflow API manages the situation. The sample group disposition is changed from a status of Retained to a status of Pending, and the sample pull dates are updated.
Stability Study Time Point Scheduling Notification - The Stability Study Time Point Scheduling Notification workflow notifies you to pull samples for time point testing. The notification considers the required leadtime, and it requests you to change the disposition of a time point sample from Retained to Pending. When the sample disposition is changed to Pending, tests are scheduled. If the test is not performed within the grace period, then the OPM Quality Stability Study Testing master workflow raises a separate event that indicates the test is overdue.
Stability Study Late Time Point Scheduling Notification - The Stability Study Late Time Point Scheduling Notification workflow notifies you that a test is overdue. The notification considers the required grace period, and uses the OPM Quality Stability Study Testing master workflow to raise a separate event to indicate the test is late.
Quality UOM Conversion Notification - The Quality UOM Conversion Notification workflow notifies the contact person that a new or revised lot-specific UOM conversion is recommended based on quality results. A link to the Item Lot/Sublot Standard Conversion window in the OPM Inventory Control application is provided. This link does not operate unless a lot number is assigned on the quality sample.
Lot Expiry/Retest Workflow - Sends a notification to a user at a defined number of days in advance of lot expiration and retest dates. Without this workflow the expiration or retesting of a lot is not visible to the user without a query for the expiration and retest information. The Lot Expiry/Retest Workflow gives the approver this visibility by notifying the approver the defined number of days in advance of the expiration and retest date.
Item Activation E-Record - Sends notifications to approve newly created items before changing their status to an approved inventory status. The workflow is initiated from the Approve Item from the OPM Item Master window. The workflow notifies the individual who needs to approve the item's creation and calls for e-signatures using Oracle E-Records. The item becomes active if it is approved. The item remains inactive if it is not approved. Item properties cannot be modified if the workflow approval is pending for an item.
Oracle E-Records Individual Approval Notification - For all deferred e-signatures, the requestor receives a notification after each initiated e-signature of the event.
Oracle E-Records E-Signature Reminder Notification - Signers can receive reminder notifications that there are e-records awaiting their e-signatures.
Oracle E-Records Timeout Notification - An e-record requestor is notified when an e-record event times out when an e-signature is not received in the allotted period of time.
Oracle E-Records Rejection Notification - All signers and the requestor receive notifications when a rejection signature is entered for an associated e-record event.
Oracle E-Records Stylesheet Upload Notification - When all approvals have been captured for a new or updated E-Record style sheet file, the style sheet is automatically uploaded to the style sheet repository. A notification is sent to the requestor.
Oracle E-Records File Approval - Uploaded files can be routed for approval and e-signatures. This event is initiated from the Oracle E-Records File Upload window by clicking the Send for Approval button.
Oracle E-Records Transaction Configuration Variable Create/Update - The settings for Oracle E-Record transaction defaults are defined and set here. Enabling these events requires that e-Records and e-Signatures are captured before updates are saved. The new or updated data is not committed to the database unless all of the required signatures are obtained while the E-Signature window displays.
Oracle E-Records Rule Configuration Variable Create/Update - The settings for Oracle E-Record transaction rules are defined and set here. Enabling these events requires that e-records and e-signatures are captured before updates are saved. The new or updated data is not committed to the database unless all of the required signatures are obtained while the E-Signature window displays.
CTO Change Order - Sends a notification to the planner in the shipping organization detailing the changes made to an ATO order. It is started when a change to the order quantity, schedule ship date, request date, or schedule arrival date is made and a discrete job reservation or a flow schedule exists for the order. It is also started anytime a configuration change or order line cancellation is made, even if a reservation does not exist.
Order and Line Runnable Processes and Functional Subprocesses - Oracle Order Management provides seeded order and line runnable processes and functional subprocesses. Order Header workflow data is defined under the item type OM Order Header (OEOH). Seeded header runnable processes are provided to support the processing of standard Orders and Returns with approvals. Booking and Close Order functional subprocesses are also seeded. Order Line workflow data is defined under the item type OM Order Line (OEOL). Oracle Order Management comes seeded with line-level runnable processes to support the processing of standard items, configurations, service items, drop-shipments, returns for credit only, and returns for credit with receipt and approval. Functional subprocesses to schedule, ship, fulfill, invoice interface, and close order lines are also seeded. Additionally, you can configure custom processes to meet your specific business requirements using the seeded functional subprocesses and custom activities. You can use these seeded and custom runnable processes for order processing by assigning them to specific order and line transaction types. Oracle Order Management usually seeds new processes with every release. Please refer to the Order Management Workflow User Guide for the latest Oracle Order Management processes.
Change Order Notification Process - Sends a change order notification from certain application forms. The recipient and message content are set dynamically when you select a responsibility and provide content. Uses the item type OM Change Order (OECHORD).
COGS Process - Generates a cost of goods sold account using the item type Generate Cost of Goods Sold Account (OECOGS).
Negotiation Header Processes - Oracle Order Management supports the negotation phase of a sales order (that is, quotes) or blanket sales agreement. The item type for Negotiation is OM Negotiation Header (OENH). It includes steps such as submit draft, optional internal approval, customer acceptance, and complete negotation. If the transaction is a quote, at the end of the negotiation flow, the OM Order Header flow will be started; while if the transaction is a blanket sales agreement, at the end of the negotiation flow, the OM Blanket Header flow will be started.
Blanket Header Process - Oracle Order Management supports Blanket Sales Agreements through the workflow item type OM Blanket Header (OEBH). It includes steps such as submit draft (if the Blanket has no negotiation phase), expiration date handling and reminders, terminate blanket, and close blanket.
Order Import Process - Oracle Order Management supports the creation and modification of sales orders through the Order Import workflow. When an inbound XML message is received, the Order Import workflow is triggered and, depending on the setup, order import is either run synchronously or deferred for an asynchronous run. This workflow process subscribes to the event oracle.apps.ont.oi.po_inbound.create and its item type is OM Order Import (OEOI). It includes steps such as raising an event to trigger the OAG CONFIRM BOD XML message, interface table data population, raising integration events, and conditional execution of order import.
Send Acknowledgment Process - Oracle Order Management supports the generation of the ACKNOWLEDGE PO and CONFIRM BOD XML message. Both messages conform to the Open Applications Group (OAG) standard. The CONFIRM BOD notifies the buyer that an inbound document has been received and the ACKNOWLEDGE PO conveys to the buyer the results of order import. The CONFIRM BOD and ACKNOWLEDGE PO utilize different processes in the same workflow. These processes subscribe to the events oracle.apps.ont.oi.cbod_out.confirm and oracle.apps.ont.oi.po_ack.create, respectively. The item type for the workflow is OM Send Acknowledgment (OEOA). The two processes include steps such as raising integration events, generation of the deliverable data, and document transmission.
Show Sales Order Process - Oracle Order Management supports the generation of the SHOW SO and CHANGE SO XML messages. Both messages conform to the Open Applications Group (OAG) standard. SHOW SO contains status information concerning the current state of an order and CHANGE SO is used to notify the buyer of changes to his or her order. Both messages utilize the same process in the Show Sales Order workflow. The workflow process subscribes to the event oracle.apps.ont.oi.show_so.create and the item type is OM Show Sales Order (OESO). The value of a particular parameter in the consumed event determines which message will be generated. The flow includes steps such as checking trading partner setup, raising integration events, generation of the deliverable data, and document transmission.
Open Interface Tracking Process - Oracle Order Management supports the tracking of XML, EDI, and generic order import transactions through the Open Interface Tracking workflow. This workflow process subscribes to the integration event oracle.apps.ont.oi.xml_int.status and retrieves information from those events for use in the Open Interface Tracking UI. The item type for this workflow is OM Open Interface Tracking (OEEM).
EDI Workflow Process - Oracle Order Management supports the derivation and generation of EDI acknowledgment data through the OM EDI Workflow (OEXWFEDI) item type. This workflow process subscribes to the event oracle.apps.ont.oi.edi_ack_values.create and populates Oracle Order Management's acknowledgment tables with the data necessary to generate the outbound EDI messages (POAO and POCAO).
ICP Customer Feedback - This workflow process is used in the Order Information Customer Feedback form to send notifications about customer feedback regarding a sales order.
Order Management Defect - This workflow process is used in the Order Information Report Defect form to send notifications about a customer report of a defect in received goods.
Delivery Workflow (WSHDEL item type) - Supports the processing of outbound deliveries. The Delivery workflow is triggered when the first line requiring picking is assigned to a delivery. You can extend delivery workflow processes to meet your specific business requirements using seeded customizable activities and notifications; however, the Delivery workflow does not support response-required notifications or deferred activities. You can use the seeded and custom processes for deliveries by assigning them in the shipping lookup R_DEL_GEN for your organization. For more information, see: Using Oracle Workflow in Oracle Order Management.
Ship to Deliver Process (WSHDEL item type) - Models the delivery ship confirmation process to support the processing of outbound deliveries. The Ship to Deliver process is started when a delivery is ship confirmed in an organization enabled for ship to delivery flow. You can extend ship to deliver workflow processes to meet your specific business requirements using seeded customizable activities and notifications. You can use the seeded and custom processes for deliveries by assigning them in the shipping lookup R_SCPOD_C for your organization. For more information, see: Using Oracle Workflow in Oracle Order Management.
Trip Workflow (WSHTRIP item type) - The Trip workflow is triggered when a trip is created. You can extend trip workflow processes to meet your specific business requirements using seeded customizable activities and notifications; however, the Trip workflow does not support response-required notifications or deferred activities. You can use the seeded and custom processes for trips by assigning them in the shipping lookup R_TRIP_GEN for your organization. For more information, see: Using Oracle Workflow in Oracle Order Management.
For a complete list of Oracle iProcurement workflows, see the Oracle iProcurement Implementation Guide.
Receipt Confirmation Process - Sends receipt notifications to requestors, informing them that they should have received their order. This process is also known as the PO Confirm Receipt workflow.
Requisition Approval Process - Submits a requisition created from Web Requisitions to the appropriate managers for approval and updates the status of the requisition.
For a complete list of Oracle iSupplier Portal workflows, see the Oracle iSupplier Portal Implementation Guide.
Supplier Self-Service Registration Approval Process - Oracle iSupplier Portal allows a guest to log on and register as a supplier contact for a company. This process routes a notification to the appropriate account approver to verify and approve the registration. If the approver approves the registration, the Supplier Web User account is activated. If the account approver rejects the registration, the account is deactivated.
For a complete list of Oracle Purchasing workflows, see the Oracle Purchasing User's Guide.
Procurement Workflow - The Procurement Workflow is a lights-out, hands-off transaction processing system that is truly flexible and extensible to all members of your supply chain. It is one of the key enablers in the shift towards more strategic sourcing and procurement activities. It consists of the Document Approval, Automatic Document Creation, Change Orders, Account Generation, Send Notifications, Price/Sales Catalog Notification, and Receipt Confirmation (used only by Self-Service Purchasing) workflow processes.
Document Approval Process - Performs all approval related activities in Oracle Purchasing. These include, but are not limited to, document submission, approval, forwarding, approval notifications, and rejection. This includes the PO Approval workflow process for approving purchase orders and the PO Requisition Approval workflow process for approving requisitions.
Automatic Document Creation Process - Automatically creates standard purchase orders or releases against blanket agreements using approved purchase requisition lines, if the requisition lines have the required sourcing information. This process is also known as the PO Create Documents workflow.
Change Orders Process - Allows you to control which changes require a manual reapproval and which will be automatically reapproved. All reapproved documents, either manual or automatic, will result in the document revision being incremented. This process is part of the PO Approval workflow.
Send Notifications Process - Looks for documents that are incomplete, rejected, or in need of reapproval, and sends notifications regarding the document's status to the appropriate people. This is also known as the PO Send Notifications for Purchasing Documents workflow.
Price/Sales Catalog Notification Process - Sends a notification to the buyer when the price/sales catalog information sent through the Purchasing Documents Open Interface includes price increases that exceed a price tolerance that you set. This process is also known as the PO Catalog Price Tolerance Exceeded Notifications workflow.
Negotiation Approval - The negotiation approval is initiated when a buyer submits a negotiation for approval before publishing the negotiation to suppliers. This process sends approval notifications to collaboration team members designated as the document approvers.
Sourcing Negotiation - This workflow is the main process that keeps track of the negotiation status and sends notifications related to the negotiation invitations, negotiation cancellation, round modifications, and amendments.
Supplier Response Disqualification - The supplier response disqualification process is initiated when a response is disqualified by a buyer. All the participating supplier users are notified about this disqualified response.
Award Approval - The sourcing award approval workflow is initiated when a negotiation is submitted for award approval. This process tracks and routes the approvals based on the approver list generated by AME.
Sourcing Auction Awarded - The sourcing auction awarded process is initiated when a negotiation award is finalized. All the participating supplier users are notified about the award decisions.
Sourcing Complete Auction - The sourcing complete auction process is initiated when a purchasing document creation process is completed. This process notifies the buyer user about the outcome of the purchasing document creation process.
Sourcing Concurrent Program Processing - The sourcing concurrent program process is initiated when processing related to the concurrent program for a super large negotiation is completed. This process notifies the initiator about the outcome of the concurrent program.
Business Event Notification - This is a notification workflow for business events. This workflow contains the following process.
EGO Business Event Notify - This notification workflow starts when EGO business events are raised. It sends a notification to the assignee containing the business event details for the business events that are raised.
Change Action Process - This process is made up of several specific workflow processes, each of which is activated when a user performs a specific change action. These specific workflow processes include:
Initiate Change - Sends an assignment notification to the assignee and starts "Initiate Change Line" workflow if Change has a line. This workflow is started when users submit a Change Object.
Priority Change - Sends a priority change notification to the Requestor, Owner, and Assignee for changes. This workflow is started when users change the priority for a Change Object.
Reassign Change - Sends an assignment notification to the assignee. This workflow is started when users reassign a Change Object.
Request Comment - Sends a notification requesting comment to the people specified on the Request Comment Action page. When the recipient responds to the request notification, the workflow sends a response notification to the requestor. This workflow is started when users request comment for a Change Object.
Send Response FYI - This process is called when the recipient responds to the request notification in the Request Comment workflow process.
Status Change - Sends a status change notification to the Requestor, Owner, and Assignee for a change. This workflow is started when users change the status for a Change Object.
Change Line Action Process - This process is made up of several specific workflow processes, each of which is activated when a user performs a specific action on a change line. These specific workflow processes include:
Initiate Change Line - Sends an assignment notification to the assignee. This workflow is started from the Change Header's Initiate Change Workflow or when a user creates a Change Line if the Change Header is Open.
Reassign Change Line - Sends an assignment notification to the assignee. This workflow is started when a user reassigns a Change Line.
Status Change Line - Sends a status change notification to the Header Requestor, Header Owner, Header Assignee, Line Owner and Line Assignee. This workflow is started when a user changes the status for a Change Line.
Change Workflow Routing Process - This process starts the Workflow Routing Agent Process, which controls Workflow Routing and sends an Approval Status change notification to the Requestor, Owner, and Assignee for a Change. This workflow is started when a user submits a Workflow Routing for a Change Object, and it controls the progression of the routing from step to step. Also this workflow is aborted when a user aborts a Workflow Routing.
Change Workflow Routing Step Process - This process is made up of several specific workflow processes, each of which is activated when assignees complete a particular step in the Change Workflow Routing process. The specific workflow processes include:
Definition - Sends a definition request notification to the specified assignees on the Workflow Routing page and controls the definition request for a New Item Request. If the assignees do not respond by the specified period, the workflow also sends a reminder notification. Once the step is completed, the workflow returns control to the parent Workflow Routing Agent workflow. This workflow is started from Workflow Routing Agent based on the definition of Workflow Routing.
Definition and Approval - Sends a definition and approval request notification to the specified assignees on the Workflow Routing page and controls the definition and approval request for a New Item Request. If the assignees do not respond by the specified period, the workflow also sends a reminder notification. Once the step is completed, the workflow returns control to the parent Workflow Routing Agent workflow. This workflow is started from Workflow Routing Agent based on the definition of Workflow Routing.
Request Approval - Sends an approval request notification to the specified assignees on the Workflow Routing page and controls the approval request. If the assignees do not respond by the specified period, the workflow also sends a reminder notification. Once the step is approved, the workflow returns control to the parent Workflow Routing Agent workflow. This workflow is started from Workflow Routing Agent based on the definition of Workflow Routing.
Request Comment - Sends a comment request notification to the specified assignees on the Workflow Routing page and controls the comment requests. If the assignees do not respond by the specified period, the workflow also sends a reminder notification. Once the step is completed, the workflow returns control to the parent Workflow Routing Agent workflow. This workflow is started from Workflow Routing Agent based on the definition of Workflow Routing.
FYI - Sends an FYI notification to the specified assignees on the Workflow Routing page. Once the step is completed, the workflow returns control to the parent Workflow Routing Agent workflow. This workflow is started from Workflow Routing Agent based on the definition of Workflow Routing.
Group Notification Management Process - This process is made up of several specific workflow processes, each of which is activated when a user performs a specific change action. These specific workflow processes include:
Group Member Subscription - Adds a member to a group after getting approval from the group administrator. This workflow sends an approval notification to the group administrator for the subscription. Based on the administrator's approval, the member is added to the group and a confirmation notification is sent to the member.
Group Deletion - Sends a notification to all group members when a group is deleted and deletes the group from the system. The workflow is started when a member deletes the group.
Group Member Unsubscription - Unsubscribes a member from a group and notifies both the group administrator and the member. This workflow is started when the member is unsubscribed from a group.
Notify Subscription Confirmation - Sends a confirmation notification to the member regarding the subscription to the group. This workflow is started after the member is successfully subscribed to a group.
Notify Unsubscription Confirmation - Sends a confirmation notification to the member regarding the unsubscription from the group. This workflow is started after the member is successfully unsubscribed from a group.
PA: Mass Pipeline Projects Update Workflow - Integrates Oracle Projects with Oracle Sales.
PA: Oracle Projects Library Workflow - Contains common functions that can be used to enhance other workflows.
PA: Project Workflow - Routes project status changes to one or more destinations for approval.
PA Step Down Allocations Workflow - Automates the execution of step-down auto allocation sets to create allocation runs, generate the allocation transactions, release the allocation transactions (or require approval before the process proceeds), distribute costs, and update project summary amounts.
Send AR Notification Workflow - Notifies project managers when a receipt is applied to a project invoice in Oracle Receivables. If this customer invoice is linked to one or more supplier invoices that are on pay when paid payment holds, the project manager can then release holds on these supplier invoices from the Supplier Workbench in Oracle Projects, thereby clearing them for payment in Oracle Payables.
PA: Advertisements Workflow - Sends advertisement notifications and e-mails.
PA: Apply Team Template Workflow - Handles the task of applying a team template to a project.
PA: Candidate Notification Process - This notification process is launched when a candidate is nominated or withdrawn for a requirement. The process notifies the resource, the manager of the resource, and their staffing manager of the nomination.
PA: CRM Workaround Workflow - Brings future-dated employees and contingent workers into the CRM Foundation application.
PA: HR Related Updates Workflow - Synchronizes Oracle HRMS data with Oracle Project Resource Management data.
PA: Mass Assignment Approval Workflow - Handles the routing of approvals for mass assignments.
PA: Mass Assignment Transaction Workflow - Handles the creation of assignments when a mass assignment request is submitted.
PA: Overcommitment Notification Process Workflow - Notifies users when assignments cause overcommitments.
PA: Project Assignments Workflow - This process manages approvals for single resource assignments. It is launched when an assignment is created for a resource and is submitted for approval. When the assignment is approved or rejected, FYI notifications are sent to the resource, the resource manager, the staffing manager, and the project manager.
PA: Budget Workflow - Routes a project budget for approval and baseline. You select which workflow to use for the budget type, as well as determining the person(s) to route the budget to.
PA: Budget Integration Workflow - When a project is set up to use bottom-up integration, the project budget baseline process launches this deferred workflow. This workflow process performs the following tasks:
Validates the submitted budget version
Optionally, activates the Budget Status Change workflow
Interfaces the budget amounts for baseline versions to Oracle General Ledger
PA: Issue and Change Workflow - Routes control items approvals.
PA: Issue and Change Action Workflow - Sends issue and change action notifications.
PA: Project Execution Workflow - Coordinates the Task Execution Workflows that you create to perform tasks.
PA: Performance Notification Workflow - Sends performance notifications.
PA: Status Report Workflow - Routes status report approvals.
PA: Workplan Workflow - Sends workplan status notifications.
Project Budget Account Generation Workflow - When a project budget is integrated with a General Ledger budget, an account must be assigned to each project budget line. The account is used to interface the project budget amount to General Ledger. This workflow enables you to automate the account generation and assignment process.
Project Portfolio Analysis Workflow - Routes actions for a planning cycle to plan participants. Participants who receive notifications include the defined project proposers, portfolio analysts, and portfolio approvers.
Content Item Approval - Sends notifications to designated approvers when a content item is submitted for approval.
Translation Approval Workflow - Sends notifications to designated approvers when a content item is waiting for translation approval. After the content item is approved, translators are notified, so that they can translate the content item into different languages.
Contract Approval Process - Oracle Incentive Compensation uses the Contract Approval workflow in the Sales Force Planning module to process an agreement for approval by management, distribute the agreement to the sales force, and allow the salespeople to accept the agreement. The Contract Approval process begins when the user submits an agreement for approval. After all approvals are done and the salesperson accepts the agreement, it is activated as a compensation plan. The Contract Approval Process sends messages to remind the manager to distribute the agreement, remind the sales force to accept the agreement, and alert the sales manager that an agreement has not yet been accepted.
Oracle iStore provides seeded workflows in which there are predefined notifications and notification messages. The iStore Alert Workflow contains the non-report-related notifications, while the report-related notifications belong to iStore Reports Alerts. The notification e-mail messages are sent to users based on various events.
Order Confirmation Normal - Confirms a normal order. This notification is initiated when a user places an order in a Web specialty store.
Order Confirmation - Next Steps for Faxed Orders - Explains the remaining steps for order submission. This notification is initiated when a user places an order and chooses to fax a credit card or purchase order as payment.
Orders Not Booked Notification - Announces that an order has not been booked to the system administrator. This notification is initiated when a user's order is not booked.
Cancel Order - Confirms a cancelled order. This notification is initiated when a user cancels an order using the Web specialty store.
Share Cart Confirmation Notification - Confirms a shared cart event and explains how to access the shared cart to the Shared cart owner and recipients. This notification is initiated when a user shares a cart with other users.
Change Access Level - Notifies users about access level changes. This notification is initiated when a Shared cart owner changes the access level of the recipient.
Remove Cart Access for Recipient - Notifies users about the shared cart status. This notification is initiated when a Shared cart recipient ends working on a shared cart.
Stop Sharing - Notifies users that a shared cart has been un-shared by the owner. This notification is initiated when a Shared cart owner stops sharing a shared cart.
Sales Assistance Request - To Sales Representatives - Describes a request for sales assistance to a sales agent. This notification is initiated when a user requests sales assistance during the checkout flow.
Sales Assistance Request - Sends a confirmation to users who requested sales assistance. This notification is initiated when user requests sales assistance during checkout flow.
User Registration - Welcomes a newly registered user. This notification is initiated when a user registers in a specialty store, or a B2B user is registered by the B2B Primary User.
Forget Login - Sends email to a user with his or her username and password. This notification is initiated when a registered user requests login information.
Contract Negotiations Request - Disapproval - Announces rejection of a contract terms change request. This notification is initiated when the Contract administrator rejects a user's request for changes in contract terms.
Contract Negotiations Request - To Sales Representatives - Describes a request for changes to contract terms. This notification is initiated when a user requests changes in contract terms.
Contract Negotiations Request - Approval - Announces approval of a contract terms change request. This notification is initiated when the Contract administrator approves a user's request for changes in contract terms.
Contract Negotiations Request - Cancellation - Announces cancellation of contract negotiations. This notification is initiated when the Contract administrator cancels a contract that was created when a user requested changes in contract terms.
Contract Negotiations Request - To Users - Acknowledges a request for changes to contract terms. This notification is initiated when a user requests changes in contract terms.
Reports - iStore Historical Summary - Contains the information from the Store Order Summary Data Out Bin specified in the Store Administration UI. This notification is initiated when iStore Reports concurrent programs refresh the report data.
Reports - iStore Top Orders - Contains daily Top Orders from the Top Orders Bin specified in the Store Administration UI. This notification is initiated when iStore Reports concurrent programs refresh the report data.
Marketing Approval Workflow - This process gets initiated when a user submits a marketing activity like a Campaign or Event for approval to make it Active. The Marketing Approval Workflow is used for concept approval, budget approval, and approval for any funds that may be required for running various marketing activities.
Marketing Generic Approval Workflow - This process gets initiated when a user submits Root Budgets, Claims, and Price Lists for approval to make them Active or Complete.
Schedule Execution - This process gets initiated when a campaign activity is set to Available or Active, which means that it needs to be executed. This could happen as a part of schedule's manual activation by the user, or as a part of any automated schedule execution activity such as triggers or repeating schedules. This process updates the schedule's status to Active if needed, and then performs any seeded execution functionality based on the schedule's channel.
Marketing Triggers - This process gets initiated when a Marketing trigger's next run time has been reached. This could be either the original start time of the trigger, or a scheduled time for the trigger repetition, if the trigger repeats at a specific interval. This process verifies, for non date based triggers, if the condition for the trigger is satisfied. If it is, then some actions need to be performed, which is done by some of the subflows. The types of actions that can be performed are execution of associated schedules, generation and execution of associated schedules that need to repeat through this trigger, sending out notifications, and plugged-in custom logic. Also, if the trigger repeats, then the next run date/time for it is calculated and scheduled.
Alert Manager Process - This process is invoked from subscription rule functions. It gets a list of subscribers and generates content for a specific provider associated with the subscriber. It calls the Message Delivery process with the available information to deliver the message.
Message Delivery Process - Delivers sales-related notification messages.
Call Support Process - Notifies the individual service request owner each time a service request of this type is created or updated. The owner can set the status of the service request to Closed by clicking the Resolved button on the notification.
This workflow has been superseded by a more flexible notifications process which implementers can use to selectively notify both service request owners and customer contacts of service-related events. You should associate this workflow with a type only if you need to use the resolution functionality. If you associate this workflow with a service request type and also use the new notifications feature, owners may receive two notifications for the same event.
Customer Support Event Process - Notifies service request owners and contacts of different events related to service requests and manages the status propagation among related service requests. This process is used by the notifications feature of Oracle TeleService.
Duplicate Check and Autotask Create for iSupport and Email Center Created SR - Checks for potential duplicate service requests when customers create service requests using Oracle iSupport or agents create service requests from within Oracle Email Center. If the process finds a potential duplicate, it notifies the service request owner. When customers create a service request of a type set up with extended attributes, the program instead alerts the individual you specify in the Alert Recipient field of the Service Request Attributes Configuration window. You must select the autolaunch check box to enable this process.
Email Notification Generic Process - This process begins when a task of type Email Follow-up is created. The process retrieves the task attribute details, such as requester, approver, subject, and so on, from the values you enter on the Optional tab of the Task Type: Attribute Configuration window and sets a due date for the approver to acknowledge the e-mail notification. The due date is set based on the service request creation date and the number of days you enter in the Offset for Due Date attribute. An e-mail is sent to the approver with the text entered in the Subject, Message Header, Message Body, and Message Footer attributes. If the approver does not acknowledge the message by the end of the due date, the process sends a reminder notification. If the approver acknowledges any of the notifications, either the original or a reminder, then the workflow terminates. Otherwise, after sending the maximum number of reminders specified in the Email Reminder Counter attribute, the workflow fails and terminates. When the process completes successfully, the workflow updates the task status to Completed. If the processing fails, the process sets the task status to Cancelled. You can modify these statuses by setting the profile options CUG_TASK_FAILED_STATUS and CUG_TASK_SUCCESS_STATUS.
Several Oracle E-Business Suite products leverage the Oracle Workflow Business Event System for business process integration. For a complete list of business events provided by Oracle E-Business Suite, please see the Oracle E-Business Suite Electronic Technical Reference Manual (eTRM), available on My Oracle Support. A description of each feature is documented in its respective product's User's Guide or Implementation Guide, if one is available.
You can also view business event interface information in the Integration Repository. For information about using the Integration Repository, see: Oracle E-Business Suite Integrated SOA Gateway User's Guide.
Related Topics
Oracle Workflow Support Policy
Oracle Workflow is embedded in Oracle E-Business Suite and is used by its modules to automate and streamline business processes. You can use Oracle Workflow Builder to easily modify an existing business process without changing its application's code. Oracle Workflow also allows you to extend your workflow processes as your business rules change and mature. Additionally, you can use the Event Manager to modify event and subscription definitions without changing application code.
Before you use Oracle Workflow to customize any predefined workflow process, event, or subscription, you should familiarize yourself with the following customization guidelines to ensure standard and safe design and development practices. By following these guidelines, you will be able to supply important information to Oracle Support Services in helping you resolve any issues that arise from your customizations.
Verify that all setup steps have been completed as documented in the Oracle Workflow documentation, and the product-specific User's Guides.
Test the unmodified seeded workflow, event, or subscription on a test database and ensure that it runs successfully with the setup and data specific to your environment.
Refer to the product-specific User's Guide and any documentation update, available on My Oracle Support, for the specific workflow, event, or subscription of interest. These documentation sources specifically mention what should NOT be modified. Oracle Support Services will not support modifications to any object that is specifically documented as not modifiable.
Gradually build in customizations step-by-step, and test the customized workflow or subscription after each step.
When creating PL/SQL procedures, conform to the standard PL/SQL API templates documented in the Oracle Workflow Developer's Guide. Be sure to handle exceptions in the event of an error so you can track down the procedure where the error has occurred.
Do not implement the customized workflow, event, or subscription in production without fully ensuring that it works successfully on a test database, which is a replica of your production setup.
If you encounter a problem when customizing a seeded workflow, event, or subscription, you should:
Provide the Support analyst with the modified workflow definition file or event or subscription definition, and where possible, identify the exact step where the problem occurred.
Provide the Support analyst with results of running the unmodified seeded workflow or subscription.
The following types of customizations are not supported:
Modifying a workflow object that has a protection level that is less than 100.
Altering a workflow object's protection level if its original protection level is less than 100.
Modifying your access level to an unauthorized level of less than 100 for the purpose of modifying workflow objects that are protected at levels less than 100.
Customizations that are explicitly documented as being UNSUPPORTED in the seeded workflow's product-specific User's Guide or documentation update notes. This includes modifying processes, attributes, function activities, event activities, notifications, lookup types, messages, events, or subscriptions that are specifically documented as not to be modified.
Manual modification of Workflow tables with a prefix of WF_ or FND_ unless it is documented in the Oracle Workflow documentation or is required by Oracle Support Services.
Customizations to any predefined Oracle Workflow directory service view definitions, including any of the predefined implementations of the WF_USERS, WF_ROLES, and WF_USER_ROLES views, as well as the bulk synchronization views provided by originating systems within Oracle E-Business Suite.
Customizations to any predefined versions of the Oracle Workflow PL/SQL security package, WFA_SEC.
The following types of customizations are supported:
Any customization that is stated as Required in the seeded workflow's, event's, or subscription's product-specific User's Guide or documentation update notes.
Customization examples documented in the product-specific User's Guide or documentation update notes. Any issues that arise are fully supported to resolution, to the extent that the customization example was followed as documented. Any deviation from what is documented amounts to a custom development issue that needs further evaluation. See number 3 below.
Customizations that are not explicitly stated as unsupported customizations, as required customizations, or as supported customization examples are supported to the extent that the customer must first isolate the problem following the customization guidelines discussed earlier. If upon evaluation, Oracle Support Services deems that the isolated problem stems from an Oracle product, Oracle will supply a solution. Otherwise, it is the responsibility of the customer to correct the custom development issue.