7Approval Management

This chapter contains the following:

Use approval management to define policies that apply to approval workflows. For example, to reflect your own corporate policies, you can specify levels of approval for transactions over a particular amount and determine how the approvals are routed.

Approval management:

  • Controls workflows for business objects such as expense reports.

  • Enables you to define complex, multistage task routing rules.

  • Integrates with the setup in Human Capital Management (HCM) to derive approvers based on the supervisory hierarchy.

To define approval management:

  • In the Offerings work area, enable the Approval Routing Administration feature at the offering level so that relevant setup tasks are available.

  • In the Setup and Maintenance work area, use the following setup tasks in the Application Extensions or another functional area.

    • Manage Task Configurations

    • Manage Approval Groups

Task Configuration

Manage rule sets and rules that control approval flows.

Approval Groups

Each approval group includes a set of users that you configure to act on tasks in a certain pattern. Tasks can be defined to get routed to an approval group instead of an individual user.

Access for Workflow Administrators

If you're a workflow administrator for a specific product family, you need the predefined role that gives access for that family. With that role, you can do things like set up approval rules and manage submitted approval tasks for that family. By default, these roles are assigned to predefined job roles, so if you have one of those job roles, you're usually good to go.

There are a couple of predefined roles for workflow administration that aren't specific to a product family:

  • BPM Workflow All Domains Administrator Role

    • Gives you access to workflow tasks from all product families

    • Isn't assigned to any predefined job roles by default

  • BPM Workflow System Admin Role

    • Provides a bit more administration access than the product family roles

    • Is assigned by default to at least one predefined job role for most product families

Predefined Roles

Here are the predefined roles that give access to workflow administration, and the predefined job roles that they're assigned to.

Product Family Role Name Role Code Predefined Job Roles Assigned To

All

BPM Workflow All Domains Administrator Role

BPMWorkflowAllDomainsAdmin

None

All

BPM Workflow System Admin Role

BPMWorkflowAdmin

Application Implementation Consultant (ORA_ASM_APPLICATION_IMPLEMENTATION_CONSULTANT_JOB)

Corporate Marketing Manager (ORA_MKT_CORPORATE_MARKETING_MANAGER_JOB)

Customer Relationship Management Application Administrator (ORA_ZCA_CUSTOMER_RELATIONSHIP_MANAGEMENT_APPLICATION_ADMINISTRATOR_JOB)

Financial Application Administrator (ORA_FUN_FINANCIAL_APPLICATION_ADMINISTRATOR_JOB)

Human Capital Management Application Administrator (ORA_HRC_HUMAN_CAPITAL_MANAGEMENT_APPLICATION_ADMINISTRATOR_JOB)

Incentive Compensation Application Administrator (ORA_CN_INCENTIVE_COMPENSATION_ADMINISTRATOR_JOB)

Marketing Analyst (ORA_MKT_MARKETING_ANALYST_JOB)

Marketing Manager (ORA_MKT_MARKETING_MANAGER_JOB)

Marketing Operations Manager (ORA_MKT_MARKETING_OPERATIONS_MANAGER_JOB)

Marketing VP (ORA_MKT_MARKETING_VP_JOB)

Procurement Application Administrator (ORA_PO_PROCUREMENT_APPLICATION_ADMIN_JOB)

Project Application Administrator (ORA_PJF_PROJECTS_APPLICATION_ADMINISTRATOR_JOB)

Sales Lead Qualifier (ORA_MKL_SALES_LEAD_QUALIFIER_JOB)

Supply Chain Application Administrator (ORA_RCS_SUPPLY_CHAIN_APPLICATION_ADMINISTRATOR_JOB)

Financials

BPM Workflow Financials Administrator

BPMWorkflowFINAdmin

Financial Application Administrator (ORA_FUN_FINANCIAL_APPLICATION_ADMINISTRATOR_JOB)

Higher Education

BPM Workflow Higher Education Administrator

BPMWorkflowHEDAdmin

Higher Education Application Administrator (ORA_HEY_HIGHER_EDUCATION_APPLICATION_ADMINISTRATOR_JOB)

Human Capital Management

BPM Workflow Human Capital Management

BPMWorkflowHCMAdmin

Human Capital Management Application Administrator (ORA_HRC_HUMAN_CAPITAL_MANAGEMENT_APPLICATION_ADMINISTRATOR_JOB)

Incentive Compensation

BPM Workflow Incentive Compensation Administrator

BPMWorkflowOICAdmin

Customer Relationship Management Application Administrator (ORA_ZCA_CUSTOMER_RELATIONSHIP_MANAGEMENT_APPLICATION_ADMINISTRATOR_JOB)

Incentive Compensation Application Administrator (ORA_CN_INCENTIVE_COMPENSATION_ADMINISTRATOR_JOB)

Procurement

BPM Workflow Procurement Administrator

BPMWorkflowPRCAdmin

Procurement Application Administrator (ORA_PO_PROCUREMENT_APPLICATION_ADMIN_JOB)

Project Portfolio Management

BPM Workflow Project Administrator

BPMWorkflowPRJAdmin

Project Application Administrator (ORA_PJF_PROJECTS_APPLICATION_ADMINISTRATOR_JOB)

Sales

BPM Workflow Customer Relationship Management Administrator

BPMWorkflowCRMAdmin

Corporate Marketing Manager (ORA_MKT_CORPORATE_MARKETING_MANAGER_JOB)

Customer Relationship Management Application Administrator (ORA_ZCA_CUSTOMER_RELATIONSHIP_MANAGEMENT_APPLICATION_ADMINISTRATOR_JOB)

Marketing Analyst (ORA_MKT_MARKETING_ANALYST_JOB)

Marketing Manager (ORA_MKT_MARKETING_MANAGER_JOB)

Marketing Operations Manager (ORA_MKT_MARKETING_OPERATIONS_MANAGER_JOB)

Marketing VP (ORA_MKT_MARKETING_VP_JOB)

Sales Lead Qualifier (ORA_MKL_SALES_LEAD_QUALIFIER_JOB)

Supply Chain Management

BPM Workflow Supply Chain Administrator

BPMWorkflowSCMAdmin

Supply Chain Application Administrator (ORA_RCS_SUPPLY_CHAIN_APPLICATION_ADMINISTRATOR_JOB)

Things to Know About the Roles

