18Configure and Troubleshoot Data Security

This chapter contains the following:

Overview of Data Security Configuration

Learn some of the ways you can configure and troubleshoot data security for sales and service users by reviewing the information in this chapter.

The database resources of an enterprise are secured using data security policies, which specify the roles that can perform a specified action on an object, and the conditions under which the action can be carried out. The conditions specified in data security policies control visibility to record-level sales and service data associated with a schema object, such as an opportunity. Conditions can use a number of components, such as team or territory access, as mechanisms for sharing data.

For example, a user assigned a role that grants access to opportunities based on team and territory can access the opportunity as part of territory visibility even though the user isn't on the opportunity team. The scope of visibility varies by object and multiple visibility levels are supported by an object for a role.

You can configure data security using the Sales and Service Access Management work area or the Security Console. In general, use the Sales and Service Access Management work area to review, configure, and troubleshoot data security. But there are a number of data security configuration tasks you can only do in the Security Console, for example, creating database resources, and defining custom conditions for a resource. Both types of tasks are described later in this chapter.

Note: Data security changes made in either work area are immediately available in both work areas.

Sales and Service Access Management Work Area

As an IT Security administrator, you must be able to easily view the data a predefined role can access and to easily configure access to data for a user group using custom roles. Administrators must also be able to troubleshoot access issues for users. You can perform all of these tasks using the Sales and Service Access Management work area, which provides simple interfaces where you can do these tasks:

  • Review and configure the data access provided by roles:

    • View data access by object for a predefined or custom role

    • Configure data security to add or remove a custom role's access to object data

    • End-date policies and configure advanced data permissions

    • Extend access to additional objects for custom roles

  • Troubleshoot access issues for users:

    • Review a user's access to object data

    • Identify the cause of any issues the user is experiencing in accessing specific records

  • Create and manage access groups to provide sales resources with additional visibility to sales object data.

    See the Access Groups chapter for information about using access groups.

Note: You can view policies for custom objects in the Sales and Service Access Management work area but you can only configure security for custom objects in Application Composer.

Access to the Sales and Service Access Management Work Area

The Manage Sales and Service Access privilege (ZCA_MANAGE_SALES_AND_SERVICE_ACCESS_PRIV) grants access to the Sales and Service Access Management work area. This privilege is assigned by default to the IT Security Manager and the Customer Relationship Management Application Administrator job roles. If necessary, you can provide access to the work area by granting the Manage Sales and Service Access functional privilege to a custom job role.

Review and Configure Data Access for Roles

You can review the visibility provided by job roles to object data on the main Sales and Service Access Management page. This page displays a read-only view of all the data security policies provided by a predefined or custom role for an object. You can use this information to query existing policies so you can answer questions such as these:

  • What's the most appropriate role to apply to a set of users?

  • What's the most suitable role to copy when you need to extend the access provided by existing predefined roles?

  • Why can't users access specific data?

By default, active policies are displayed for a role and object but you can also review inactive policies.

