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.

Getting Started

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.

Assignments and Routing

How Workflow Task Routing Is Mapped Out

To determine how to route and assign a workflow task, the task configuration has at least one stage and one participant. In BPM Worklist, the Assignees subtab in the Task Configuration tab has a diagram that maps out the stages and participants. A participant represents a single user or group of users to assign the task to, and a stage is a way to organize those participants to map out the routing flow.

You can have one or more stages in sequence or in parallel. And within each stage, you can have one or more participants in sequence or in parallel:

  • Parallel: The task gets assigned and notifications are sent to all of the participants in the stage at once.

  • Sequential: The task gets assigned and notifications are sent to one participant and then another, in a specific order. All assignees need to approve sequentially to get the task approved.

Each participant has at least one rule set defined, and each rule set has at least one rule. Rules contain the conditions that must be met for the task to be assigned to a participant, and rules also determine whom to assign the task to.

Example

Let's take a look at a diagram mapping out a workflow task. The flow and placement of the boxes show what's in parallel or in sequence.

Example of diagram in the Assignees tab mapping
out workflow task
Callout Number What It Is In This Example

1

Stage

The outermost boxes in the diagram are stages. We see four of the stages in this task, and two of them are in parallel at the second step of the sequence for the task.

2

Participant

Each box within a stage is a participant. Three of the stages have one participant, and one stage has three participants, two of which are in parallel at the beginning of the sequence for the stage.

3

Go to rule icon

Each participant has an icon that you can click to open the rule sets and rules for that participant.

Types of Participants

There are four types of participants for workflow tasks. In the diagram on the Assignees subtab, each participant has an icon that tells you what type it is. If the icon for a participant is grayed out, that means the participant is disabled.

Single

The assignee is a single user or an application role. (Even though LDAP group is also a possibility, it's recommended that they're not used.) For example, the task is assigned to a user's manager, and the manager's approval is all that's needed for the request to go through. With application role, the task is routed to all users with the role, and someone can claim the task to work on it.

Icon for participants of type Single

Parallel

A set of assignees must work in parallel, usually by voting. For example, the task is assigned to people who must vote to decide whether to hire someone or not.

Icon for participants of type Parallel

Serial

A set of assignees must work in sequence, and the set is usually dynamic. For example, the task is routed up a supervisory chain for approval.

Icon for participants of type Serial

FYI

This is like the Single participant type, except that the assignees just get a notification and don't need to act on the task. In some cases, they can add comments or attachments, but they can't affect the outcome of the task.

Icon for participants of type FYI

Disable Stages or Participants

If a stage or participant doesn't apply based on your business requirements, you can disable it.

  1. In the Setup and Maintenance work area, go to the Manage Task Configurations task in the Application Extensions functional area. Or, depending on your offering, you might use a different functional area or another approval setup task.

  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 Assignees subtab.

  5. If the diagram mapping out the workflow task is big, click the Switch to Vertical Layout link.

  6. In the diagram, select the stage or participant you want to disable.

    • Stage: Click anywhere in the stage except inside the boxes representing participants.

    • Participant: Click in the box representing the participant.

  7. In the pane after the diagram, click the Advanced subtab.

  8. Select the Ignore Stage or Ignore Participant check box, depending on what you selected in the diagram.

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

Create Approval Groups

An approval group is a set of users that can act on workflow tasks. You can set up tasks so that at some point in the approval flow they get routed to an approval group instead of an individual user. An approval group can contain other approval groups.

  • When a task is assigned to an approval group in a parallel participant, someone in the group can claim the task and act on it. When the task is claimed, no one else in the group can act on it. But if the person who claimed the task releases it, then someone else from the group can claim it.

  • If it's a serial participant instead, the task is routed to each member of the approval group in sequence, so everyone must act on it.

  • There are two types of groups in workflow. One is the approval groups we are talking about here that you can use in task configurations to define routing. The other is LDAP groups that are available for users to select when they delegate or reassign tasks, but it's not recommended for them to use LDAP groups.

There aren't any predefined approval groups, so it's up to you if you want to create any. Here's how you go about it:

  1. In the Setup and Maintenance work area, go to the Manage Approval Groups task in the Application Extensions functional area.

  2. In BPM Worklist, on the Approval Groups tab, click the Create Approval Group icon in the Groups toolbar.

  3. On the Details page, enter the group name.

  4. In the Members section, click the Add Member icon.

  5. In the Add to Group dialog box, select User or Approval Group, depending on what you want to add to your group.

  6. Find and select the specific user or group, and click OK.

  7. Add more members, and edit or delete any if you need to.

    Note: For approval groups that you plan to use in serial participants, add members in the order that you want tasks to get assigned. If you add User 1, User 2, and then User 3, the task is first assigned to User 1, then User 2, and finally User 3.
  8. Click Save.