Here are some things to know about how these roles should be used and what the roles let administrators do.

  • If your administrators manage workflow for multiple product families, you or your security administrator should give those users a custom role with the appropriate family-specific roles added.

  • If your administrators manage workflow for all product families, give them a custom role with BPM Workflow All Domains Administrator Role.

    Caution: Assign BPM Workflow All Domains Administrator Role only if your administrators really do need access to workflow tasks from all product families. For access in multiple product families, but not all, use the roles for the corresponding families instead.
  • All administrators can see to-do tasks, no matter which role they have for workflow administration.

  • Only administrators with either BPM Workflow All Domains Administrator Role or BPM Workflow System Admin Role would have Skip Current Assignment as an action to take on workflow tasks.

Define the Due Date and Expiration Policies for Workflow Tasks

For workflow tasks that should be completed within a general time frame, you can set a due date, expiration policies, or both. The current assignee will get notified before the due date to take action. Even after the due date passes, the task doesn't expire and the assignee, as well as any subsequent approvers, can still act on it. But if you set expiration policies, the task can expire based on your settings. Expired tasks are in a final state and no one can make any more updates to them. To set due dates and expiration policies, use the Manage Task Configurations or other approval setup task in the Setup and Maintenance work area.

Overall Process

To set the due date, expiration policies, or both:

  1. In the Setup and Maintenance work area, go to the following:

    • Functional Area: Application Extensions or another functional area

    • Task: Manage Task Configurations or another approval setup task

  2. In BPM Worklist, on the Task Configuration tab, select the workflow task to configure and click the Edit task icon in the Tasks to be configured toolbar.

  3. Open the Deadlines subtab and make your changes.

  4. Click the Commit task icon in the Tasks to be configured toolbar when you're ready to deploy your changes.

This figure shows the Deadlines subtab.

Deadlines subtab where you set due date and expiration
policies

Specify a Due Date

On the Deadlines subtab, specify the time frame that all approvers should complete the task in. For example, if you enter 14 days for the Due Date fields, that means the task is due 14 days after it's created.

Indicate How Tasks Expire

Follow these steps:

  1. On the Deadlines subtab, expand the Expiration Settings section.

  2. Indicate how the task would expire, based on what's not done during a specified time frame.

    • Task Level: If all approvals aren't done.

    • Assignee Level: If the assignee doesn't act on the task.

Define Policies with Assignee Level Expiration

To set expiration policies, including any escalations or renewals, with Assignee Level selected:

  1. In the Expiration Settings section of the Deadlines subtab, specify a duration and optionally select the Exclude Saturday and Sunday check box. For example, if you enter 30 days and select the check box, then:

    • For sequential routing, the task expires if the last assignee doesn't act on the task within 30 weekdays after the task is routed to that assignee. If the first assignee doesn't act in 30 weekdays, the task is passed to the next assignee, who gets another 30 weekdays. And so on, until the last assignee.

    • For parallel routing, the task expires if the current assignees don't act on the task within 30 weekdays after the task is assigned.

  2. If you want tasks to get escalated or renewed after they expire, select the Escalate or Renew option. Otherwise, leave the Expire only option selected.

  3. To escalate, indicate how many times the approval escalates up the management chain. For example, you enter 2 in the Maximum Escalation Levels field. When the task expires:

    • For sequential routing, the task is routed to the manager (User 2) of the last assignee (User 1).

    • For parallel routing, the task is routed to the managers (User 2) of all current assignees (User 1).

    When User 2 doesn't act within 30 weekdays, then the task is escalated to the manager of User 2, who has another 30 weekdays before the task goes into a final Expired status.

  4. To renew, indicate how many times the task can get renewed. For example, you enter 2 in the Maximum Renewals field. When the task expires:

    • For sequential routing, the last assignee gets another 30 weekdays.

    • For parallel routing, the current assignees get another 30 weekdays.

Define Policies for Task Level Expiration

To set expiration policies, including any escalations or renewals, with Task Level selected:

  1. In the Expiration Settings section of the Deadlines subtab, specify a duration and optionally select the Exclude Saturday and Sunday check box. For example, if you enter 30 days and select the check box, then the task expires if not all approvals are done 30 weekdays after the task is routed to the first assignee. If there are three assignees and the first two take 25 weekdays to act, then the last assignee only gets 5 weekdays.

  2. If you want tasks to get escalated or renewed after they expire, select the Escalate or Renew option. Otherwise, leave the Expire only option selected.

  3. To escalate, indicate how many times the approval escalates up the management chain.

    For example, you enter 2 in the Maximum Escalation Levels field and select Director in the Highest Approver Title field. When the task expires, it's routed to the manager (User 2) of the current assignee (User 1). When User 2 doesn't act within 30 weekdays, then:

    • If User 2 isn't a director, the task is escalated to the manager of User 2, who has another 30 weekdays before the task goes into a final Expired status.

    • If User 2 is a director, then the task goes into a final Expired status.

  4. To renew, indicate how many times the task can get renewed. For example, you enter 2 in the Maximum Renewals field. When the task expires, all pending assignees get another collective 30 weekdays to act. If they don't all act within that period, then the task is renewed for another 30 weekdays. If the task still isn't complete in that time, then it goes into a final Expired status.

Define People to Support Workflow Tasks

Generally, workflow tasks involve the person who creates the task and the approvers who act on the task. But for any given task, you can also define others who might get involved:

  • Task Owner: The task owner is an administrator for the business process that the workflow task is related to. Task owners can see the tasks for their business processes and act on behalf of anyone assigned to the task. They can also reassign, withdraw, or escalate tasks.

  • Reviewers: Reviewers can add comments and attachments to a task without having the task directly assigned to them. They can do this only if you or someone else set them up as reviewers for the task.

  • Error Assignees: Sometimes workflow tasks run into problems when trying to figure out the next assignee, for example when trying to carry out the escalation policy. You can define whom to automatically assign the task to so that the issue gets fixed. You can have different error assignees for different tasks. Error assignees can route or reassign the task to the appropriate people, or indicate that the issue can't be fixed (in which case, the task is set to the Error status).

Set Up Task Owner, Reviewers, or Error Assignees

This screenshot shows where you define supporting people on the Task Configuration tab in BPM Worklist.

Task Owner, Reviewers, and Error assignees fields
on the Assignees subtab
  1. In the Setup and Maintenance work area, go to the Manage Task Configurations task or another approval setup task in the Application Extensions functional area or another functional area.

  2. In BPM Worklist, on the Task Configuration tab, select the workflow task.

  3. Click the Edit task icon in the Tasks to be configured toolbar.

  4. Open the Assignees subtab.

  5. Click one of the icons after the Task Owner, Reviewers, or Error assignees field.

    • First icon: Use the expression builder to define who gets assigned, and click OK.

    • Second icon: Find the person you want, and click OK.

  6. Click the Commit task icon in the Tasks to be configured toolbar when you're ready to roll out your setup.