Here's how to review data access for a selected role and object:

  1. Sign in to the application as a user who has either the IT Security Manager or Customer Relationship Management Application Administrator job role.

  2. Select Navigator > Tools > Sales and Service Access Management.

    The Sales and Service Access Management page is displayed. It contains two areas: the Access Policies table, which lists each data policy for the selected object and role combination, and the Advanced Permissions table, which shows more detail about any advanced permissions available for a policy selected in the Access Policies table.

    Tip: You can also access the Sales and Service Access Management page from the Setup and Maintenance work area by selecting the Manage Sales and Service Access task in the Users and Security functional area of the Sales offering.
  3. Select a role in the Role field.

    You can select either a custom or a predefined role. To search for a role:

    1. In the Role field drop-down list, click Search, then enter the role name in the Role field of the Role dialog box.

    2. Click Search again. From the search results, select the role you want, then click OK. Note that in the search results predefined roles are identified by a Yes in the Predefined role column.

  4. Select an object in the Object field.

    The Object field lists all the sales and service objects the role can access.

    Note: Select the Trading Community Party object to view access policies for both accounts and contacts.
  5. Click Find Policies.

    The Access Policies table now lists all the active data security policies relating to the object you selected, such as Trading Community Party, for the selected role. You can view more or less information for the policies in the table by selecting the Columns option in the View menu.

    This information is shown for each active policy in the Access Policies table.

    Field Value

    Condition

    Lists the condition that must exist for this data policy to take effect. For example, if you selected the Sales Representative role and the Opportunity object, the condition might state that this policy applies when the user assigned the Sales Representative role is an opportunity sales team member with edit or full access.

    Permissions

    Shows the access provided by the policy. For example, if the Read, Update, and Delete check boxes are selected, then this policy provides a user with read, update, and delete access to the object when the conditions specified in the policy are met, for example, when the user is an opportunity sales team member with edit or full access.

    The Advanced field indicates the number of advanced permissions defined for the policy. Not all objects or policies have advanced permissions.

    Start Date

    Indicates the date when the policy was activated.

    End Date

    Indicates the date when the policy is deactivated.

    Role Code

    Role Name

    Lists the role name and code of the role the policy is associated with. In most cases, the policy relates to the top-level job role you selected in the Role column, but in some cases, the policy is provided by an inherited duty role. A policy can even be provided by both the top-level role and by an inherited role.

    Custom Condition

    Indicates whether the condition specified in the policy is a predefined condition provided by Oracle or is a custom condition that you created previously.

  6. You can limit the policies that are shown for the role and object by clicking the Query By Example filter icon and entering filter text. You can filter by condition, role name, or role code.

    For example, currently the standard Sales Representative job role provides data visibility to all accounts and contacts. To view the conditions that are providing this full access, use these steps:

    1. Select Sales Representative in the Role field, Trading Community Party in the Object field, and click Find Policies.

    2. Click the Query By Example filter icon, and enter the text All records in the query field above the Condition column.

    The page is refreshed and displays two policies that provide all record access. Notice that one policy is provided by the Sales Representative role and the other by an inherited role, Contract View Access Across All Contracts. If you wanted to create a version of the Sales Representative role that had more restricted access to accounts and contacts, you would have to create custom copies of both roles and remove the All records policies from each.

    To remove the filter, click the Clear All icon in the query row.

  7. To view the advanced permissions defined for a selected policy in the Access Policies table, scroll to the Advanced Permissions table.

    Advanced permissions provide a finer-grained method of controlling what the user can do. For example, a policy might provide update access to an opportunity but the advanced permission for the policy might allow you to restrict that update access to specific attributes.

    For each advanced permission, the Advanced Permissions table shows the type of access provided, for example, Read access, and the action it relates to, for example, View Opportunity.

  8. If you want to view the inactive policies for a selected role and object on the Sales and Service Access Management page, then select the Inactive policies check box.

    Inactive policies are policies that you set an end-date for and the end-date has passed. The number of inactive policies for the role and object is shown in parentheses beside the Inactive policies check box. For example, the number 1 indicates that there is only one inactive policy for the role-object combination.

Edit the Data Access Permissions for a Custom Role and an Object

You can update existing and future-dated policies for a custom role and object, and grant access to new subsets of object data for the role, using the Active Policies edit page of the Sales and Service Access Management work area. For example, you can:

  • Add or remove all access to individual policies

  • Configure read, update, and delete permissions for a specific policy

  • End-date policies to inactivate them

  • Configure advanced permissions for policies

