Manage Security by Object

When you create custom objects, by default their UIs are visible only if you have the Custom Objects Administration (ORA_CRM_EXTN_ROLE) role. Use each custom object's Security node to specify the additional job roles that can access that custom object's UIs.

Use the Security node to provision data security for custom object records and restrict users who have privileges to view, update, or delete records. You can provision this type of security to all users or only to members of access groups, to owners of records or to an owner and his management hierarchy, and to user-defined roles. For example, you can make it possible for owners to update records, while managers can only view records.

Alternatively, you can update the security policy for a custom role, across multiple custom objects, using the Role Security link in the Common Setup pane. See "Manage Security by Role."

Managing Object Security

The object-centric Define Policies page displays a list of the custom roles available for selection. Use this page to manage access to either a top-level or child custom object by specifying a security policy for one or more custom roles. When you do this, users with the corresponding custom roles can access the custom object and its data, depending on the security policies you define. Alternatively, you can enable the custom object to use access group security, which means that only members of a specific access group can see the custom object records, depending on the rules that you define.

To access the object-centric Define Policies page:

1. Ensure that you're in an active sandbox session.

2. Navigate to Application Composer and on the main Overview page, select a custom object in the object tree.

3. Select the Security node. The page that displays is the object-centric Define Policies page.

4. Enable data security across multiple roles. For each role in the table, indicate if that role can create records, and indicate the level of access for viewing, editing, and deleting records.

   If data security is selected, the corresponding functional security is automatically selected.

5. If you want to enable the custom object to use access group security instead, then select the Enable Access Group Security check box. For more information about enabling access group security, see "Enable Access Group Security for Custom Objects."

   Note: Even if you select the Enable Access Group Security check box, you must still configure functional security in the Roles section so that the right roles can see the custom object's user interface pages.

6. You can optionally configure owner security instead of access group security. With owner security, for example, you can provide create and read access to all users, update access to the record's owner and owner management chain, and delete access to only the owner.

   If you configure both owner and access group security, then your users will see data from both their owner management chain as well as from access groups that they're members of.

   See "Manage Security for Owner and Owner Management Chain."

7. Select the Change History check box for each role that can view the custom object's Change History subtab.

   For the Change History subtab to be visible to users on a custom object record, you must do two things:

   1. Check the Change History check box.

   2. Add the Change History subtab to the custom object's details page layout.

      Refer to your product's implementation documentation for more information. For example, for Oracle CX Sales and Fusion Service, see "Enable the Change History Subtab" in the Implementing Sales guide.

See "Make Custom Object Pages Visible to Users" to learn about function security and data security.