Assignments and Routing

Prevent Assigning Approvals to Specific Users

In rare cases, just based on how approval rules are set up, workflow tasks get routed to the person who created the task. Or, to someone else who should not be approving due to a conflict of interest. To make sure that such things don't happen, you can configure tasks so that they skip certain users in the approval chain. Those users can still get FYI notifications about the tasks, but not notifications they can act on.

  1. In the Setup and Maintenance work area, go to the Manage Task Configurations task or another approval setup task in the Application Extensions functional area or another functional area.

  2. In BPM Worklist, on the Task Configuration tab, select the workflow task.

  3. Click the Edit task icon in the Tasks to be configured toolbar.

  4. Click the Configuration subtab.

  5. In the Prohibit User Self-Approval section, select the Prohibit self-approval by users named in these payload attributes check box.

  6. In the Payload Attributes subsection, add one or more attributes:

    1. Click the Add icon.

    2. Click the Expression Builder icon.

    3. In the Expression Builder, expand Variables > Task > task:task.

    4. Select an attribute that represents the users to skip, for example task:creator for the task creator. Or, open the task:payload node and select an attribute from there instead.

      Note: Make sure you select an attribute that gives you user IDs at runtime, the IDs that users enter to sign in to the application.
    5. Click Insert into Expression and then OK.

  7. Select the Reassign approvals to those users' managers check box if you want to reroute tasks to the manager of the skipped user. Otherwise, the task goes to the next assignee in the approval chain.

  8. In the Tasks to be configured toolbar, click the Commit task icon when you're ready to roll out your changes.

You can also do this setup for specific participants in the task, if it's not an FYI task. In the Assignees subtab, select the participant, click Advanced, and find the same Prohibit User Self-Approval section.

  • If you have settings at both the participant and task level, both would apply.

  • If there's any conflict, for example with the setting of the Reassign approvals to those users' managers check box, the participant level setting takes precedence.

How You Can Regularly Reassign Pending Approvals for Workers That Become Inactive

A manager assignment can become inactive due to the end of an assignment or work term, termination, or global transfer. If the manager has any pending approval notifications, you must reassign them.

Run this process: Run Reassign Pending Approvals for Terminations and Correct Invalid Supervisor Assignments Process in the Scheduled Processes work area. You can set a schedule to run it at least once a day. You can run it more frequently if you want things updated faster.

Here's what the process does:

  • It reassigns the direct reports of a terminated manager to that person's line manager and also assigns any pending notifications to the line manager. Only actionable notifications will be reassigned.

  • It reassigns pending approval notifications based on the number of days you specify using the Past Period in Days Considered for Reassigning Pending Approvals parameter.

Workflow Notifications

When workflow tasks are assigned to users, they get notifications through email and the Notifications icon in the global header. Workflow tasks are managed in the Worklist: Notifications and Approvals work area and configured in the Setup and Maintenance work area using the Manage Task Configurations or other approval setup task. If you have the BPM Workflow System Admin Role (BPMWorkflowAdmin) role, you can disable or enable these notifications for all users. For example, you can disable notifications during testing, to avoid sending test notifications to users, and then enable notifications when ready.

When you disable workflow notifications:

  • The setting applies only to email notifications that are sent as part of workflow tasks, not to all emails in general.

  • Users can still find their workflow tasks in the Worklist: Notifications and Approvals work area.

Setting Notification Mode

To disable or enable workflow notifications:

  1. Click the Notifications icon on the global header.

  2. Click More Details.

  3. In BPM Worklist, click your user name and select Administration.

  4. On the Application Preferences page that's on the Administration tab, select a value from the Notification Mode list:

    • All: Email notifications are enabled. Workflow notifications are included in the global header. This is the default value.

    • None: Email notifications and workflow notifications in the global header are disabled.

    • Email: Only email notifications are enabled. New workflow notifications won't appear in the global header.

    • In-app: Workflow notifications in the global header are enabled. Email notifications are no longer sent.

    Note: If you or another administrator has selected news feed as the default home page layout, then users also get notifications in the Things to Finish section on the home page, as well as the Notifications page. The same mode setting that applies to the notifications in the global header also applies to the Things to Finish section and the Notifications page.
  5. Click Save.

Define When to Send Workflow Notifications

When notifications are enabled, each workflow task is set up by default to send notifications as part of the approval process. For example, to notify assignees whenever they're assigned a task. For any workflow task, you can change the predefined setup to determine when notifications are sent, and to whom. This setup applies to email or in-app notifications, or both, depending on what's enabled.

Set Up Notification Scenarios

To define the scenarios for sending notifications:

  1. Navigate to the Notifications subtab in BPM Worklist for the task you want to edit.

  2. Click the Add Notification icon to enable additional notification scenarios, or edit existing rows directly.

    1. In the Task Status column, select when to send the notification, for example when the task has expired. Aside from the actions or statuses available to end users, you can also select any of the following:

      • Alerted: Usually, an error condition that can be fixed. The task is assigned to the error assignee, or someone else if the task doesn't have error assignees.

      • Update: Whenever the task is updated, for example by adding a comment or attachment, without affecting the approval status or routing.

      • Update Outcome: Whenever the outcome of the task is updated, for example approved or rejected.

      • All other actions: Any action that's not already in the list of values.

    2. In the Recipient column, select whom to notify.

      • Assignees: The users or groups whom the task is currently assigned to.

      • Initiator: The user who created the task.

      • Approvers: The users who already approved the task as part of a sequential approval chain.

      • Owner: The task owner, who's responsible for the business process that the task is related to.

      • Reviewer: The user who can only add comments and attachments to a task.

  3. To disable specific notification scenarios, select a row and click the Delete Notification icon.

  4. Click the Save icon in the Tasks to be configured toolbar.

The following figure shows the table on the Notifications subtab with predefined scenarios for a workflow task. In this example, notifications are sent to assignees whenever the task is assigned to them. The task initiator also gets a notification when the task is complete, and administrators are notified if the task results in error.

Table on Notifications subtab to define when and
to whom notifications are sent for the workflow task

Set Up Reminders

To send reminders in addition to the defined notification scenarios:

  1. Select the Enable Reminder check box.

  2. From the Repeat list, select the number of reminders to send, for example 2.

  3. From the Initiating Action list, specify if the reminder is sent based on when the task is assigned to a user or when the task expires.

  4. Define a frequency for the time between reminders, for example 3 days.

  5. Click the Save icon in the Tasks to be configured toolbar.