Follow these steps to edit the permissions to object data for a custom role.

  1. Sign in to the application as a user who has either the IT Security Manager or Customer Relationship Management Application Administrator job role.

  2. Select Navigator > Tools > Sales and Service Access Management.

    The Sales and Service Access Management page is displayed.

  3. Search for or select a role in the Role field.

    You can't edit policies on predefined roles, so search for and select a custom role. For example, if you copied the predefined Sales Representative role to create a custom version of the role, you could select it.

  4. Select an object in the Object field, for example, select the Sales Lead object.

    Note: Select the Trading Community Party object to view access policies for both accounts and contacts.
  5. Click Find Policies.

  6. Click the Edit icon and the Active Policies edit page for the selected role and object is displayed.

    The Access Policies table shows all available policies for the selected role and object by default but you can use the Show Conditions filter to display only policies that are granted or only policies that are not granted.

  7. Configure the access provided to the selected object for the selected custom role by selecting or deselecting the Read, Update, or Delete check boxes for a policy.

    For example, if you are editing policies for a custom Sales Representative role and the Sales Lead object, you can perform data configuration tasks such as:

    • Restrict the ability to delete leads to lead owners by locating any policies that provide lead access to team members and deselecting the Delete check box for these policies.

    • Allow sales representatives to view retired leads by locating the policy that grants this access, then clicking the Read check box.

  8. You can remove all access granted by a policy. For example, if your company doesn't use territory access, you can remove territory access to lead data using one of the following methods:

    • Review the Criteria column to locate the policies that grant territory access, then deselect the Read, Update and Delete check boxes for each of these policies.

    • End-date the policies so that they're no longer active by selecting a date that has passed in the End Date field, for example, select yesterday's date.

    Note: To reactivate a policy that's deactivated, reassign the appropriate read, update, and delete permissions to the relevant criteria and specify a start date for the policy.
  9. If a policy has an advanced permission associated with it, then you can edit the advanced permission to specify more granular levels of access to the object.

    For example, a policy might provide full access to lead data for a resource in the territory assigned to the sales lead. You can restrict this access by selecting the policy, then scrolling to the Advanced Permissions table for the policy. You can remove update access to the lead data but retain read access by deselecting the Update check boxes.

    Note: You can update the advanced permissions for a policy only if the related permission in the parent row in the Access Policies table is checked. For example, if the read permission in the parent row of a policy isn't selected, none of the read permission options in the Advanced Permissions table can be edited.
  10. Click Save and Close.

    Your changes are saved and the Sales and Service Access Management page is displayed where you can review your changes. If you have end-dated a policy, note that the number in parentheses beside the Inactive policies check box is incremented.

Considerations When Editing Inherited Roles

This topic describes some of the things to keep in mind when you edit inherited roles on the Active Policies page of the Sales and Service Access Management work area.

To add or remove a job role's access to object data, you have to know which policies provide the access. A job role can be assigned a policy in these ways:

  • It can be assigned a policy directly

  • It can inherit a policy indirectly from an inherited role

  • It can receive the same policy from more than one role

The information on the Active Policies page lets you view all policies a job role is assigned, from all sources, for the selected object. For each policy in the Access Policies table, the Role Name field lists the role that the policy is associated with; this is either the top-level job role you selected on the Sales and Service Management page, or a duty role that the top-level role inherits.

You can't edit policies that are inherited from predefined duty roles because predefined roles can't be edited. But you can edit policies that are inherited from custom duty roles. If you edit a policy provided by an inherited custom duty role, keep in mind that if the custom duty role is also inherited, directly or indirectly, by other roles then the change you make to the policy also impacts these other roles.

To make sure that you don't inadvertently change the access provided by roles other than the top-level job role you're editing, a warning message alerts you if a policy change you're making impacts other roles. The message lists the names of all roles impacted by your edit, and prompts you to confirm whether or not you want to continue to make the change. Select one of these options:

  • Click Yes to continue to apply the access change to the inherited custom role in either of these situations:

    • You want to make the access change to all the roles listed in the warning message.

    • You don't want to make the access change to all the roles listed in the warning message, but you do want to apply the access change to the job role you're editing now.

      In this situation, make a note of the roles listed in the message before clicking Yes. At a later time, you can directly update each role listed in the message to restore the access it provides to its original setting. This process can be time consuming if there are a number of roles affected by the edit of the inherited duty role so it's a good idea to avoid this situation if possible. For example, if you removed a privilege from the custom inherited role, you will have to manually add the privilege back to each job role listed in the message, or to the job role associated with each duty role listed in the message.

  • Click No if you decide not to apply the access change to the inherited custom role. Instead, use these steps to implement the access change for the top-level job role only:

    1. Modify the role hierarchy of the top-level job role by removing the inherited custom role.

    2. Do one of the following:

      • Make a copy of the inherited custom duty role you removed using the Copy top role option, assign the copied duty role to the top-level job role, then edit the duty role as required.

      • Directly assign the job role with the access provided by the removed inherited duty role that you want to retain.

Edit Inactive Policies

If you specified an end date for a policy, then once the end date is passed, the policy is inactive. You cannot edit inactive policies for custom roles but you can delete them, as described in the following procedure.

To delete an inactive policy:

  1. On the Sales and Service Access Management page, select a custom role in the Role field and an object in the Object field.

  2. Click the Inactive policies check box.

  3. Click Find Policies.

    All inactive policies are displayed in the Access Policies table.

  4. Click the Edit icon.

  5. On the Inactive Policies page, select a policy and click the Delete icon.

  6. Click Yes when a warning is displayed.

  7. Click Save and Close to return to the main page.

    The deleted policy is no longer included in the Access Policies list and the number in parentheses beside the Inactive policies check box is reduced.