Caution: Don't delete your approval group if it's used in at least one approval rule. You can still edit the group.

Configure Approval Rule Sets and Rules

Rule sets and rules control how a workflow task is routed, assigned, and completed, based on specific conditions. For example, a rule can say that for a transaction that costs more than a certain amount, approvals must go up three levels in the management chain. A workflow task has one or more rule sets, and a rule set has one or more rules. At run time, if a rule set has multiple rules, all the rules are evaluated at the same time. A rule has two parts, an If section that has the conditions, or tests, and a Then section that has the actions to take when the conditions are met.

Configure Rule Sets

First, create or find the rule set you want to work on:

  1. In the Setup and Maintenance work area, go to the Manage Task Configurations task in the Application Extensions functional area. Or, depending on your offering, you might use a different functional area or another approval setup task.

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

    Note: You may see a message saying that flexfields have been modified. This means someone used Application Composer to create new fields, which creates flexfields on the back end. Click the Start Synchronization button to get the latest set of flexfields that you can use for the rules in this task.
  3. Click the Edit task icon in the Tasks to be configured toolbar.

  4. Click the Assignees subtab.

  5. If the diagram mapping out the workflow task is big, click the Switch to Vertical Layout link.

  6. In the diagram, find the participant you want to work on. Click the Go to rule icon and select Go to rule. Or, select the participant and, in the pane after the diagram, click the link in the Business rule field.

  7. Go on to work on the rule set that's displayed. Or, in the Rule Sets section, select another rule set to edit (or delete, if possible), or click the Add Rule Set icon.

  8. Click the Show Advanced Settings icon before the rule set name to see the Effective Date list and Active check box. The rule set needs to be effective and active to apply when people create workflow tasks. It's a good idea to leave the effective date set to Always.

  9. Now you're ready to add, edit, or delete rules in the rule set. Expand the rule if it's not already. As with the rule set, you can click the Show Advanced Settings icon for a rule to make sure that the rule is effective and active.

Here's a screenshot to help us understand what we see in the Assignees tab:

The Assignees tab where you configure rule sets
and rules
Callout Number What It Is

1

The Rule Sets section, where you can select a rule set to work on or create a new rule set.

2

The rule set name, with the Show Advanced Settings icon.

3

The toolbar for working on rules within the rule set.

4

The names of the rules in the rule set, each with the Expand icon and the Show Advanced Settings icon.

Configure the If Section in Rules

In the If section of the rule, define conditions for the rule. Each line in this section is called a test.

  1. Click the Left Value icon to select an attribute in the Condition Browser dialog box.

    Note: Even though you can find attributes starting at the Tasks folder, payload subfolder, and then going from there, it's better to select the same attribute from another folder other than Task, if available.
  2. Select an operator.

  3. Click the Right Value icon to select something from the Condition Browser dialog box, or enter a value in the corresponding field.

  4. Click the icon at the end of the line, after the Right Value icon, for more options. For example, select (...) to get an and or or toggle and add another line. You can also select Delete Test to remove a line.

    Caution: If the attribute you're evaluating in the condition is optional, users might not have entered something for that attribute in the UI. For your rule to work properly, it's highly recommended that you first have a line in the condition that checks if the attribute isn't blank. So that means you select the attribute, select isn't as the operator, enter null, click the icon at the end of the line, and select (...) to get an and. Then the next line would be the condition that you're evaluating the attribute for.

Configure the Then Section in Rules