The following figure shows the reminder setup with the given sample settings, along with After Assignment selected as the initiating action. For this example, a reminder is sent three days after the user is assigned the task. One more reminder is sent three days after that, if the user still hasn't acted on the assigned task.

Section on Notifications subtab to set up reminders
for workflow tasks

Synchronize Notifications in the Global Header with Workflow Tasks

When workflow tasks are assigned to users, they get an email as well as a notification in the global header. They can also find all of their workflow tasks in the Worklist: Notifications and Approvals work area. The notifications in the global header don't immediately reflect changes to the task status due to actions taken through email, the Worklist: Notifications and Approvals work area, or BPM Worklist. Use the Synchronize Notifications in Global Header scheduled process to update the notifications with the latest task statuses, which are always reflected in the Worklist: Notifications and Approvals work area.

Note: If you or another administrator has selected news feed as the default home page layout, then users also get notifications in the Things to Finish section on the home page, as well as the Notifications page. The scheduled process also applies to notifications in these UIs. For example, the Things to Finish section automatically reflects changes made in the global header, but not changes made through email until the scheduled process runs.

Scheduling the Process

In the Scheduled Processes work area, submit the Synchronize Notifications in Global Header process with a defined schedule. For example, schedule the process to run every two hours.

Effects of the Synchronization

After the scheduled process runs, notifications in the global header might move from the Pending Notifications list to the All Notifications list. For example:

  1. A notification is pending a user's approval.

  2. The user approves the task using the Worklist: Notifications and Approvals work area. The task status changes, but the notification in the global header is still in the Pending Notifications list.

  3. After synchronization, the notification moves to the All Notifications list because the user has changed the task status to Approved, and the notification is no longer pending action.

    If the news feed home page layout is selected, then after synchronization, the notification:

    • Is removed from the list in the global header

    • Is no longer a card in the Things to Finish section

    • Moves from the Assigned to Me tab on the Notifications page to the All tab

The scheduled process doesn't update the title of notifications in the global header. Similar to email subjects, the notification titles are static.

Email Notifications

Add Header Content to Workflow Email Notifications

Each workflow task is configured with scenarios for sending email notifications as part of the approval process. For each notification scenario in the Notifications subtab, the Notification Header column determines what's in the email header, a region that appears before the email body.

  • By default, all predefined notification scenarios have emails with blank headers.

  • Any notification scenarios you add in the Notifications subtab would have the following header value: concat(string('Task '), /task:task/task:title, string(' requires your attention.')). It is recommended to change that value to null.

For some workflow tasks, you can enable configurable email notifications based on report layouts to be used instead of the standard email notifications. The Notification Header setting doesn't apply to those configurable email notifications.

Adding Company Name or Logo

If you do want to add, for example, your company name or logo to the email header:

  1. In the Setup and Maintenance work area, go to the Manage Task Configurations task or another approval setup task in the Application Extensions functional area or another functional area.

  2. In BPM Worklist, on the Task Configuration tab, select the workflow task.

  3. Click the Edit task icon in the Tasks to be configured toolbar.

  4. Open the Notifications subtab.

  5. For the specific notification scenario on the Notifications subtab, click the icon in the Notification Header column.

  6. In the Edit Notification Message dialog box, delete any existing content and enter the following in the Notification Message field.

    • For company name: Enter text in single quotes, for example 'Oracle'. You can also use HTML formatting, for example '<h2>Oracle</h2>'.

    • For company logo: Enter the URL to your logo, following this syntax: '<img src="https://cloud.oracle.com/res/images/header/oracle-cloud-logo.png" width="230" height="69" alt="Oracle Logo">'. Replace the URL and alternative text with your own.

  7. Click the Save icon in the Tasks to be configured toolbar.

Set Up the From Field in Workflow Email Notifications

By default, the From field in workflow email notifications shows an email address without a sender name. You can't change the email address, but you can specify the sender name. For example, if you indicate that Your Company is the text to display, then the From field shows: Your Company <<your pod>.fa.sender@workflow.mail.<your data center>.cloud.oracle.com>.

You can set up the sender name in application preferences for all workflow tasks, or have different setup for specific workflow tasks. If not specified at the task level, the sender name setting defaults from the preferences.

Setting Up for All Workflow Tasks

To define the sender name for all workflow tasks that have no other applicable setup:

Notification section on the Application Preferences
page on the Administration tab, with options to define the email sender
name for all workflow tasks
  1. Open the Administration tab. If you're not in BPM Worklist:

    1. Click the Notifications icon in the global header.

    2. Click More Details.

    3. Click your user name and select Administration.

  2. On the Application Preferences page that's on the Administration tab, select one of the Email "From:" Display Name options.

    • Select to specify the text to display. Enter your value or leave blank if you want nothing to appear in the From field.

    • Select Submitter to show the person who created the task.

    • Select Previous Approver to show the previous assignee in the approval chain. When the notification is sent to the first assignee in the approval chain, the From field shows the person who created the task.

  3. Click Save.

Setting Up for a Specific Workflow Task

To specify the sender name for a specific workflow task:

More section on the Notifications subtab on the
Task Configuration tab, with options to define the email sender name
for a workflow task
  1. In the Setup and Maintenance work area, go to the Manage Task Configurations task or another approval setup task in the Application Extensions functional area or another functional area.

  2. In BPM Worklist, on the Task Configuration tab, select the workflow task.

  3. Click the Edit task icon in the Tasks to be configured toolbar.

  4. Open the Notifications subtab.

  5. On the Notifications subtab, click the Expand More icon.

  6. Select one of the Email "From:" Display Name options.

    • Select Not Applicable so that what appears in the From field depends on the application preferences that apply to all workflow tasks.

    • Select to specify the text to display. Enter your value in quotes, for example "Oracle", or leave blank if you want nothing to appear in the From field.

    • Select Previous Approver to show the previous assignee in the approval chain. When the notification is sent to the first assignee in the approval chain, the From field shows the person who created the task.

  7. Click the Save icon in the Tasks to be configured toolbar.

Send Test Workflow Email Notifications to One Address

While you're testing workflow setup, you can send all email notifications to a single address so that your users don't receive any test emails. The test emails are still sent based on the notification scenarios defined for the particular workflow task.

Specifying the Email Address

To enter the email address to send test emails to:

  1. Click the Notifications icon in the global header.

  2. Click More Details.

  3. Click your user name and select Administration.

  4. On the Application Preferences page that's on the Administration tab, click the Test Notification Email Address icon.

  5. In the dialog box, enter an email address in the Test Notification Email Address field.

  6. Click OK and then Save.

