4Data Sharing Mechanisms and Object Visibility

This chapter contains the following:

Data Sharing Mechanisms

Review the information in this chapter to learn how users gain visibility to various objects used in the sales and service applications.

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:

  • Team

  • Partner team

  • Territory

  • Resource hierarchy

  • Business unit

For example, for the Opportunity object, data can be shared through team membership, through the resource hierarchy, or through territory membership.

The security reference implementation provided by Oracle determines who can access 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're on the opportunity sales team.

  • The opportunity owner or sales team member is your direct or indirect report in the resource hierarchy.

  • You're the owner or are a member of the territory assigned to the opportunity.

  • You're the owner or member of an ancestor territory of the territory assigned to the opportunity.

  • You're assigned to a territory for the account associated with the opportunity.

  • You're assigned to a territory that's an ancestor of the territory for the account associated with the opportunity.

Salespeople can see all opportunities related to their accounts but 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 aren't added to the opportunity sales team.

  • Owners and members of territories assigned to the opportunity product 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 aren't added to the opportunity sales team but they always get full access.

The following diagram 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) can't access the opportunity.

  • Sales managers can access the opportunity because a salesperson in their management chain has access.

This diagram shows who in a sales hierarchy can access an opportunity.

How data security policies determine access to
opportunities.
  • Agent A can access the opportunity because she created it. When you create an opportunity, you're the initial owner.

  • Agent B can access the opportunity because he's on the sales team.

  • Agent C can access the opportunity because he's 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 can't.

  • Sales administrators can access the opportunity.

Note: Access using accounts isn't shown in this diagram.

Special Access

Some access isn't affected by the management hierarchy and membership in sales teams or territories. This special access includes:

  • Administrators: Users assigned the Sales Administrator job role get full access to opportunities and other objects. This access is based on their privileges, regardless of where the administrators are in the management hierarchy. Administrators don't 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're moved to another opportunity.

How Users Gain Access to Leads

The security reference implementation provided by Oracle 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're the lead owner.

  • The lead owner is your direct or indirect report in the resource hierarchy.

  • You're 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're the owner of the territory the lead is assigned to or of ancestor territories.

  • You're a member of the sales territories assigned to the lead.

Multiple Business Units and Data Access for Sales Objects

The way that you implement multiple business unit functionality in your enterprise can affect your users access to object transactional data.

A business unit (BU) is a unit of an enterprise that performs one or more business functions, such as sales or marketing. A business unit primarily provides a means of separating or sharing setup data and controlling transactional data access within an enterprise. By default, an enterprise structure is created as a single business unit to which all users belong but you can create additional business units if you need to.

Users are associated with a business unit through their resource organization membership. Resource organizations are mapped to one or more business units. When you create a sales user and assign the user to a resource organization, the user gains access to each business unit that's mapped to the resource organization. For example, users can access relevant transactional data associated with their primary business unit, but might also have access to relevant transactional data in other business units through their resource organization.

Note: When you create a user in the sales application, you specify a business unit for the user. But only the BUs associated with the user's resource organization are relevant in determining the business units a user can access. If a business unit isn't specified for a resource organization, the default business unit is used.

Within the sales application, these business objects support the use of multiple business units:

  • Contracts

  • Leads

  • Opportunities

  • Resource Organizations

  • Territories

When you create an object that supports multiple business units, such as an opportunity, you specify the business unit to associate with the object.

Object Access in a Single Business Unit Environment (Default)