In the Then section of the rule, define what happens when the conditions in the If section are met.

  1. Edit any existing actions. Or, click the Add Action icon, and you usually select Add Approver and then a list builder, which controls how to route the task.

  2. Fill in the rest of the section. The fields you get depends on the list builder, but here are some that you might use.

    Field What This Is

    Response Type

    Required: The assignee needs to take action, for example to approve or reject.

    FYI: The assignee doesn't need to take action.

    Number of Levels

    Number of levels required for the task to be completely approved, from the starting participant to the top participant.

    Starting Participant

    The first assignee in the approval chain.

    Top Participant

    The last assignee in the approval chain if the chain goes up that high. Approvals don't go beyond this participant, for example in the supervisory hierarchy.

    Auto Action Enabled

    If set to True, there's an automatic action that is taken on the task when the rule conditions are met.

    Auto Action

    "APPROVE": The task is automatically approved.

    "REJECT": The task is automatically rejected.

    Rule Name

    The name of the rule with the Then section that you want to use.

    • Leave the field with the name of the rule you're working on, to indicate that this rule will use the Then section defined here for this rule.

    • Or, you can enter the name of an existing rule from any task, enclosed with quotation marks, and leave all the other fields in this Then section blank. The Then section in the rule you entered would apply to this rule you're working on. So basically, you're reusing the Then section from another rule.

    To select the starting or top participant:

    1. Click the Starting Participant or Top Participant icon.

    2. In the Add Hierarchy Participant dialog box, select the Get User option for a particular user, or Get Manager for an attribute, such as the task creator.

    3. For the Get Manager option only, select the list builder that's used for the rule.

    4. For the Get User option, enter in the Reference User field the user ID that the user signs in with, enclosed in quotation marks, for example "KLEE".

      For the Get Manager option, here's what you do for the Reference User field:

      1. Click the Expression Builder icon.

      1. In the Variables tab of the Expression Builder, select the attribute you want in the hierarchy. For example, expand Task > payload and find your attribute there.

      2. Click the Insert Into Expression button.

      3. Click OK.

    5. Leave the Effective Date field blank to use the latest hierarchy, for example supervisory hierarchy.

    6. Click OK.

    What shows up in the Starting Participant or Top Participant field reflects what you have in the Add Hierarchy Participant dialog box. Here are a couple of examples.

    • HierarchyBuilder.getManager("supervisory",Task.payload.Owner User Name,-1,"","")

      Part of the Participant Value What This Means

      getManager

      You selected the Get Manager option.

      "supervisory"

      You selected the Supervisory list builder.

      Task.payload.Owner User Name

      For the Reference User field, you went to Task > payload > Owner User Name in the Variables tab to select the Owner User Name attribute.

      -1

      This is the default value, which corresponds to the primary employment assignment. That supervisory hierarchy will be used to find assignees for the task.

      "",""

      You left the Hierarchy Type and Effective Date fields blank, so there's nothing between the quotation marks.

    • HierarchyBuilder.getPrincipal("KLEE","","")

      Part of the Participant Value What This Means

      getPrincipal

      You selected the Get User option.

      "KLEE"

      For the Reference User field, you entered "KLEE".

      "",""

      You left the Hierarchy Type and Effective Date fields blank, so there's nothing between the quotation marks.

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

Example of a Rule

Let's take a look at an example of a rule. In the If section, we have two tests, the first checking if an attribute is a specific value, the second checking if an attribute is more than a certain amount. The attribute names reflect where the attribute is in the hierarchy you get in the Condition Browser dialog box. The and connecting the two tests means that both conditions must be met.

Example of the If section in a rule

In the Then section, there's the action that applies if the conditions are met, and it's defined based on a Supervisory list builder. Assignees must take action, and only one approval is needed.

Example of the Then section in a rule

List Builders

A list builder is the method to use for routing a workflow task, for example, by going up the supervisory hierarchy or sending to an approval group. When the conditions in a rule are met, the task is assigned based on the action in the Then section of the rule. To define an action, you select a list builder and then provide settings for that list builder to determine whom to assign the task to.

Here are the available list builders:

  • Approval Group

  • Job Level

  • Management Chain

  • Position

  • Resource

  • Supervisory

Let's take a closer look at some of the more widely used list builders.

Approval Group

An approval group is a specific set of users that can act on a task. Depending on the participant type, tasks are routed to an approval group in serial or parallel.

  • Parallel: Someone in the approval group can claim the task and act on it. When the task is claimed, no one else in the group can act on it. But if the person who claimed the task releases it, then someone else from the group can claim it.

  • Serial: The task is routed to each member of the approval group in sequence, so everyone must act on it.

After you select Approval Group as the list builder, you select the approval group to assign the task to when the rule's conditions are met. If you select True for the Allow empty groups list, there won't be any errors if the group you select doesn't have any members when the rule is evaluated. In most cases, the task is then rejected or routed back to the previous assignee, with the same status that the task was in when it was first routed to that assignee.

Job Level

This routing is based on the supervisor hierarchy in Oracle HCM Cloud. Employees must be set up in HCM with job levels and supervisors. The approval chain goes up the hierarchy and includes assignees based on what you define. For the number of levels, enter a positive number in the At most or At least fields, or both. And select a value from the relative to list.

Number of levels settings for the job level list
builder
  • At least: Let's call the corresponding job level X1.

    • Users in the hierarchy are included in the list of assignees if their job level is less than X1. As soon as we get to a user whose job level is the same as or more than X1, the list of assignees includes that user but goes no further.

    • The at least condition takes precedence, so after it's met first, then the at most condition is applied from where the at least condition left off.

  • At most: Let's call the corresponding job level X2.

    • We start with the last assignee from the at least condition. If their manager's job level is less than or the same as X2, then their manager is added to the assignees list and becomes the last assignee. The manager of this new last assignee is then evaluated the same way, and so on up the hierarchy.

    • When we reach a job level that's more than X2, the list of assignees ends, and that user isn't included.

The job levels that X1 and X2 represent depend on what you select from the relative to list. Here are examples of what X1 and X2 would be if you enter 3 in the At most and At least fields.