After you're done testing, go back and delete the email address that you entered.

More Setup for Workflow Email Notifications

You can click the Expand More icon on the Notifications subtab to open the More section and see other setup options for email notifications. In general, leave the default settings in this section for every workflow task. Settings in this section include the following check boxes, which, if selected, would:

  • Make notification secure (exclude details): Exclude business transaction details in email notifications.

  • Hide End User Web URL in notifications: Remove the default first line in the email body: Access this task in the Workspace Application or take direct action using the links in this email. This line includes a link that opens BPM Worklist. It is recommended to select this check box.

  • Make notification actionable: Include links in email notifications that users can click to directly take action, for example to approve or reject.

  • Send task attachments with email notifications: Include files attached to the task as attachments in the email notifications.

Configurable Notifications

Apply Changes to Workflow Notifications Soon After Upload

Configurable workflow notifications are refreshed every 24 hours so that they perform better for your users. But when you're making changes to reports, subtemplates, or data models, you can apply your changes sooner so they're available for testing. Create profile options to control when notifications reflect your changes after you upload them to the BI catalog. When you're done configuring notifications, use the same profile options to turn the refresh back to every 24 hours, to optimize performance. But even if you don't, the refresh automatically resets to 24 hours when it's been more than eight hours since you set the profile options.

Note: The refresh applies only to changes uploaded to the BI catalog and the actual notifications that are then sent out with your changes. You can always preview changes to layout templates while you're editing in Microsoft Word or view the report in BI Publisher.
Create Profile Options to Control the Refresh

Your profile options can apply to all workflow tasks, a product family, or a product. Based on the scope you want, your profile option must have a profile option code that follows a certain format.

Scope Profile Option Code Examples

Global

BIP_CLIENT_REFRESH_TIME

BIP_CLIENT_REFRESH_TIME

Product Family

BIP_CLIENT_REFRESH_TIME_<FAMILY>

  • BIP_CLIENT_REFRESH_TIME_FIN

  • BIP_CLIENT_REFRESH_TIME_HCM

  • BIP_CLIENT_REFRESH_TIME_PRC

  • BIP_CLIENT_REFRESH_TIME_PRJ

  • BIP_CLIENT_REFRESH_TIME_SCM

Product

BIP_CLIENT_REFRESH_TIME_<FAMILY>_<PRODUCT>

  • BIP_CLIENT_REFRESH_TIME_FIN_AP

  • BIP_CLIENT_REFRESH_TIME_HCM_PER

  • BIP_CLIENT_REFRESH_TIME_PRC_PON

  • BIP_CLIENT_REFRESH_TIME_PRJ_PJE

The profile options with a smaller scope take precedence. For example, you have profile option A with a global scope and profile option B with a product scope. If you're currently configuring notifications for a particular product, use profile option B to adjust the refresh time just for that product. But based on profile option A, the refresh is still at 24 hours for all other configurable notifications in all other products. Profile option B takes precedence over profile option A only for that one product.

Tip: To find the product family or product code, go to the Setup and Maintenance work area. Use the Manage Taxonomy Hierarchy task in the Application Extensions functional area for any offering. In the hierarchy, expand the root node and then the Oracle Fusion node. Find the row for the family or product and look in the Module Key column for the code.

Now you're ready to create your profile options!

  1. In the Setup and Maintenance work area, go to the Manage Applications Core Profile Options task in the Application Extensions functional area for your offering.

  2. On the Manage Applications Core Profile Options page, click the New icon.

  3. On the Create Profile Option page, enter the profile option code in the format that corresponds to the scope you want.

  4. Enter a display name that you can easily remember to help you find the profile option later.

  5. From the Application list, select Oracle Middleware Extensions for Applications.

  6. From the Module list, select Application Core.

  7. Specify a start date.

  8. Click Save and Close.

  9. On the Manage Applications Core Profile Options page, make sure your new profile option is selected in the Search Results: Profile Options subsection.

  10. In the <Profile Option>: Profile Option Levels subsection, select the Enabled and Updatable check boxes for the Site level.

  11. Save your work.

Set the Refresh Interval

In the Setup and Maintenance work area, go to the Manage Applications Core Administrator Profile Values task in the Application Extensions functional area. Set your profile option at the Site level and enter 15 or higher for the refresh interval in minutes. For example, if you enter 15, then your changes are applied to notifications 15 minutes after you upload to the BI catalog.

Caution: Make sure to enter a whole number.

When you're done making and testing your changes, set the profile option back to 1440, which is 24 hours in minutes. If you forget and leave your profile option as is for longer than eight hours, don't worry! At that point, the profile option resets itself back to 1440 minutes.

Best Practices for Layouts in Workflow Notifications

Predefined workflow notifications based on report layout templates all follow a general format. When you edit a copy of these layout templates in Microsoft Word, follow the predefined layout as closely as possible for consistency. Also keep in mind shared components and mobile considerations.

General Structure

In general, the workflow notifications contain a set of components that are displayed in a certain order.

The callouts in this figure identify the email notification components listed in the following table.

Example of a workflow email notification with callouts
to identify the various components

The callouts in this figure identify the in-app notification components listed in the following table. In addition to describing each component, the table also indicates if the component appears in the email notification, in-app notification, or both.

Example of a workflow in-app notification with
callouts to identify the various components
Callout Component Notification Type

1

Buttons with the primary actions to take on the task, such as Approve and Reject. These buttons aren't part of the configurable, report-based notification content.

In-app

2

Notification header listing key attributes of the workflow task and the associated transaction.

Both

3

Buttons for the primary actions to take on the task, such as Approve and Reject.

Email

4

Notification body that usually includes transaction and line level details, displayed in tables or sets of attributes with corresponding values. The data model for the report restricts the total number of rows displayed in some of the tables. If the limit is exceeded, the table footer provides a link to the transaction details page, where users can view all the rows. To change this limit, you can edit a copy of the data model.

Both

5

Approval history, including any attachments that users in the history uploaded for the task. You can't edit the approval history component, which usually appears in the body of only email notifications. For in-app notifications, you can usually view the history by clicking the Actions button and selecting History.

Email (or both, in rare cases)

6

Buttons for the primary actions again.

Email

7

A link to the corresponding transaction page, and another link to the in-app notification.

Email

When you modify notifications, try to keep to this general structure and don't remove essential elements such as the action buttons. Likewise, don't change the styles in your layout template. The predefined style template should still apply to your notification; don't edit a copy of the style template and apply that to your notification.