In this type of implementation, all users can access master data, such as product or account information, by default. Users also have access to transactional data for objects such as opportunities, contracts or leads:

  • Sales administrators can access transactional data for all objects.

  • Sales users gain access to transactional data for an object through one of these methods:

    • They have been granted full access to the object

    • Through territory or team membership

    • Through the resource management hierarchy

    Full access to an object is provided through data security policies that include a condition of All Values. This table provides information about other methods of object access.

    Type of Object Access Description

    Territory membership

    You gain access to an object if:

    • You're the owner or member of the territory that's assigned to the object.

    • You're the owner or member of an ancestor territory of the territory assigned to the object.

    • Your direct or indirect report in the resource hierarchy is the owner or a member of the territory assigned to the object.

    • Your direct or indirect report in the resource hierarchy is the owner or member of an ancestor territory of the territory assigned to the object.

    Team membership

    You gain access to an object if:

    • You're a member of the sales team assigned to the object.

    • Your direct or indirect report in the resource hierarchy is a member of the sales team assigned to the object .

    • You're a member of the partner team assigned to the object.

Object Access in a Multiple Business Unit Environment

In a multiple business unit environment, access to objects and data is influenced by the business unit the user belongs to. In this type of implementation, access to transactional data for objects, such as opportunities or leads, is determined in these ways:

  • Sales administrators can access transactional data for all objects that are associated with the business unit or units to which the administrators are assigned.

  • Sales users access to transactional data for an object is the same in multiple business unit environments and single business unit environments. So sales users can access object data across business unit boundaries provided that they have valid access to the object by means of territory or team membership, through the resource hierarchy, or by being granted full access to the object.

    But business unit assignment can indirectly affect a user's access to object transactional data. In a multiple business unit environment, business units are available as territory dimensions and can be included as part of the territory coverage definition for the assignment of transactions. A sales user gains access to object data through territory membership. If business unit is specified as a territory dimension, then the user's access to data is limited to objects which, when they were created, were assigned to the same business unit that's assigned to the user's territory team.

For additional information about using multiple business units, see the Oracle CX Sales Implementing Sales guide.

Data Sharing and Visibility in Incentive Compensation

The conditions specified in data security policies control visibility to record-level data associated with a schema object, such as an incentive compensation plan and a paysheet.

Conditions can use these components as mechanisms for sharing data, provided that the sharing mechanism is applicable for the object:

  • Business unit

  • Analyst assignment

  • Person security profile

Business Unit

For incentive compensation administrators, the basis for data sharing is the business unit they have access to. Incentive compensation administrators are users assigned to these job roles:

  • Incentive Compensation Manager

  • Incentive Compensation Plan Administrator

  • Incentive Compensation Analyst

Analyst Assignment

You have the option to further limit data access for users assigned to the Incentive Compensation Analyst role. You can limit the analyst access to the business unit or to participants who are directly assigned to the analyst. In the Setup and Maintenance work area, use the following:

  • Offering: Sales

  • Functional Area: Incentives

  • Task: Manage Parameters

For example, analyst Amy is directly assigned to the participants Jack and Ravi. Analyst Ryan is assigned to the participants Juan and Mary. When the Manage Parameter setting indicates analyst security is by participant, Amy can't manage participant data for Juan and Mary because she isn't the assigned analyst. This functionality applies to data within the Participant Snapshot and Payments work areas.

You can assign analysts to participants when the participants are imported, using the Participant Assignments, Manage Analyst Assignments task, and using the Participant Snapshot, Participant Details task.

Person Security Profile

The predefined person security profile types can be assigned to abstract roles, such as the employee, line manager, and contingent worker roles. You can also assign the security profile to the Incentive Compensation Participant and Incentive Compensation Participant Manager abstract roles. The person security profile, view own record option provides visibility to the participant's own data. The person security profile, view manager hierarchy option provides the participant manager with visibility to participant data for the subordinates in their management hierarchy.

Data Sharing and Visibility in Service

A service application user's access to service requests is determined by the set of data security policies assigned to all the roles the user is provisioned with. The predefined roles in the service application don't provide for service request visibility based on business unit or queue. But you can configure either queue or BU-based visibility to service requests for specific roles. Users assigned these roles can see only the service requests assigned to the business unit or queue where they're a resource member.

For more information about restricting service request visibility by business unit or by queue, see the Implementing B2B Service guide.