Note: You can reactivate a policy that is deactivated by reassigning the appropriate read, update, and delete permissions to the relevant criteria and specifying a start date for the policy on the Active Policies edit page.

You can provide custom roles with visibility to object data they can't currently access by creating new data security policies on those roles for the relevant object.

For example, if you want to provide sales managers with access to budget data for a specific initiative, then you have to create access to the relevant budget object for a custom version of the Sales Manager job role, because the Sales Manager job role doesn't provide access to budget data by default. The following procedure describes how to create access to a new object for a custom role.

To extend object access for a role:

  1. On the Sales and Service Access Management page, click the Create button.

  2. On the Create Policies page, search for the custom role whose access you want to extend in the Role field.

  3. Select the object you want to provide access to in the Object field.

    For example, select the object for budgets, MDF Budget. The only objects available for selection are objects where data security policies are not already defined for the custom role.

  4. Click Find Policies.

    All the data security policies defined for the selected object are displayed in the Access Policies table. There are no permissions selected in the Permissions columns because data access to the object hasn't previously been configured for the custom role you selected.

  5. Locate the condition that provides the data access you want to implement for the object.

    For example, if you want to provide the custom sales manager role with read access to all budgets that have a status of Draft up to the end of the year, then do the following:

    1. Locate the condition that provides the required access. For example, locate a condition similar to the following: Access the MDF budget for table MKT_BDT_BUDGETS_B for all MDF budgets in the enterprise, and the MDF budget is in draft status.

    2. Click the Read check box for this condition.

    3. Specify a Start Date of today and an appropriate End Date.

  6. Click Save and Close.

    On the Sales and Service Access Management page, the new policies you have added are now listed in the Access Policies table.

    Note: You can view data security for custom objects using the Sales and Service Access Management work area, but you can only edit security policies for custom objects using Application Composer.

Review and Troubleshoot Data Access Issues for Users

Overview of the Data Access Explorer

You can use the access explorer functionality that the Sales and Service Access Management work area provides to quickly troubleshoot data access issues reported by your users. These are some examples of the typical access issues you might have to investigate:

  • You create a custom sales representative role that removes access to all accounts but users assigned the custom role still have all account access. Which data access conditions are providing the access?

  • A sales manager can't see opportunities assigned to her reports. Which data access condition must she be assigned to get access?

To identify the cause of a user access issue, you must be able to view the data access policies that a user is currently granted for an object, and all the policies that provide access to the relevant object or record. You can view both types of information on the Explore UI. You can:

  • Review all the access policies granted to a user for an object, and all the roles that provide the access.

  • Discover which policies are affecting a user's ability to view a specific object record.

With this information, you can identify why a user can or can't view a specific record or records, and then grant or revoke the appropriate data security policies using the Sales and Service Access Management UI.

Make Additional Objects Available in Access Explorer

You can view a user's data access to the following objects by default on the Explore UI:

  • Opportunities

  • Leads

  • Activities

  • TCA Party

If you want to be able to view user access to additional objects, you can do so by configuring the lookup, Enable Staged Object Access in Access Explorer, and specifying lookup codes for each object you want to make available. This procedure describes what you need to do to expose additional objects on the Explore page.

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

    • Offering: Sales

    • Functional Area: Sales Foundation

    • Task: Manage Standard Lookups

  2. On the Manage Standard Lookups page, create a lookup type with the following values:

    • Lookup Type: ZCA_SAM_STAGED_OBJECT_ACCESS

    • Meaning: Enable Staged Object Access in Access Explorer

    • Module: Simplified Access Management

  3. Click Save.

  4. Create lookup codes for each object you want to make available on the Explore page. For example, to add two partner objects as lookup codes, enter these values.

    Lookup Code Meaning

    ZPM_PARTNER_PROFILES

    Partner Profile

    ZPM_PROGRAM_ENROLLMENTS

    Partner Program Enrollment

  5. Click Save and Close, then click Done.

Object Lookup Codes

This table shows the lookup code to specify for each object you can expose on the Explore page.

Object Lookup Code Meaning

HZ_CUST_ACCOUNTS

Trading Community Customer Account

MKL_DM_DEAL_PRODS

Deal Registration Product