Relative To What That Means What X1 and X2 Would Be

Absolute

The first job level, job level 1

Job level 3

Creator

The user who did something to create a workflow task

Job level 5, if the user at job level 2 created the task

Starting Point

What you define in the Starting Participant field

Job level 6, if the starting participant corresponds to the user at job level 3

Also, there are a couple of optional settings you can use for the job level list builder:

  • Utilized Participants: Include the entire assignee list or just a part of it.

    • All approvers: Everyone in the list.

    • Final approver only: Just the very last assignee in the list.

    • Manager and final approver: The first assignee in the list and the very last assignee.

  • Include all managers at last level: Include all users with a job level that's the same as the last level needed for approval.

Let's take a look at some examples of what the assignee list would be from this reporting hierarchy:

  • Clerk (job level 1)

  • Manager (job level 2)

  • Director (job level 3)

  • Vice president (job level 5)

  • Senior vice president (job level 6)

  • Chief executive officer (job level 6)

For all the examples, the clerk at job level 1 created the task, and the rule has these settings:

  • Relative to: Absolute

  • Starting Participant: Manager at job level 2

  • Top Participant: Job level 6

  • Utilized Participants: All approvers

At Least (X1) At Most (X2) Include All Managers at Last Level Assignees

3

3

No

The assignees are the manager (job level 2) and director (job level 3).

  • Starting participant: Manager at job level 2 is included no matter what.

  • At least condition: Director at job level 3, the last and only assignee for this condition because he has the first job level that's the same as or more than X1.

  • At most condition: No match because the director's manager, the vice president, has a job level (5) that's more than X2.

2

5

No

The assignees are the manager (job level 2), director (job level 3), and vice president (job level 5).

  • Starting participant: Manager at job level 2 is included no matter what.

  • At least condition: Director at job level 3, the last and only assignee for this condition because he has the first job level that's the same as or more than X1.

  • At most condition: Vice president at level 5, because she is the director's manager and has a job level that's the same as X2. But, her own manager isn't included because the senior vice president's job level (6) is more than X2.

4

6

No

The assignees are the manager (job level 2), director (job level 3), vice president (job level 5), and senior vice president (job level 6).

  • Starting participant: Manager at job level 2 is included no matter what.

  • At least condition: Director, whose job level (3) is less than X1, and the vice president, who is the last assignee for this condition because her job level (5) is the first that's the same as or more than X1.

  • At most condition: Senior vice president at level 6, because he is the vice president's manager and has a job level that is the same as X2.

4

6

Yes

The assignees are the manager (job level 2), director (job level 3), vice president (job level 5), senior vice president (job level 6), and chief executive officer (job level 6).

This example is the same as the previous one, except that the Include all managers at last level check box is selected. So in this case, the CEO is also an assignee because she has the same job level as the senior VP, who is the last assignee based on what's defined for the rule.

1

1

No

The only assignee is the manager (job level 2).

  • Starting participant: Manager at job level 2 is included no matter what.

  • At least condition: The manager is already the first assignee with a job level that's the same as or more than X1, so the condition is already met.

  • At most condition: No match because the manager's manager, the director, has a job level (3) that's more than X2.

Resource

You can assign the task to a specific user or application role. (Even though LDAP group is also a possibility, it's recommended that you don't use them.) Select the assignee in the Users or Application Role field, and leave the other fields for participants with null.

Supervisory

This routing is based on the supervisory hierarchy in Oracle HCM Cloud. Employees must be set up in HCM with jobs and supervisors. For example, the clerk reports to the manager, who reports to the director, who reports to the vice president. The list of assignees begins with the starting participant in the rule, then goes up the supervisory hierarchy. The list ends when it has gone through the specified number of levels or reached the top participant, whichever comes first.

Here's an example of an action in the Then section of the rule, based on the supervisory list builder.

Field Example of a Value What This Means

Number of Levels

3

Three approvals are needed

Starting Participant

HierarchyBuilder.getPrincipal(Task.Workflow Submitter,-1,"","")

The user who created the task

Top Participant

HierarchyBuilder.getPrincipal("KLEE",-1,"","")

The person with the user ID KLEE, in this case, the vice president

So with the reporting structure from the clerk to the vice president, say the clerk submits a transaction that creates a workflow task. The starting participant is the clerk, so the task would go first to the clerk, the manager, and then the director. Because only three levels of approvals are needed, the task is completely approved without going up to the vice president, who would be the final assignee no matter how many levels are needed.

Define Rules to Automatically Approve or Reject Workflow Tasks