To add components to your notification, for example another table, consider first downloading another style template from My Oracle Support. This template contains Quick Parts content that you can use in Word when you do more advanced work on layout templates. For example, from the Quick Parts gallery, you can select and add the table that's consistent in format with predefined tables already on your notification.

By default, the components that you add in the layout template appear in both email and in-app notifications, where available. You can add conditions to explicitly make a particular element, for example a field, appear only in one type of notification and not the other.

Shared Components

A predefined subtemplate in the business intelligence (BI) catalog applies to all predefined layout templates for workflow notifications. The subtemplate contains components that are shared among the notifications, for example:

  • Branding logo, if you add one to the subtemplate, which would appear as the first component in the email body. The logo appears in email notifications only.

  • Action buttons in email notifications.

  • Links at the end of the email notification, one to the corresponding transaction page, and another to the in-app notification.

When you make a copy of a predefined layout template to edit, the copy automatically inherits the same predefined subtemplate. To edit these shared components, make a copy of the predefined subtemplate, edit the copied version, and apply it to your own layout templates.

Mobile Considerations

Because users can view the workflow notifications on mobile devices, always consider mobile first and keep the notifications as simple as possible. For example:

  • Don't put too much content horizontally, such as too many columns in tables.

  • Keep all text, including attributes and column headings, as short as possible.

  • Center align lists of attributes and their values, if they appear outside tables.

Make sure to test your email notifications on mobile devices.

Add a Branding Logo and Change Other Shared Components in Workflow Notifications

A predefined subtemplate contains common components for all workflow notifications based on predefined report layouts. For example, the subtemplate has a place for you to add a branding logo, which would appear at the beginning of email notifications. You can modify other shared components so that the same changes apply to your notifications. For example, for email notifications, you can also change the text on action buttons, or the text of the links that appear at the end of emails.

Note:
  • You must edit a copy of the subtemplate in the Custom folder of the business intelligence (BI) catalog. Don't directly update the predefined subtemplate.

  • The exact steps can vary depending on your version of Microsoft Word.

Modifying Shared Components in the Subtemplate

To edit a copy of the predefined subtemplate that contains the shared components:

  1. Click Navigator > Reports and Analytics.

  2. Click the Browse Catalog icon.

  3. In the BI catalog (the Folders pane), expand Shared Folders > Common Content > Templates.

  4. For Workflow Notification Subtemplate, click More and select Customize.

    If you're not using the Customize option:

    1. Click Copy in the toolbar with Workflow Notification Subtemplate selected.

    2. In the BI catalog, expand Shared Folders > Custom > Common Content > Templates. Create a Templates folder in this location if it doesn't exist.

    3. Click Paste in the toolbar.

    4. Click the Edit link for the copied subtemplate.

    All reports using the predefined subtemplate are automatically redirected to point to your subtemplate in the Custom folder. This applies:

    • To all reports, predefined or not

    • No matter if you copy and paste the subtemplate or use the Customize option

    • Only if your subtemplate has the same name and relative file path within Custom as the predefined subtemplate

  5. In the Templates section, click the link in the Locale column.

  6. Save the subtemplate .rtf file to your computer.

  7. Open the .rtf file with Microsoft Word.

    • To add a logo, insert your own image in the subtemplate.

    • To change button or link text, edit the text accordingly. Make the same edits wherever that button or link text appears in the subtemplate.

      Caution: To ensure that your layout templates reflect these changes without additional rework, don't edit any other text in the subtemplate .rtf file.
  8. Update Word options to ensure that existing links remain intact in the subtemplate.

    1. Click File > Options > Advanced.

    2. In the Word Options dialog box, click Web Options in the General section.

    3. In the Web Options dialog box, open the Files tab.

    4. Deselect the Update links on save check box.

  9. Save your changes in Word.

Uploading the Modified Subtemplate

To upload your subtemplate to the BI catalog:

  1. In the BI catalog, expand Shared Folders > Custom > Common Content > Templates.

  2. Click Edit for Workflow Notification Subtemplate.

  3. In the Templates section, click the Upload icon.

  4. Select your modified .rtf subtemplate and a locale, and click OK to overwrite the original subtemplate.

Use Quick Parts for Workflow Notifications

Use the Quick Parts feature in Microsoft Word to easily insert reusable pieces of formatted content. When you edit copies of predefined report layout templates for workflow notifications in Word, you can add predefined Quick Parts content to your .rtf file. For example, you can insert a table in a format that's consistent with predefined notifications. The predefined Quick Parts content is available in a style template .dotx file on My Oracle Support.

Note: The exact steps can vary depending on your version of Microsoft Word.
Prerequisites

To get the predefined Quick Parts content into your Quick Parts gallery:

  1. Open Configurable Workflow Notifications: Implementation Considerations (2215570.1) on My Oracle Support at https://support.oracle.com.

  2. Download the .dotx file and save it to your Microsoft Word template folder, for example C:\Users\<user name>\AppData\Roaming\Microsoft\Templates.

Also, to preview your layout template changes before uploading the .rtf file back to the business intelligence (BI) catalog:

  • Generate sample report data from the data model for the report that you're editing.

  • Download a local copy of the subtemplate that applies to the layout template.

Adding Quick Parts Content to Workflow Notifications

To insert content from the Quick Parts gallery into a layout template:

  1. In the BI catalog, find the predefined report with the layout template that you want to modify.

  2. For the report, click More and select Customize.

    If you're not using the Customize option:

    1. Copy the predefined report and paste it in an appropriate subfolder within the Custom folder.

    2. Click the Edit link for the copied report.

  3. Click Edit for the layout template to insert Quick Parts content into, and save the .rtf file to your computer with a new file name.

  4. Open the .rtf file with Microsoft Word.

  5. Put your cursor where you want to insert new content.

  6. From the Insert tab on the ribbon, click Quick Parts within the Text group, and select the component to insert.

  7. Edit the inserted component as needed and add any other components.

  8. Save your changes in Word.

Previewing the Layout Template Changes

To preview your edits before uploading your layout template to the BI catalog:

  1. On the ribbon, open the BI Publisher tab and click Sample XML within the Load Data group to import sample data from the data model. Skip this step if you already loaded sample data.

  2. At the beginning of the document, replace the path with the location of the downloaded subtemplate file on your computer. For example, change <?import:xdoxsl:///Common Content/Templates/Workflow Notification Subtemplate.xsb?> to <?import:file:///C:/Template_Directory/FinFunWorkflowNotificationSub.rtf?>.

  3. From the BI Publisher tab on the ribbon, click HTML in the Preview group.

  4. If the preview reflects your changes as expected, then change the path back to the original location.

  5. Save your changes in Word.