MKL_DM_DEAL_RESOURCES

Deal Registration Team

MKL_DM_DEALS

Deal Registration Summary

MKT_BDT_BDGT_ENTRIES

Marketing Budget Entry

MKT_BDT_BUDGETS_B

MDF Budget

MKT_BDT_CLAIMS

MDF Claim

MKT_BDT_CLM_SETTLEMENTS

MDF Claim Settlement

MKT_BDT_FUND_REQUESTS

MDF Request

MKT_CM_CAMPAIGNS

Top Level Campaign

MKT_IMP_MAP

File Import Mapping

MKT_IMP_OBJECTS

File Import Object

MOT_TERR_PROPOSALS

Sales Territory Proposal

MOT_TERRITORIES

Sales Territory

OSS_SUBSCRIPTIONS

Subscription

SVC_SERVICE_REQUESTS

Service Request Header

SVC_WORK_ORDERS

Field Service Work Order

ZCA_ASSET

CRM Asset

ZCA_BP_BUSINESS_PLANS

Sales Business Plan

ZCA_OBJECTIVES

Sales Objective

ZCA_SALES_ORDER_HEADERS

Sales Order

ZPM_PARTNER_PROFILES

Partner Profile

ZPM_PARTNER_PROGRAMS_B

Partner Program

ZPM_PROGRAM_ENROLLMENTS

Partner Program Enrollment

Review a User's Access to Object Data

You can view all the policies that currently affect the visibility a user has to an object, and the names of all the roles that provide each policy, using the Sales and Service Access Management access explorer functionality.

A user can be granted the same data access policy from more than one role. For example, a user might be granted a policy directly by a job role, and indirectly by a duty role that the job role inherits. Being able to identify all the roles that provide a policy to a user is essential when you want to remove a user's access to a set of data.

Use these steps to review all the policies that affect a user's access to an object.

  1. Select Navigator > Tools > Sales and Service Access Management.

  2. On the Sales and Service Access Management page, click the Explore Access button.

  3. On the Explore page, select the name of the user whose access you're investigating in the User Name field.

  4. Select an object from the Object field, for example, select the Opportunity object.

    Don't enter a value in the Public Unique Identifier field. You only enter a value in this field if you want to investigate a user's access to a specific record.

    Note: Select the Trading Community Party object to view access policies for both accounts and contacts.
  5. Click the Explore button.

    All the currently active policies for the object that are granted directly or indirectly to the user are displayed. For each policy you can also view:

    • The name of the role that provides the policy. If the user inherits the policy from more than one role, click the link beside the role name to see a list of all roles.

    • The status of the policy. By default, active policies are displayed.

    • The policy start and end dates, and the permissions provided by the policy.

    • Whether or not the policy condition is a custom condition.

    The Provides Record Access column indicates if a policy provides access to the record specified in the Public Unique Identifier field. Because you haven't entered a value for this field, the Provides Record Access column is empty and the Provides Record Access drop-down list, which lets you filter values for the Provides Record Access column, is inactive.

    You can display more or less data for each policy by selecting options from the View menu.

  6. Once you have reviewed all the active policies assigned to the user, you can select options from the Show Conditions drop-down list to view other policies available for the object. This table shows the options available.

    Filter Option Description

    All

    Display all policies defined for the object, including policies that are granted to the user and policies that aren't granted.

    Granted and active

    Display all active policies for the object that are granted to the user. This is the default value.

    Granted and inactive

    Display all inactive policies defined for the object that are granted to the user.

    Granted and future dated

    Display all inactive policies defined for the object that are granted to the user which are set to become active at some date in the future.

    Not granted

    Display all policies defined for the object that aren't currently granted to the user.

Troubleshoot data access issues for users using the access explorer functionality. On the Explore page, you can view all the policies that affect a user's ability to view an object record and to see whether or not each policy has been granted to the user. You can use this information to find answers to questions such as these:

  • What access policy do I have to grant to give the user access to a specific record?

  • Which granted access policy do I have to remove from the user so that the user can no longer access a record?

For example, the predefined Sales Manager role allows sales managers to view the opportunity records belonging to their subordinates. If a manger reports that she can't see the opportunities of one of her subordinates, use the Explore page to discover what's causing the problem. To do this, you need the following information:

  • The user name of the manager

  • The object name, in this case, opportunity

  • The Public Unique Identifier of one of the subordinate user's opportunity records