You can configure a rule so that the workflow task is automatically approved or rejected without having to send it to any approver. These are the main things to do for your rule in the Then section:

  • Set up the routing so that the task gets assigned to the application (workflowsystem) or the submitter (Task.Workflow Submitter).

  • Select True for the Auto Action Enabled list.

  • Enter "APPROVE" or "REJECT" in the Auto Action field.

Here's an example of the Then section for a rule that's set up to automatically approve.

Field Value

List Builder

Supervisory

Response Type

Required

Number of Levels

1

Starting Participant

HierarchyBuilder.getPrincipal("workflowsystem",-1,"","")

or

HierarchyBuilder.getPrincipal(Task.Workflow Submitter,-1,"","")

Starting Participant

HierarchyBuilder.getPrincipal("workflowsystem",-1,"","")

or

HierarchyBuilder.getPrincipal(Task.Workflow Submitter,-1,"","")

Auto Action Enabled

True

Auto Action

"APPROVE"

Rule Name

Example Approval

Dimension ID

null

For a rule that's set up to automatically reject, the only difference is that the Auto Action field has "REJECT" instead.

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.

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.

Define the Due Date and Expiration Policies for Workflow Tasks

If you want workflow to finish within a general time frame, you can set a due date, expiration policies, or both.

  • Before the due date, the current assignee will be reminded to take action. Even after the due date passes, the task doesn't expire. The assignee, and any approvers after them, can still act on the task.

  • 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.

Overall Process

Here's how you set the due date, expiration policies, or both for a specific workflow task:

  1. In the Setup and Maintenance work area, go to Manage Task Configurations or another approval setup task in Application Extensions 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 Deadlines subtab and make your changes.

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

Let's take a look at the Deadlines subtab and what you can set up there.

Deadlines subtab where you set due date and expiration
policies

Specify a Due Date

On the Deadlines subtab, specify how much time you want to give to approvers. For example, if you enter 14 days for the Due Date fields, that means the task is due 14 days after it's created. All approvals should be done by then.

Indicate How Tasks Would Expire

If you want to set expiration policies, do this first:

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

  2. Indicate how the task would expire:

    • Task Level: If all approvals aren't done within a certain time frame

    • Assignee Level: If the assignee doesn't act on the task within a certain time frame

  3. Now let's move on with the rest of the setup, which depends on the level you selected.

There's no expiration policy if you leave it at Do Nothing. The task is automatically withdrawn if it's still open after the number of days (180) you see in the Open Tasks Withdrawn After Number of Days field. That field is on the Application Preferences page, which you can get to by opening the Administration tab in BPM Worklist.

Define Expiration Policies at the Assignee Level

If you selected Assignee Level, here's how you set expiration policies, including any escalations or renewals:

  1. In the Expiration Settings section of the Deadlines subtab, enter a duration and optionally select the Exclude Saturday and Sunday check box. Let's say you enter 30 days and select the check box:

    • With sequential routing, the task expires if the last assignee doesn't act on the task within 30 weekdays after the task is routed to them. If the first assignee doesn't act within 30 weekdays, the task is passed to the next assignee, who gets another 30 weekdays. This goes on until the last assignee.

    • With 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 to escalate or renew tasks after they expire, select the Escalate or Renew option. If not, leave the Expire only option selected.

  3. To escalate, indicate how many times to go up the management chain. Suppose you enter 2 in the Maximum Escalation Levels field. Here's what happens when the task expires:

    • With sequential routing, the task goes to the manager (User 2) of the last assignee (User 1).

    • With parallel routing, the task goes to the managers (User 2) of all current assignees (User 1).

    When User 2 doesn't act within 30 weekdays, the task is escalated to the manager of User 2, who has another 30 weekdays before the task goes to 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. Here's what happens when the task expires:

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

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

    If they still don't act within those 30 weekdays, they get another 30 weekdays before the task goes to a final Expired status.

Define Expiration Policies at the Task Level

If you selected Task Level, here's how you set expiration policies, including any escalations or renewals:

  1. In the Expiration Settings section of the Deadlines subtab, enter a duration and optionally select the Exclude Saturday and Sunday check box. Let's say you enter 30 days and select the check box:

    • The task expires if all approvals aren't 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 gets only five weekdays.

  2. If you want to escalate or renew tasks after they expire, select the Escalate or Renew option. If not, leave the Expire only option selected.

  3. To escalate, indicate how many times to go up the management chain. Suppose you enter 2 in the Maximum Escalation Levels 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, the task is escalated to the manager of User 2, who has another 30 weekdays before the task goes to 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 all don't act within that period, they get another 30 weekdays before the task goes to a final Expired status.

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 Show All.

  3. On the Notifications page, click the Worklist button.

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

  5. 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: Settings for the notifications list in the global header also apply to the Things to Finish section on the home page. And to the Notifications page, which you open from the notifications list or the Things to Finish section.
  6. 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

Aggregate Tasks to Minimize the Number of Notifications to Send

