Slide 3 - Oracle Sales Cloud Release 11
Slide notes
Hello, my name is Peggy. Welcome to the training for Release 11. In this session I will talk about what’s coming in Oracle Sales Cloud around paysheet approval.
Notes
Slide 4 - Agenda
Slide notes
For the enhancement covered in this training, I’ll start with a high-level overview, followed by more detail to explain how you can use the enhancement, and what business value it can provide. Then, I’ll walk you through a functional demonstration so you can get a better idea for how the feature works. Next, I’ll explain what you need to consider before enabling the feature in your business, and what you need to know to set it up, including two setup demonstrations.
Notes
Slide 5 - Enhancement Overview
Slide notes
When your paysheet approval processing requirements go beyond incentive compensation analyst and manager approval, your application administrator can now edit the approval flow and configure rules for determining your approvers. The approver can come from the participant’s supervisor hierarchy, a group that you define, or a specific user. This feature still supports your governance requirements while giving you more flexibility and control over your paysheet approval processing.
Notes
Slide 6 - Configurable Payment Approval Workflow
Slide notes
With this enhancement you can graphically design your approval policy into parallel and sequential steps.
You can route the approval notifications based on rules. For example, you can define a rule that indicates paysheets over $5,000 must be routed to the participant’s manager for approval.
This also means that you can now include the participant’s supervisor hierarchy in the approval process. When using the participant’s supervisor hierarchy, you set traversal levels. For example, to traverse two levels means that the participant’s manager and their manager’s manager are required approvers.
You can define an approval group. Approval groups are typically used for your subject matter experts. For example, you can define an approval group of auditors that specialize in reviewing incentive compensation items. You can then define a rule that indicates all paysheets over a maximum amount be routed to the group of auditors for review.
For steps defined for parallel approval, you can enable voting. For example, you define a step where at least 50% of the approvers must approve. The workflow tracks the responses from the approvers in order to determine the vote and outcome.
Notes
Slide 7 - Configurable Payment Approval Workflow
Slide notes
You now have more options to configure your paysheet approval policy in the Incentive Compensation application. This allows the software to manage your approval processing for you. Each submitted paysheet is evaluated against your rules to determine the approval path required for that specific paysheet. Whether the paysheet qualifies for automatic approval or needs to be routed up several approver hierarchies, the list of approvers is derived and the notifications are routed based on your policy. Altogether, this allows you to have strong paysheet governance without a lot a manual work.
Notes
Slide 8 - Approval Routing and Notifications using the Configurable Payment Approval Workflow Demonstration
Slide notes
Now, let’s go to a demonstration. In this demonstration, we will go through a paysheet approval flow but I do need to give you some background about the setup and my paysheet participant.
Notes
Slide 87 - Summary of Enhancement Capabilities
Slide notes
Here is the summary of the features I have talked about today.
Approval processing can occur in steps. In this context, the steps are referred to as service-oriented architecture participants. A step can be either parallel or sequential in relation to the other steps. The step contains your approval policy for that step. In other words, it contains the notification routing type, your voting requirements, and the conditional rules.
The conditional rules provide the ability to use the attributes of the paysheet and participant to define the conditions and related action. For example, you can define a rule that indicates paysheets over 5000 USD must be approved by the participant’s manager. The rule action contains the details for building the list of approvers when the conditions are true. This includes selecting the participant’s supervisor hierarchy or approval group.
When using the participant’s supervisor hierarchy, you set traversal levels. For example, to traverse two levels means that the participant’s manager and their manager’s manager would be required approvers.
You can define approval groups and assign the group to a rule action. Approval groups are typically used for your subject matter experts.
Notes
Slide 88 - Additional Information
Slide notes
The list builder for the analyst approval hierarchy is a function of the Incentive Compensation product and not native to the BPM worklist. This means that the approval rule conditions and actions do not apply to that hierarchy. The configuration options that are available include the placement of the Participant One SOA participant in relationship to the other SOA participants and the option to disable it completely.
The approval flow is made up of steps. For example, your approval flow can include one step to get approval from the participant’s supervisory hierarchy and another step to get approval from a group of subject matter experts. You can have any number of unconditional steps. However, if your step includes conditions, then the step is associated with a set of rules. Let’s say your step to get approval from you subject matter experts has a condition that the paysheet must be over 100,000 and the participant cost center must be B045. That means you have used 1 of the 4 rules sets. If you always require the participant supervisory hierarchy, then this step will not need conditions and you will still have 3 rule sets left to use.
I will explain the approval steps and rule sets more in the next section.
Notes
Slide 89 - Implementation Advice
Slide notes
In this implementation advice section, I will go through what you need to consider before enabling these features in your business, and what you need to know to set them up.
Notes
Slide 90 - Feature Impact Guidelines
Slide notes
This table depicts key upgrade information for the new features covered in this training. These features provide additional options above and beyond the analyst-to-compensation manager paysheet approval process that existed in previous releases. If you determine that your paysheet approval policies can benefit from the new features, you can enable them using them as needed using the Setup and Maintenance work area. I’ll go into the setup specifics later in this section.
The setup for these features, as well as the approval notifications, can be accessed using the shipped job roles. The exact job roles are detailed later in this section.
Notes
Slide 91 - Setup Summary
Slide notes
Configuring your paysheet approval policies is performed via Functional Setup Manager. The setup tasks are not automatically displayed. You must first enable the Approval Routing Authorization feature for the Incentive Compensation offering.
Once enabled, the Applications Extension functional area includes the two tasks for this feature.
You use the Manage Task Configurations for Incentive Compensation task to define your paysheet approval policy. You use the Manage Approval Groups for Incentive Compensation task to define the approval groups. If you only require the participant supervisor approval, then you do not need to define approval groups.
Notes
Slide 92 - Manage Task Configurations Basics - Tasks
Slide notes
Now, I’ll cover just a few more basics. The task configuration names are technical names. You will select the NotificationforPaysheet task. When configuring the task, you first need to select the Edit icon. You can also save your changes, but what I want to point out is that you finally need to commit the changes so they can be used by the approval process.
Notes
Slide 93 - Manage Task Configuration Basics – Stage and SOA Participants
Slide notes
The Assignees tab displays the SOA participants in the paysheet approval stage. The first SOA participant, Participant One, represents the analyst-to-compensation manager hierarchy defined using the Participant Assignment work area. The second SOA participant, Participant Two, sends the FYI notification to the requesting analyst. All other SOA participants are for your approval policies.
Notes
Slide 94 - Parallel and Sequential Approval Setup Detail
Slide notes
Now that I have covered the basics, let’s take a closer look at the setup for the features that I spoke about earlier in this training. When your approval policy includes multiple steps, you will use the Assignees graphical view to define your SOA participants. You can add a new SOA participant by selecting an existing participant. The new participant will be added in parallel or sequentially to the participant that you selected. You can also change the type of an existing SOA participant.
The routing type can be set to Serial notification delivery or Parallel notification delivery. If you choose parallel notification delivery, then all the approvers are sent the notification at the same time, even if they are derived from a hierarchy. If you choose serial delivery, then the next approver is only notified after the previous approver approves the notification. You can choose the single type if the approvers are a single type of user. For example, you can select a specific user or a set of users with a specific security job role. The FYI notification delivery indicates the notification receiver has no impact to the approval outcome.
Notes
Slide 95 - Parallel and Sequential Approval Setup Detail
Slide notes
To configure the SOA participant, you select the SOA participant in the graphical view. The region at the bottom of the page displays the Basic, Voting, and Advanced menus. The Basic menu indicates how the assignees (or approvers) will be determined. If you do not have any conditions, you can select the approver source here. For example, if you always want an approval group to approve the paysheet, then you will change the "Assignees based on" option from rule-based to an approval group. If you do have conditions, then select the Rule-based option.
You can define your voting requirements using the voting menu. This menu displays when the SOA participant is a parallel routing type.
The advanced menu has many options but an important one is that this is where you will uncheck the Ignore Participant checkbox to enable the SOA Participant.
When your assignees are based on rules, then it’s time to define the rules.
Notes
Slide 96 - Rule-Based Conditions and Actions Setup Detail
Slide notes
For the rule-based SOA participants provided by Oracle, the rule is a placeholder rule and should be replaced with your own rule. If you created a new SOA participant, select the create rule option to navigate to the rules setup page.
The rule conditions are the IF statements. The IF statements are tests that determine when an approval rule takes effect. You can specify multiple IF statements. If you join multiple statements with "and" operators, then all statements must be true before the approval rule takes effect. If you join multiple statements with "or" operators, then only one of the statements must be true before the approval rule takes effect.
The paysheet attributes used in the IF statement are included in the NotificationForPaysheetPayloadType , paysheetDetailInfo folder. You expand the folder to select the desired attribute.
Amount-based rules need to include converting the string values to amounts.
Notes
Slide 97 - Rule-Based Conditions and Actions Setup Detail
Slide notes
The rule actions are also known as THEN Statements. The THEN statements determine how individual approvers are identified and any actions that approvers are expected to take.
To associate the participant supervisor hierarchy to a rule, you choose the action “Add Approver, Supervisory”.
Enter the number of levels that you want to traverse. For example, I have entered the value 2 in the example displayed here.
The starting participant is the paysheet’s incentive compensation participant.
The top participant is the user name of the person at the top of the paysheet participant supervisor hierarchy. Approval routing stops when either the number of levels or the topmost approver is reached, whichever is sooner.
In the example displayed here, the rule is stating that when the paysheet is over 1000 and the incentive compensation participant’s cost center is B405, then route the approval notification to the participant’s manager and the manager’s manager.
The starting participant and the top participant values are a bit tricky. Let’s take a closer look at how to define those to values.
Notes
Slide 98 - Participant Supervisor Hierarchy Approval Setup Detail
Slide notes
When defining the starting participant, you must use the paysheet’s participant user name as the starting reference if you want their supervisory hierarchy to approve. In the Reference User field, you will specify the attribute that is passed into the workflow which represents the participant user name. This is the technical payload attribute name, (NotificationForPaysheetPayloadType.paysheetDetailInfo.participantUserName). I’ll show you a tip on this part in the setup demonstration later in this section. Since we intend to go up the hierarchy, select the Get Manager option to indicate the hierarchy will get the manager of the reference user.
To define the top participant, you need the user name of the person at the top of the paysheet participant supervisor hierarchy. In the Reference User field, specify the top manager’s user name in double quotes. Select the Get User option to indicate person’s user name will be used. It is important to note that the approval processing will fail if the top participant is not in the supervisor hierarchy of the starting participant.