When you enter this information on the Explore page, all the policies that give access to the record are listed. You can then check if the manager is provisioned with these policies, identify the role providing the policy, and update the role to grant the policy.

Use these steps to review all the policies that affect a user's access to a specific object record.

  1. Select Navigator > Tools > Sales and Service Access Management.

  2. On the Sales and Service Access Management page, click Explore Access.

  3. On the Explore page, select the name of a user in the User Name field. In this scenario, enter the name of the sales manager.

  4. Select an object in the Object field. In this scenario, select the Opportunity object.

    Note: Select the Trading Community Party object to view access policies for both accounts and contacts.
  5. Enter the PUID of one of the opportunity records that the manager wants to access in the Public Unique Identifier field.

    For information on how to find the PUID of a record, see the topic Display the Public Unique Identifier for Object Records.

  6. Click the Explore button.

    All the access policies for the object that grant access to the record are displayed by default.

    The Status field shows whether or not each policy is granted to the user whose name you selected in the User Name field. The Status column can have one of these values:

    • Active: The policy is active and is granted to the user.

    • Inactive: The policy is granted to the user but is inactive.

    • Future Dated: The policy is granted to the user but is not yet active.

    • Not Granted. The user is not granted the policy.

    The Provides Record Access field indicates whether or not an individual policy grants access to the record specified in the Public Unique Identifier field. A check mark in the field indicates that the policy provides record access; if the field is empty, the policy doesn't provide access to the record.

    You can use the information from the Status and Provides Record Access fields to figure out what you have to do to provide the user with access. For example, you might find that the policy that provides a sales manager with access to their subordinates opportunity records is future dated. In this case, note the name of the role providing the policy and edit the role on the Sales and Service Access Management page to change the start date of the policy to the current date.

  7. By default, the value of the Show Conditions drop-down list is All and the value of the Provides Record Access drop-down list is Yes so the Explore page lists all polices defined for the object that grant access to the record.

    You can change the selections in these lists to provide different views of the user's access to object data. For example, to view all the policies that are defined for the object, including policies that do and policies that don't provide access to the record, select All from the Show Conditions list and leave the Provides Record Access drop-down list empty.

Display Public Unique Identifiers for Object Records

The sales application generates a unique number (or ID) for each business object record, such as an opportunity record, when the record is created in the database. As an administrator, you can configure the unique ID that's generated to make it more user-friendly and readable. This user-friendly value is called the public unique ID (PUID).

The PUID values for object records aren't displayed on the UI by default. To make these values visible, add the PUID field of the object to the object page using Application Composer. To do this, you require read-only access to all of the object records and access to Application Composer.

The following are the steps to add the Opportunity Number field to the Opportunities page. The Opportunity Number field displays the PUID value of opportunity records. Follow a similar process for any other objects whose PUID values you want to make available on the UI.

  1. Activate a sandbox.

    See the topic Create and Activate Unified Sandboxes for more information.

  2. Select Navigator > Configuration > Application Composer.

  3. On the Application Composer Overview page, navigate to the standard object whose PUID values you want to expose.

    For example, expand Opportunity

  4. Select the Pages node.

  5. Select the Application Pages tab.

    You can use the links on the tab to navigate to the object's configuration pages, where you can modify the pages that are available for the selected object. You can show or hide fields, rearrange fields, and add your own fields.

  6. The Opportunity Number field shows the PUID value for an opportunity record. To make this field available on the UI, in the Landing Page Layouts region, select Standard Layout, then select Duplicate from the Actions menu.

  7. Enter a name for the new layout, then click Save and Edit.

  8. Locate the Fuse Opportunity Overview Table area and click the Edit icon.

  9. In the Available Fields list, locate the Opportunity Number field and move it to the Selected Fields list.

  10. Click Save and Close.

  11. Test the changes by navigating to the Opportunities page as a user with access to the opportunities pages, for example, a salesperson.

  12. Search for an opportunity, and verify that the PUID value is showing for the opportunity.

  13. Publish the sandbox.

  14. Navigate to the Sales > Opportunities page and search for an opportunity record. The PUID of the opportunity is displayed.

For information on exposing attributes and working with sandboxes, see the Oracle Applications Cloud Configuring Applications Using Application Composer guide. For information on public unique IDs, see the Oracle CX Sales Implementing Sales guide.

PUID Fields for Objects