Depending on the rules in a workflow task, it's possible that a task is assigned to the same user more than once. For example, the rules in a stage can result in assigning a task to you, but then a later stage in the same task also results in assigning the task to you. You can aggregate the task so that a separate notification isn't sent to the assignee every time they're assigned the same task.

  1. In the Setup and Maintenance work area, go to the Manage Task Configurations task in the Application Extensions functional area. Or, depending on your offering, you might use a different functional area or another approval setup task.

  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 Miscellaneous section, select a value from the Task Aggregation list:

    • None: Send separate notifications every time the task is assigned to the same assignee.

    • Once per task: Send a single notification to the assignee no matter how many times they're assigned the same task.

    • Once per stage: Send a single notification to the assignee if they're assigned the same task more than once within a stage. If they're assigned the same task again because of another stage, they would get another notification for that stage.

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

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.

Note: Your users might get other types of email notifications, for example for things not related to workflow. Your setup here doesn't affect those emails, and you might not be able to specify the sender name for those emails.
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 Show All.

    3. On the Notifications page, click the Worklist button.

    4. In BPM Worklist, 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.

Workflow email notifications can have attachments. For example, when you request information from someone as part of the workflow, they might respond with a message and a file attachment. The email notification you get when they respond would include their attachment. Many workflow tasks have this already set up by default. Here's how you can enable email attachments or change the default setup.

Enable or Disable Email Attachments

You can turn on or off email attachments for specific workflow tasks.

  1. In the Setup and Maintenance work area, go to the Manage Task Configurations task in the Application Extensions functional area. Or, depending on your offering, you might use a different functional area or another approval setup task.

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

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

  4. Click the Notifications subtab.

  5. Expand the More section.

  6. Select or deselect the Send task attachments with email notifications check box.

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

Set Maximum Number and Size of Attachments

These settings apply to all workflow tasks that have email attachments enabled.

  1. Click the Notifications icon in the global header.

  2. Click Show All.

  3. On the Notifications page, click the Worklist button.

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

  5. On the Application Preferences page, go to the Notification section.

  6. In the Maximum Number of Email Attachments field, enter a whole number to limit the number of attachments in a single email.

  7. In the Maximum Size of Email Attachments (in MB) field, enter a whole number up to 10 to limit the size of individual attachments in the email.

    Tip: If you want the emails to have links to files instead of having the files attached to the email, enter 0 in at least one of these two fields.
  8. Click Save.

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 Show All.

  3. On the Notifications page, click the Worklist button.

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

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

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

  7. 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

  • BIP_CLIENT_REFRESH_TIME_SCM_EGO

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 aren't 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

For a workflow task to be purged and removed from users' worklists, it must have a final status, like Completed or Withdrawn. Tasks go from the Assigned status to the Completed status when the final assignee approves or rejects the tasks. For your information (FYI) tasks get a final status when assignees explicitly dismiss the tasks. If assignees don't do anything within a certain period of time that result in a final task status, the tasks are automatically dismissed (FYI tasks) or withdrawn (all other tasks).

When FYI Tasks Are Eligible to Be Automatically Dismissed

The FYI Notifications Expiration Period (FND_NOTIFICATION_EXP_PERIOD) profile option controls when FYI tasks are eligible to be automatically dismissed.

  1. In the Setup and Maintenance work area, go to the Manage Applications Core Administrator Profile Values task in the Application Extensions functional area.

  2. On the Manage Applications Core Administrator Profile Values page, leave the profile option with the default value of 7 at the Site level, 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 this many days after the task was created, the task is then eligible to get automatically dismissed.

When All Other Tasks Are Eligible to Be Automatically Withdrawn

All other tasks (the ones that are not FYI) are eligible to be automatically withdrawn if both of these things happen:

  • The expiration settings for the particular task is set to Do Nothing on the Deadlines subtab, within the Task Configuration tab in BPM Worklist.

  • Assignees don't take action to send the task to a final status within 180 days after the task was created. This number is reflected in the Open Tasks Withdrawn After Number of Days field on the Application Preferences page, which you can open by clicking the Administration tab in BPM Worklist.

When Eligible Tasks Are Automatically Dismissed or Withdrawn

Now we know when tasks are eligible, but when are they actually dismissed or withdrawn automatically?

  • FYI tasks: A 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, 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 task status from Assigned to Completed.

  • All other tasks: A 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 task status to Withdrawn.

How Workflow Tasks Are Archived and Purged

Workflow tasks with a final status like 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 day without you having to set anything up. You can't change or stop this automatic archive, which includes all eligible tasks that aren't archived yet. These scheduled processes run in this order to get the daily archive done:

  • Extract Workflow Tasks for Archive

  • Process Translations for Workflow Tasks Archive

  • Upload Workflow Task Attachments for Archive