Uploading the Modified Layout Template

To upload your layout template to the BI catalog after previewing the changes:

  1. Back in the BI catalog, click Edit for the report within the Custom folder, if that page isn't still open.

  2. Click the View a list link.

  3. Click the Create icon on the table toolbar.

  4. In the Upload or Generate Layout section, click Upload.

  5. Upload your edited .rtf file with a unique layout name.

  6. Back on the page for editing the report, click Delete for the layout template that you downloaded earlier.

  7. Click the Save Report icon.

Set Up Content to Appear in Only Email or In-App Workflow Notifications

For workflow tasks that have configurable email and in-app notifications, the same .rtf report layout template is used for both types of notifications. When you edit a copy of predefined templates in Microsoft Word to modify the notifications, you can make content conditional. For example, you can add an attribute from the data models used for the report, and set the attribute to appear only in in-app notifications.

The logo, action buttons, and links at the end of email notifications are predefined to appear only in emails, based on the subtemplate. The approval history is usually predefined to also appear in the body of only email notifications. Any conditional setting you apply to these components in the .rtf template won't override the predefined setup.

Prerequisites

Generate sample report data from the data model used for the report, and save the .xml file to your computer.

Defining Conditional Regions

To define a conditional region of content that appears only in email or in-app notifications:

  1. Open your .rtf report layout template in Microsoft Word.

  2. On the ribbon, open the BI Publisher tab and click Sample XML within the Load Data group.

  3. Select the .xml file you downloaded to import sample data from the data model.

  4. In your .rtf document, select the content you want to make conditional.

  5. On the ribbon, click Conditional Region within the Insert group.

  6. In the Conditional Region dialog box, on the Properties tab, select BINDISONLINENOTIF from the Data field list in the General section. The values in this list come from the sample data you imported from the data model.

  7. Select Date/Text from the next list.

  8. In the Condition 1 section, select Equal to from the Data field list.

  9. In the corresponding text field, enter true for content to appear only in in-app notifications, or false for content to appear only in emails.

  10. Make sure that form fields containing the conditional logic are inserted around your selected content. The beginning form field, C, should be immediately before the conditional content, and the closing form field, EC, should be immediately after. Move the form fields as needed.

    Tip: To make sure you're looking at the correct form fields, double-click the C form field to open the Conditional Region dialog box and see the BINDISONLINENOTIF setting.
  11. Save your changes in Word.

Entering Conditional Code

If the data model for your report doesn't have the BINDISONLINENOTIF attribute, then:

  1. In your .rtf report layout template, put your cursor immediately before the content you want to make conditional.

  2. Enter the following code, which functions the same as the C form field:

    • <?if:BINDISONLINENOTIF='true'?> for in-app only

    • <?if:BINDISONLINENOTIF='false'?> for email only

  3. Put your cursor immediately after your conditional content.

  4. Enter <?end if?>, which functions the same as the EC form field.

  5. Save your changes in Word.

Preview Changes to Layout Templates for Workflow Notifications

To modify workflow notifications, you edit a local copy of the .rtf report layout templates in Microsoft Word. Before uploading the .rtf files to the business intelligence (BI) catalog, you should preview the output with the changes you made. You can avoid uploading a broken report that displays an error in the notifications sent to users.

Note: The exact steps can vary depending on your version of Microsoft Word.
Prerequisites

  • Generate sample report data from the data model used for the report, and save the .xml file to your computer.

  • Download a local copy of the subtemplate that applies to your own report layout template:

    1. In the BI catalog, expand Shared Folders > Custom > Common Content > Templates if you're using a modified subtemplate, or Shared Folders > Common Content > Templates for the predefined subtemplate.

    2. Click Edit for Workflow Notification Subtemplate.

    3. In the Templates section, click the link in the Locale column.

    4. Save the subtemplate .rtf file to your computer.

Previewing Output

To generate sample output from a local layout template:

  1. Open your .rtf report layout template in Microsoft Word and make your edits.

  2. On the ribbon, open the BI Publisher tab and click Sample XML within the Load Data group.

  3. Select the .xml file you downloaded to import sample data from the data model.

  4. At the beginning of your .rtf document, replace the path with the location of the downloaded subtemplate file on your computer. For example, change <?import:xdoxsl:///Common Content/Templates/Workflow Notification Subtemplate.xsb?> to <?import:file:///C:/Template_Directory/FinFunWorkflowNotificationSub.rtf?>.

  5. From the BI Publisher tab on the ribbon, click HTML in the Preview group.

  6. If the preview reflects your changes as expected, then change the path back to the original location.

  7. From the BI Publisher tab on the ribbon, click Validate Template in the Tools group.

  8. Also in the Tools group, click Check Accessibility.

  9. Save your changes in Word.

Define Where and How to Act On Workflow Tasks

By default, users can act on workflow tasks from email notifications, their worklist, and anywhere else they get to the task. They can add comments while updating the task outcome, for example to explain why they're rejecting something. For any workflow task, you can set it up so that users can act on tasks only when they're in the application, not from emails. You can also make it mandatory, optional, or not allowed to enter comments when approving or rejecting tasks. For example, you might require comments for auditing or regulatory purposes.

  1. In the Setup and Maintenance work area, go to Manage Task Configurations or another approval setup task in the Application Extensions functional area or another functional area.

  2. In BPM Worklist, on the Task Configuration tab, select the workflow task.

  3. Click the Edit task icon in the Tasks to be configured toolbar.

  4. Open the Configuration subtab.

  5. In the Approval Pre-conditions section, for the Approve and Reject lists, select an option to determine if comments are required, optional, or not allowed when users approve or reject.

    Note:
    • These settings apply only to new tasks that are submitted after you finish these steps, not to tasks that are already in progress.

    • The validation applies right before the user approves or rejects. For example, let's say comments are not allowed for approval. If users add a comment and then do something else immediately, like save, and then click Approve, they won't get an error. If they add a comment and then immediately click Approve, they would get an error.

    • The settings may or may not actually take effect, depending on which workflow task you're configuring and where users are approving or rejecting from.

  6. Select the Perform update outcome only from task form check box if you want users to update tasks only from the application, not from email.

  7. Click the Commit task icon in the Tasks to be configured toolbar when you're ready to roll out your changes.

Change Workflow Task Titles

Users see titles for workflow tasks in many places, such as the notifications list in the global header, or the Worklist: Notifications and Approvals work area. You can change task titles and even set up titles for specific languages. So for example, people using the application in Spanish see the task title you define for Spanish.

This screenshot shows parts of the Task Configuration tab in BPM Worklist, where you can define the task title.