This table shows the field that must be exposed in Application Composer to make the PUID values for the object's records visible on the UI.

Object Name in Application Composer PUID Field to Expose

Account

Registry ID

Activity

Activity Number

Asset

Asset Number

Business Plans

Number

Campaigns

Campaign Number

Contact

Registry ID

Deal Registration

Registration Number

Deal Registration: Deal Products

DealProdNumber

Deal Registration: Deal Resources

DealResourceNumber

MDF Budget

Code

MDF Claim

Code

MDF Claim Settlement

Code

MDF Request

Code

Objective

Number

Opportunity

Opportunity Number

Partner

Partner Number

Partner Programs

Program Number

Program Enrollments

Enrollment Number

Sales Lead

Lead Number

Sales Orders

Quote or Order Number

Sales Territory

Territory Number

Sales Territory Proposal

Proposal Number

Service Request

Reference Number

Subscription

Subscription Number

Work Order

Reference Number

Manage Database Resources

Data security policies secure the database resources of an enterprise. This topic describes how to manage database resources and data security policies if, for example, you want to define and secure a new database resource, or if the predefined data security conditions for a database resource don't meet your needs. Using the Manage Database Resources and Policies page of the Security Console, you can:

  • Define a new database resource

  • Create data security policies to secure a new database resource

  • Create new database resource conditions for a database resource

To perform the tasks in this topic, you must have the IT Security Manager job role.

Define Database Resources

A database resource is a database table or view that corresponds to a business object. When you create a custom business object that you want to secure, you must define its associated database table or view as a database resource. To define a table or view as a database resource, you must:

  • Specify the primary key column of the database resource

  • Filter columns of the database resource to exclude columns from being included in the row instance sets that can be made available to users through data security policies

  • Identify conditions and actions for the database resource to determine what portions of the resource can be secured by data security policies and the operations that can be performed on the data

The following procedure describes each of these tasks.

To define a new database resource:

  1. On the Security Console Administration tab, select the General subtab, then click Manage Database Resources.

    The Manage Database Resources and Policies page is displayed.

  2. In the Search Results region, click the Create icon.

    The Create Database Resource page is displayed. The General Information subtab is selected by default.

  3. Enter the values for the new database resource.

    The following table describes the field values to specify for the new database resource.

    Field Value

    Object Name

    The name of the custom business object you want to define as a database resource.

    Display Name

    The display name of the business object.

    Data Object

    Select the data resource (table or view) that the custom business object represents.

    When you select a value for the Data Object field, the Primary Key Columns and Filter Column Details areas are displayed.

    Module

    Select the user module associated with the resource.

  4. Click the Function Security Enabled check box if functional security policies have been defined for the business object.

  5. In the Primary Key Columns area, click the Create icon.

  6. In the Primary Key field, select the primary key column of the database table or view that the business object represents.

  7. In the Filter Column Details area, select columns you want to exclude from the row instance sets defined by data security policies. The data from filtered columns isn't accessible by users. To select a column as a data filter, move it from the Available Columns list to the Selected Columns list.

  8. Click the Condition subtab to create conditions for the new database resource, then click the Create icon.

    The Create Database Resource Condition dialog box is displayed. Conditions specify the rows of the database resource that can be secured by data security policies.

  9. Create resource conditions as described in the procedure Creating Conditions for a Database Resource later in this topic.

  10. Click the Action subtab.

    You define actions on the database resource to specify the operations data security policies can secure on a business object. For example, you can specify whether a user might have read, update, or delete access by naming actions for each of these and granting them in a data security policy to a particular role. An action must correspond with an operation that the business object implements.

  11. Click the Add Row icon.

  12. Enter a value in the Name and Display Name fields. The action name you enter must match an operation name defined for the corresponding business object. Actions act on the row instance sets specified by the database resource conditions that you define in a data security policy, that is, conditions determine the row instance set available to a user for a given action.

    You can specify more than one action.

  13. Click Submit.

  14. When the confirmation dialog box is displayed confirming that the database resource was created, click OK.

Create Conditions for a Database Resource

Database resource conditions define what portions of a database resource can be secured by data security policies. You can't edit the predefined conditions provided by Oracle but you can create new conditions for a predefined database resource or for a database resource you have created.