Though unlikely, if you ever need to archive more frequently, you can use the Scheduled Processes work area to manually run these processes in the same order. Make sure one process finishes before you submit another.

You have the option to set parameters for the Extract Workflow Tasks for Archive process. But let's say you leave the default with 50000 as the number of tasks in a batch and a maximum runtime of 120 minutes. That means the process will archive in batches of 50000 workflow tasks. If it's still running after two hours, the process finishes archiving the current batch and then stops. You can check the log file of the process to see how many tasks are included in the archive.

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 daily 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 > Others > 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.

Monitor and Troubleshoot

Manage Workflow Transactions

After workflow tasks are created, it's helpful to keep track of them and jump in when you need to, especially when something goes wrong. If you have the appropriate roles, you can monitor and troubleshoot workflow tasks for others and for yourself. Use the Transaction Manager: Transactions page in the Transaction Console work area to manage transactions. A transaction is a business process that involves a workflow task.

Here are some of the things you can do:

  • Track transaction statuses and download spreadsheets with information about transactions.

  • Download and review diagnostic logs for transactions with errors.

  • Depending on what's going on with the transaction and what roles you have, you might be able to, for example, reassign or recover the transaction.

Find Transactions

Follow these steps:

  1. Click Navigator > Tools > Transaction Console.

  2. If you see tabs, make sure you're on the Transaction Summary tab.

  3. On the Transaction Manager: Transactions page, check the Last Refresh time stamp after the page title to see when the transaction statuses were last updated. Click the Refresh icon if needed. You can refresh any time as long as someone else didn't already start a refresh.

    • You can also set the Refresh Transaction Administrator Console Transaction Status scheduled process to run on a schedule, to automatically refresh the statuses on a regular basis. Start by setting it to run once every hour, and then see how it goes and adjust from there.

    • If you open the details for a specific transaction (step 5), its status also refreshes and you see the latest on the details page.

  4. View the transactions with a status that matches the default Status filter, for example Failed. You can remove this filter to get results for all statuses. Or, use the search and filters to apply your own criteria, for example, to find transactions that are priority 1 or submitted by a specific person.

    • You can use the search to find results based on keywords in the Name or Process Name column, or specifically use the Name or Process Name filters. Name is the person or object the workflow task applies to, and the process reflects the type of workflow task.

    • You can personalize filters to add or hide filters, and create saved searches for future use.

  5. Select and act on the transactions right there from the results table, or click the transaction in the Name column to see details, such as diagnostic information for failed transactions, and go from there.

Act On Transactions Without Opening Details

Here's what you do:

  1. Select one or more transactions from the results table.

  2. Optionally use the Priority menu to set an issue priority, so that you can later filter on the priority to find these transactions.

  3. Open the Actions menu and select an action. If you selected more than one transaction, you see only the actions that can apply to all of them.

Use Transaction Details

What you can see and do in the transaction details depends on the transaction status and what roles you have. For example, for transactions that are in progress or completed, you might see the approval history, which shows who already approved and who the current assignee is, if any.

For failed transactions, you can get information about the issues and, if you're an administrator, usually take some action:

  1. Select an issue from the Issues list, if the transaction has more than one issue.

  2. Review the information in the Instructions and Details sections, including any description and resolution for the issue, as well as the related workflow task and approval rule.

  3. Click the Download link to get the diagnostic log.

  4. Use the Issue Priority list to set an issue priority, if you want to later filter on the priority to find this transaction.

  5. From the Assigned To list, select the person who should fix the issue, for tracking and filtering purposes.

  6. Add comments, for example to track what you're doing to address the issue, or note down any service request IDs. You and others can see these comments only in the Transaction Console, not with the workflow task in the worklist.

  7. If you can, take action to address the issue. Here are some examples of how you might go about it:

    • Open the Actions menu and select an action to manage the transaction.

    • Follow up with the person you assigned the issue to or your help desk. Give them the diagnostic log and other information from the transaction details.

    • Reconfigure the approval rule that the transaction is based on, and have the workflow task resubmitted.

  8. Select another issue from the Issues list, if any, and go through the same process.

  9. Click Save and Close.

Download a Spreadsheet of Transactions

This is all you need to do:

  1. In the results table, select the transactions you want to include in the spreadsheet. To get all transactions, either select all of them or none at all.

  2. On the Actions menu, click Download.

Statuses for Filtering Transactions

Use the Transaction Manager: Transactions page in the Transaction Console work area to track the status of transactions. For example, you can filter the transactions by status to see just the transactions that are in progress or stuck. These statuses aren't the actual workflow task statuses that you see in the worklist or in notifications.

Status Description

Auto Recovery

The transaction ran into some issues, but the application is trying to fix them without any action on your end.

Completed