General subtab with the Title field and the Title
icons
  1. In the Setup and Maintenance work area, go to the Manage Task Configurations task or another approval setup task in the Application Extensions functional area or another functional area.

  2. In BPM Worklist, on the Task Configuration tab, select the workflow task.

  3. Click the Edit task icon in the Tasks to be configured toolbar.

Tip: At any time before you click the Commit task icon in the Tasks to be configured toolbar, you can still click the Reset icon to go back to the predefined title.

Define a Single Title for All Languages

If you want different titles for specific languages, skip this section and follow the steps in the next section.

  1. On the General subtab, click the first Title icon after the Title field.

  2. Use the expression builder to define what's shown as the title at runtime.

  3. Click OK.

  4. Click the Commit task icon in the Tasks to be configured toolbar when you're ready to roll out your changes.

Define Different Titles for Specific Languages

Repeat these steps for each language where you want to override the predefined title.

  1. On the General subtab, click the second Title icon after the Title field.

  2. In the Translations dialog box, select a language in the Locale list.

  3. Click the Add Row icon.

  4. In the Key column, enter whatever you want to identify this title with. If you choose to use this title, then the key is shown in the Title field on the General subtab. Users won't see it.

  5. In the column with the locale name, enter the title that users see. If you want the title to have variables, then use numbers in braces for each variable, starting with 0. For example, your title can look something like this: Request from {0} for Transaction {1}.

    1. Click the Edit icon if you have any variables.

    2. In the Edit Arguments dialog box, click the Expression Builder icon in the Value column.

    3. Use the expression builder to define what's shown in the title at runtime instead of the variable.

    4. Click OK to get back to the Translations dialog box.

  6. Optionally add more rows and define more titles in the Translations dialog box for this language, for example, if you have other titles you might want to use later.

  7. In the Translations dialog box, select the title to use for this language, and click OK.

  8. Click the Commit task icon in the Tasks to be configured toolbar when you're ready to roll out your changes.

Workflow Task Life Cycle

Define When to Automatically Dismiss or Withdraw Workflow Tasks

Only workflow tasks with a final status, such as Completed or Withdrawn, can be purged and removed from users' worklists. Tasks go from the Assigned status to the Completed status when the final assignee approves or rejects the tasks, or, with for your information (FYI) tasks, when assignees explicitly dismiss the tasks. If assignees don't take actions that result in a final task status, within a certain period of time, then the tasks are automatically dismissed (FYI tasks) or withdrawn (all other tasks).

When Tasks are Eligible for Automatic Dismissal or Withdrawal

The FYI Notifications Expiration Period profile option determines when FYI tasks are eligible for automatic dismissal. In the Setup and Maintenance work area, use the following:

  • Functional Area: Application Extensions

  • Task: Manage Applications Core Administrator Profile Values

On the Manage Applications Core Administrator Profile Values page:

  • Leave the profile option with the default value of 7, or replace it with a different number.

  • The profile value represents the number of days after the FYI task is created.

When assignees don't read or dismiss an FYI task within the specified number of days after the task was created, the task is then eligible to be automatically dismissed. All other tasks are eligible for automatic withdrawal when assignees don't take action to send the task to a final status within six months after the task was created.

When Eligible Tasks Are Automatically Dismissed or Withdrawn

Different processes run to automatically dismiss eligible FYI tasks or withdraw all other eligible tasks.

  • FYI Tasks: The process runs every three days, starting the first day of each month. For example, it runs on May 1, 4, 7, and so on, and again on June 1 and every three days after. So, if you leave the FYI Notifications Expiration Period profile value at 7, then depending on when the process runs, an FYI task can be automatically dismissed within seven to ten days after it's created. The process changes the FYI task status from Assigned to Completed.

  • All Other Tasks: The process runs every three days, starting the second day of each month. For example, it runs on May 2, 5, 8, and so on, and again on June 2 and every three days after. The process changes the status of eligible tasks to Withdrawn.

How Workflow Tasks Are Archived and Purged

Workflow tasks with a final status, such as Completed or Expired, can be archived and purged. Archiving keeps a copy of the task data for audit, data retention or analysis, and other purposes. Purging removes the completed tasks from users' worklists and permanently deletes the original data.

Archive

Tasks are automatically archived once a month without you doing any setup. You can't change or stop this automatic archive. You can, however, also run the Archive Workflow Tasks scheduled process as needed; for example, you need the latest data archived immediately for reporting purposes. The process includes all eligible tasks that aren't yet archived.

Archived data includes task details, approval history, comments, and attachments. How you view or use the archived data depends on the products you're using. For example, the data might be displayed in a table on a page, or available through a business intelligence subject area that you can select to create an analysis.

Purge

Archived tasks that were last updated over 30 days ago are immediately purged after the monthly automatic archive, without you doing any setup. You can't change or stop this automatic purge.

You can add the Worklist: Notifications and Approvals region to My Dashboard, which is a blank dashboard by default. This region displays the workflow tasks assigned to the person using My Dashboard. After you add the Worklist region, select a value for the Welcome Dashboard Worklist Timeout Interval (ATK_HOME_PAGE_WORKLIST_TIMEOUT) profile option.

Adding the Region

To add the Worklist: Notifications and Approvals region to My Dashboard:

  1. Click Navigator > My Dashboard.

  2. Click your user image or name in the global header, and select Edit Pages in the Administration menu group.

  3. Click the Add Content button where you want to place the region.

  4. Open the Application Content folder in the Add Content dialog box.

  5. Click Add for the Worklist: Notifications and Approvals item.

  6. Click Close.

  7. Save your work, and then click the Close button.

Defining the Timeout Interval

When users open My Dashboard and it contains the Worklist: Notifications and Approvals region, data for the region is retrieved. The Welcome Dashboard Worklist Timeout Interval profile option determines how long to continue retrieving before timing out and displaying no data. In the Setup and Maintenance work area, use the following:

  • Functional Area: Application Extensions

  • Task: Manage Application Toolkit Administrator Profile Values

Note: If you don't see this task, then make sure that the Application Toolkit Component Maintenance feature is enabled at the offering level in the Offerings work area.

On the Manage Application Toolkit Administrator Profile Values page, set the Welcome Dashboard Worklist Timeout Interval profile option.

  • If you don't set a value for this profile option, which is blank by default, then the region doesn't time out.

  • Retrieving data for the Worklist region affects the performance of My Dashboard as a whole. So, select a value for this profile option if your users have the Worklist region on My Dashboard and notice performance issues.

After the timeout, users can refresh the region to try retrieving the data again.