A condition is a group of row instances that are determined by a simple XML filter or an SQL predicate (WHERE clause) that queries the attributes of the resource itself. You can define a condition to specify multiple row instance sets using an SQL WHERE clause with parameters. You don't need to define a condition for single row instance conditions (single value) or for all row instance conditions (all values). Both the single-value case and the all-values case can be easily defined when you create the data security policy.

To create conditions for a database resource:

  1. On the General subtab of the Security Console Administration tab, click Manage Database Resources.

    The Manage Database Resources and Policies page is displayed.

  2. Search for the database resource whose conditions you want to edit.

  3. In the Search Results list, select the appropriate database resource, then click the Edit icon.

    The Edit Data Security page is displayed.

  4. Select the Condition subtab to define a new condition for the resource.

    Any existing conditions defined for the database resource are displayed. You can't delete or edit any predefined conditions.

  5. Click the Create icon.

    The Create Database Resource Condition dialog box is displayed.

  6. Enter a name and display name for the condition.

  7. For the Condition Type, select one of the following:

    • Select Filter if you want to use the attribute picker to define a simple condition. If you select the filter condition type, you also must specify the following values:

      • For the Match option, select the All option if you want the filter conditions to include AND clauses or select the Any option if you want the filter conditions to include OR clauses.

      • In the Conditions area, click the Add icon.

      • Define the filter values.

        The following table describes the filter values for each field.

        Field Value

        Column Name

        Select the column for which you're defining the filter.

        Tree Operators

        Select this option if the operator you want to use in the filter is a tree operator.

        Operator

        Choose the operator for the selected column filter.

        Value

        Enter a value as the test for the operator.

        If you specified the Tree Operators option, click the Search icon. The Select Tree Node dialog box is displayed allowing you to choose the operator value.

      • Click Save.

    • Select SQL Predicate if you know the attribute names of your condition and you want to use an SQL predicate consisting of a query on the table or view named by the database resource. Enter the SQL values in the SQL Predicate field.

  8. Click Save to save the new condition.

Create a Data Security Policy for a Database Resource

When you register a new business object as a database resource, users will initially be prevented from initiating the operations of the business object or from accessing the data of the resource. You define data security policies to make the data of a custom business object available to the users of the application.

Before you create a data security policy, make sure that the following tasks have been completed:

  • Identify the business object that you want to secure and register its associated database table or view as a database resource.

  • Identify and define any conditions that you want to make available for the database resource.

  • Identify and register the actions that you want to secure for this database resource.

To create a policy for a database resource:

  1. On the General subtab of the Security Console Administration tab, click Manage Database Resources.

    The Manage Database Resources and Policies page is displayed.

  2. Search for the database resource that you want to secure by defining a policy.

  3. In the Search Results list, select the database resource, then scroll down to the Policies Details area.

    All the policies defined for the database resource are displayed.

  4. You can select an existing policy for editing by selecting the policy then clicking the Edit icon. In this case, however, click the Create icon to create a new policy.

    The Create Policy dialog box is displayed with the General subtab selected.

  5. Specify the following information for the new policy:

    • In the Name field, enter a name for the policy.

    • In the Start Date field, enter the date on which the policy is to become active.

    The Module field is pre-filled with the name of the module associated with the database resource for which you're creating the policy but you can change this value.

  6. Click the Role subtab, then click the Add icon to select the roles that are to be assigned the new policy.

    The Select and Add: Roles dialog box is displayed.

  7. Select the roles to be assigned the new policy as follows:

    • In the Role Name field, enter the name of the role.

    • In the Application field, enter the application stripe of the role, for example, CRM, HCM, or FSCM, then click Search.

    • Select a role from the list of roles displayed, then click Apply to associate the role with the new policy.

    • Select any additional roles from the list and, when you have finished adding roles, click OK.

    All users assigned the roles you select are provided with access to the data defined in the policy.

  8. Click the Rule subtab to define a rule to specify the rows of the database resource to which the policy applies.

  9. Select one of the following values in the Row Set field:

    • To secure a specific row, select Single Value, then search for and select the row you want to secure in the Row field.

    • To secure all rows in the resource, select All Values.

    • To secure a subset of the data in the data resource select Multiple Values, then search for and select the condition that defines the subset of the data to be secured in the Condition field.

  10. Click the Action subtab, then move actions from the Available Actions list to the Selected Actions list to specify the actions, applicable to the data secured on the database resource, which you want to grant to the role.

  11. Click Save and Close.