All approvals are done and the transaction successfully went through all processes.

Draft

The transaction is saved but not submitted yet. This status doesn't apply to all product families.

Failed

The transaction has one or more errors, for example, due to a network or database outage, or an issue in the approval rules setup.

In Progress

At least one approval is still pending for the transaction before it's all done.

Stuck

The transaction was submitted, but ran into issues so the workflow task doesn't exist yet.

Submitted

The transaction was just created and hasn't moved on yet to another status. This status doesn't apply to all product families.

Actions for Managing Transactions

Use the Transaction Manager: Transactions page in the Transaction Console work area to manage and troubleshoot transactions. For example, you can withdraw a transaction even if you're not the one who submitted it. What you can do depends on the transaction status and the roles you have. Some actions, such as approve and reassign, are the same as the ones you can take on the workflow tasks from the worklist or from notifications.

Action Description

Add Comment

Add your notes for the transaction, for example to track what you're doing to address the issue, or to jot down any service request IDs. You and others can see these comments only in the Transaction Console.

Alert Initiator on Error

Notify the submitter if the transaction ends up in error.

Approve

Approve the transaction if the workflow task is currently assigned to you to approve or reject.

Download

Get a spreadsheet with information about the selected transactions.

Reassign

Reassign the workflow task to an approver, the submitter, or someone else.

Recover

Restart the process after the transaction stopped due to errors. After you address the issue, use this action to get the application to pick up where the process last left off and retry whatever had ended up in error.

Reject

Reject the transaction if the workflow task is currently assigned to you to approve or reject.

Terminate Process

Completely end the transaction so that no one can see or act on the workflow task again.

Withdraw

Remove the workflow task from the workflow. You can ask the submitter to submit again, for example, after an issue is resolved.

Things to Check If There Are Issues with Workflow Tasks

After you configure workflow tasks, it's possible to run into some issues when they're actually in use. In general, use the Transaction Console work area to monitor tasks and review details about errors. Let's take a look at some issues that might come up and how you can proceed when they do.

Task Isn't Getting Assigned to Approvers

One main way to tell this is happening is that when users open a workflow task, they see a message saying that the approval history can't be displayed. That usually means something about the related approval rule is not quite right, so approvers can't be found. Here are some things to check to make sure the rules are working correctly:

  • Click the Show Advanced Settings icon for the rule set and rules to make sure that both are active and effective.

  • If the rule is routing to an approval group, make sure that the group actually exists and has members.

  • If the list builder is using the supervisory hierarchy, check for these things:

    • Are there enough manager positions to fulfill the number of levels needed for approval?

    • Does the supervisor hierarchy go up that far from the task creator or the person the task is created for, depending on which is the starting participant?

    • Is there a top participant defined in the rule?

    • Is the rule configured to always route to an implementation user instead of managers in the hierarchy?

  • Review the rules in general to make sure the conditions have enough information to be true.

  • If the rule is defined to automatically approve or reject, ask the task creator to try and submit their transaction again.

Assignees Don't Get a Notification

In the Transaction Console work area, look for the transaction, which would have an error. If available as an option, withdraw the transaction. Otherwise, review the error and logs, if any, and address the issue.

To confirm that something went wrong with the notification, the task creator or the current assignee can also check for tasks with errors, for example in the notifications list in the global header or the Worklist: Approvals and Notifications work area.

Assignees Can't Approve By Email

Here are some things to check:

  • Is this an email-only issue? Can the assignee can approve from somewhere else, for example the notifications list in the global header or the Worklist: Approvals and Notifications work area?

  • Does the email have links that the assignee can click to take action? If not, open the task configuration and make sure that the Make notification actionable check box is selected in the More section of the Notifications subtab.

  • Did the assignee already take action on the task elsewhere, outside email?

Pending Task Prevents Further Update

If there's no movement on a task for a while, future approvers can't act on the task and move things along.

  • It could be that there's nothing wrong. The task is just pending action from the current assignee. In which case, remind them to act on the task.

  • Find out who created the task and check if there's an error with the task.

    • If you recently had an upgrade and the error wasn't already there before the upgrade, make sure to resolve the issue.

    • If the creator wants to withdraw the task, whether there's an error or not, they can do that themselves or have you withdraw for them from the Transaction Console work area.

Approvals Are Complete But Result Isn't Reflected

Even though a workflow task has a Completed status, it could be that what you expect to happen next due to the approval hasn't happened yet. In which case, check on these things:

  • Did all approvers act on the task? Did any approver reject?

  • Has the task expired? Check the task configuration to see if expiration policies are set on the Deadlines subtab. Also, the task creator should have received a notification if it expired.

  • Did the task creator get any notifications about errors with the task? In the Worklist: Notifications and Approvals work area, they should select Any for the Status filter to make sure they review all notifications.