This chapter contains the following:
When you receive your Oracle Sales Cloud implementation, access to its functionality and data is secured using role-based access control (RBAC). This guide describes the RBAC controls provided by Oracle Sales Cloud, and describes the tasks you must perform to implement these controls so that users have appropriate access to Oracle Sales Cloud data and functions.
Some of the tasks described in this guide are performed only or mainly during implementation of Oracle Sales Cloud. Most, however, can be performed at any time and as new requirements emerge. During implementation, you can perform security-related tests:
From an implementation project
By opening the Setup and Maintenance work area (Navigator - Tools - Setup and Maintenance) and searching for the task on the All Tasks tab
Once the implementation is completed, you can perform most security-related tasks from the Setup and Maintenance work area. Any exceptions are identified in relevant topics.
Oracle Sales Cloud implements role-based access control (RBAC) to prevent unauthorized access to application resources. Users gain access to application functions and data when they are assigned job and abstract roles, which correspond to their roles in your organization. Users can have any number of different roles, and this combination of roles determines the resources that the user can access. The job role providing the greatest level of access takes precedence.
Role-based security in Oracle Cloud applications controls who can do what on which set of data.
In role-based access:
This is a role assigned to a user, for example, the Sales Manager role.
This is a function that users with the role can perform, for example, approve sales forecasts.
This is the set of data that users with the role can access when performing the function; for example, approve forecasts for salespersons who work for them.
Oracle Sales Cloud provides the following types of roles:
You assign job and abstract roles directly to users. Duty roles are associated with job and abstract roles; they are not assigned directly to users. You can assign job and abstract roles to a user manually, when you create the user, or automatically, by creating role provisioning rules.
Many job and abstract roles are predefined in Oracle Sales Cloud. You can assign each sales application user with one or more of the following job roles.
Channel Account Manager
Channel Operations Manager
Channel Partner Administrator
Channel Sales Director
Channel Sales Manager
Customer Data Steward
Data Steward Manager
Master Data Management Application Administrator
Partner Sales Manager
Sales Vice President
These predefined roles are part of the Oracle Sales Cloud security reference implementation. The security reference implementation is a predefined set of security definitions that you can use as supplied. Also included in the security reference implementation are roles that are common to all Oracle Cloud applications, such as:
Application Implementation Consultant
IT Security Manager
You must also assign the following abstract roles to all Oracle Sales Cloud users who are employees so they can carry out their work:
To create users with implementation privileges, you must provision special job roles. See the topic Creating Setup Users for Oracle Sales Cloud: Worked Example for more information.
This topic describes the roles provided by Oracle Sales Cloud and explains how they work together to provide users with permissions to application resources. Oracle Sales Cloud provides the following types of roles:
The permissions each role provides are described in security reference manuals available on http://docs.oracle.com.
The following figure shows each of the role types and how they relate to one another.
Abstract roles and job roles are also called external roles because they are created in the LDAP directory and are not specific to an application pillar. Duty roles are also known as application roles because these roles are created in the Sales Cloud database and are specific to each Oracle application pillar.
Job roles represent the job functions in your organization. Sales Representative and Sales Manager are examples of predefined job roles. You can also create custom job roles.
Job roles provide users with the permissions they need to perform activities specific to their jobs. For example, providing a user with the Sales Manager job role permits the user to manage salespersons within the organization, follow up on leads, generate revenue within a territory, build a pipeline, manage territory forecasts, and assist salespeople in closing deals.
You assign job roles directly to users.
Abstract roles represent a worker's role in the enterprise independently of the job they do. The following are examples of abstract roles used in Oracle Sales:
You can also create custom abstract roles.
Abstract roles permit users to perform functions that span across the different jobs in the enterprise. For example, users who are employees must be provisioned with the Employee abstract role, so they can update their employee profiles and pictures. For Oracle Sales Cloud, you must also provision users with the Resource abstract role, so they can work on leads, opportunities, and other sales tasks.
You assign abstract roles directly to users.
Job and abstract roles permit users to carry out actions by virtue of the duty roles they include. Duty roles represent the individual duties that users perform as part of their job. Duty roles are composed of security policies which grant access to work areas, dashboards, task flows, application pages, reports, batch programs, and so on.
Job roles and abstract roles inherit duty roles. For example, the Sales Manager job role includes the Sales Lead Follow Up Duty and the Quota Management Duty. The Sales Lead Follow Up Duty makes it possible for the managers to work with leads. The Quota Management Duty enables the management of sales territory quotas.
Duty roles can also inherit other duty roles. They're part of the security reference implementation, and are the building blocks of custom job and abstract roles. You can also create custom duty roles.
You don't assign duty roles directly to users.
Duty roles are associated with two types of security policies: functional security policies and data security policies. Security policies define the privileges provided by the duty role to access specific application resources. This topic describes both types of security policy.
Functional policies permit an individual who is assigned a duty role to access different user interface elements, Web services, tasks flows, and other functions. For example, a sales manager who has the Delete Opportunity functional policy will be able to view and click the Delete button. Removing that policy removes the button from view.
A functional policy is made up of the following:
A duty role name. The name of the duty where the policy applies, for example, Opportunity Sales Manager Duty.
A functional privilege that specifies the application features that are being secured, for example, View Opportunity.
In the security reference manuals, functional privileges are listed in the Privileges section.
Data security policies specify the roles that can perform a specified action on an object, and the conditions under which the action can be carried out. A data security policy is composed of:
A duty role name. The name of the duty where the policy applies. For example, Opportunity Sales Manager Duty.
A data privilege that defines the action being performed. For example, View Opportunity.
The condition that must be met for access to be granted. For example, sales managers can view opportunities provided they are in the management chain or are members of the sales team on the opportunity.
If the View All condition is specified, the duty role provides access to all data of the relevant type.
Each data security policy represents an underlying SQL query. The application evaluates the query at run time, and permits access to data that meets the condition. Data privileges are listed in the Data Security Policies section of the security reference manuals.
The conditions specified in data security policies control visibility to record-level data associated with a schema object, such as an opportunity. Conditions can use the following components as mechanisms for sharing data, provided that the sharing mechanism is applicable for the object:
For example, for the Opportunity object, data can be shared through team membership, through the resource hierarchy, or through territory membership.
This topic describes how users inherit roles and privileges. In Oracle Sales Cloud, each role is a hierarchy of other roles:
Job and abstract roles inherit duty roles.
Duty roles can inherit other duty roles.
When you assign job and abstract roles to users, they inherit the data and functional security privileges associated with those roles.
This example shows how roles and privileges are inherited for a user assigned the Sales Manager job role.
The following figure shows a few representative duty roles. In reality, job and abstract roles inherit many duty roles, which themselves might inherit many duty roles.
In this example, the provisioning rule automatically provisions an employee sales manager with the roles needed to do the job: the Sales Manager job role, and the Employee and Resource abstract roles. Roles are inherited as follows:
The Sales Manager job role inherits the Quota Viewing Duty and the Sales Manager Duty.
Duty roles inherit other duty roles. For example, the Sales Manager Duty inherits many other duty roles including the Marketing Lead Analysis Duty and the Opportunity Sales Manager Duty.
The duty roles are associated with functional security policies and data security policies. For example, the inherited Opportunity Sales Manager Duty has:
Functional security policies that specify which application pages and functions sales managers can access for deleting, assigning, closing, creating, and viewing an opportunity. The View Opportunity policy, for example, permits sales managers to view all UIs, Web services, and task flows related to opportunities.
Data security policies that specify the actions opportunity sales managers can perform on what opportunities and under what conditions.
For example, opportunity sales managers can view all data related to opportunities if they are an opportunity sales team member with view, edit, or full access.
This topic explains how the security reference implementation provided by Oracle determines who can access what opportunity information in your sales organization.
Whether or not you can access a particular opportunity depends on your membership in the resource and territory hierarchies. You can access an opportunity if:
You create the opportunity.
You are on the opportunity sales team.
The opportunity owner or sales team member is your direct or indirect report in the resource hierarchy.
You are the owner or are a member of the territory assigned to the opportunity.
You are the owner or member of an ancestor territory of the territory assigned to the opportunity.
You are assigned to a territory for the account associated with the opportunity.
You are assigned to a territory that is an ancestor of the territory for the account associated with the opportunity.
Salespeople can see all opportunities related to their accounts. However, access differs between territory members and opportunity members:
An opportunity owner gets full access to the opportunity, which includes the ability to edit as well as add and remove team members.
Owners and members of territories or of ancestor territories assigned to the account of the opportunity get read-only access to the opportunity and are not added to the opportunity sales team.
Owners and members of territories assigned to the opportunity revenue lines are added as a distinct list of territories to the opportunity sales team. Owners and members of these territories get full access to the opportunity. Depending on a profile option, either only the owner or all the members of the territory are added as resources to the opportunity sales team. Regardless of the access level for these members as a resource on the opportunity team, they always have full access.
Owners and members of ancestor territories of the territory assigned to the opportunity do not get added to the opportunity sales team but they always get full access.
The following figure illustrates some of the different ways you can gain access to an opportunity:
Named agents in the diagram (A, B, and C) can access the opportunity.
Unnamed agents (highlighted in yellow) cannot access the opportunity.
Sales managers can access the opportunity because a salesperson in their management chain has access.
This figure shows who in a sales hierarchy can access an opportunity.
Agent A can access the opportunity because she created it. When you create an opportunity, you are the initial owner.
Agent B can access the opportunity because he is on the sales team.
Agent C can access the opportunity because he is the owner of the NW territory.
Sales managers who are higher up in the management chain can also see the opportunity because access is provided through the resource hierarchy. Agent C's manager can access the opportunity information, but agent C's colleagues cannot.
Access using accounts is not shown in this figure.
Some access is not affected by the management hierarchy and membership in sales teams or territories. This special access includes:
Administrators: Administrators get access to opportunities and other objects. This access is based on their privileges, regardless of where the administrators are in the management hierarchy. Administrators do not have to be on the sales team or members of territories.
Deal Protection: Salespeople assigned to an opportunity retain the sales credit on an opportunity even if they are moved to another opportunity.
This topic explains how the security reference implementation provided by Oracle Sales Cloud determines who can access lead information in your sales organization.
Qualified leads are assigned to a sales team based on sales territories. Unqualified leads are assigned to individual lead qualifiers either manually or based on rules defined in the assignment manager engine. Whether or not you can access a particular lead depends on your membership in the resource and territory hierarchies.
You can access a lead if:
You are the lead owner.
The lead owner is your direct or indirect report in the resource hierarchy.
You are a member of the lead sales team.
Resources in the management hierarchy of a newly added lead sales team member have the same level of access to the sales leads as the team member.
You are the owner of the territory the lead is assigned to or of ancestor territories.
You are a member of the sales territories assigned to the lead.
Only the lead owner, or resources in the management chain of the lead owner, can change the lead owner.
If the predefined security reference implementation doesn't fully represent your enterprise, then you can make changes.
For example, the predefined Sales Representative job role includes sales forecasting duties. If some business groups in your organization have the sales managers do forecasting, not the sales representatives, then you can create a custom Sales Representative role without those duties. Alternatively, if a predefined job role is too narrowly defined, then you can create a job role with a greater range of duties than its predefined equivalent.
During implementation, you evaluate the predefined roles and decide whether changes are needed.
If you change the security reference implementation, then it is recommended that you create custom roles rather than modify predefined roles. For additional information, see the chapter Customizing Security later in the guide.
If jobs exist in your enterprise that aren't represented in the security reference implementation, then you create custom job roles.
If the duties for a predefined job role don't match the corresponding job in your enterprise, then create a custom role and add the required duties to the new role.
If the duties for a job aren't defined in the security reference implementation, then you create custom duty roles.
The Security Reference for Oracle Sales Cloud includes descriptions of all predefined security data in the Oracle Sales security reference implementation. The Security Reference for Oracle Applications Cloud includes descriptions of all predefined security data that's common to Oracle Fusion Applications.
You can access all information in these manuals from various Oracle Sales user interface pages. For example, you can review individual job roles using the Manage Job Roles task. However, using the manuals you can compare roles and plan any changes.
You can access the security reference manuals on cloud.oracle.com. Select Resources - More Resources - for Business Users - Cloud Documentation - All Books.
The Security Reference for Oracle Sales Cloud contains a section for each predefined Sales job and abstract role. For each role, you can review its:
Function security privileges
This information can help you to identify which users need each role and whether to make any changes before provisioning roles.