Make Custom Object Pages Visible to Users

After creating custom objects and their respective user interface (UI) pages, you must indicate which end users can view the pages (functional security) and enter data (data security). You do this in Application Composer using the custom object's Security node, or the Role Security link in the Common Setup pane.

You can provision data security for custom object records and restrict users who have privileges to view, update, or delete records. You can give access 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.

Review these aspects of the custom object security process in Application Composer before you begin to define your security policies:

• Who can create custom objects?

• Who can see your custom object?

• Understanding security policies

• Custom vs. predefined roles

• Application Composer and the Security Console

Who Can Create Custom Objects?

By default, a custom object and its records are visible and editable only to users who are provisioned with the Custom Objects Administration (ORA_CRM_EXTN_ROLE) role. Users with any one of the three following job roles can also create custom objects and use all other Application Composer functions:

• Customer Relationship Management Application Administrator

• Application Implementation Consultant

• Master Data Management Application Administrator

Oracle recommends provisioning the user with the Customer Relationship Management Application Administrator job role (for performing the application changes) and the Custom Objects Administration job role and an Administrator job role (for testing the application changes in the UI).

Who Can See Your Custom Objects?

When you create custom objects, by default their UIs are visible only if you have the Custom Objects Administration (ORA_CRM_EXTN_ROLE) role. The application creates this custom role automatically. The UI pages you create for custom objects aren't visible to additional users unless you provide access in Application Composer using the object's Security node. Use the Security node to specify not only which job roles can access the UIs, but the levels of access. Provision data security for custom object records and restrict users who have privileges to view, update, or delete records. You can give access 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 object records, while managers can only view records.

To manage who can see your custom objects at runtime, do the following. In this procedure, we will look at sales managers and salespeople.

1. Ensure that you have assigned the Custom Objects Administration role to yourself and to other users who make application changes.

   The Custom Objects Administration role is automatically assigned to new custom objects, as well as existing custom objects, if you have upgraded from a previous release.

   Note: If you're creating your own objects, then you must also add the Custom Objects Administration role. The application automatically generates this object role the first time you create an object.

   See "Enable Sales Administrators to Test Configurations in the Sandbox."

2. For each custom object, use the Security node to specify which roles can view that object's UI pages, and their level of access: view, update, and delete. This is called a security policy. See the following "What's a Security Policy" section.

   When granting access to custom object UIs, you can select only custom job roles. For example, if you want to create a custom object for sales managers, then a custom sales manager job role must first exist (instead of the predefined Sales Manager job role provided by Oracle), before you can grant access to sales managers. If you want to create a custom job role, then copy the predefined Sales Manager job role in the Security Console as described in the Securing Sales and Service guide.

   Granting access to custom job roles means that your custom object won't be affected by future upgrades. See the "Custom vs. Predefined Roles" section later in this topic.

3. 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. See "Enable Access Group Security for Custom Objects."

4. If you're creating custom objects for a specific job role, then you must also assign yourself that job role to view and test the application changes in a sandbox. For example, if you're creating a custom object for sales managers, then you must assign yourself the sales manager job role to test how that object works for sales managers. If you later create a different object for salespersons, then you will have to deprovision the sales manager job role and provision yourself with the salesperson job role instead, so that you can accurately test your new object.

   • Setup users who have the permission to create and update users can grant themselves the appropriate job roles by editing their user record in the Manage Users work area.

   • Sales administrators who are resources can request the job role they need for testing by following the procedure described in "Assigning Yourself an Additional Job Role."

     To make job roles requestable for sales administrators, a setup user must create a special role-provisioning rule, as described in "Creating the Provisioning Rule for the Job Roles Used in Testing."

5. If you're adding a custom object subtab to a standard object, then you must also assign yourself the job role that can view the standard object's UI.

   For example, if you add a custom object subtab to the Edit Opportunity details page. In this case, you will need the role required to access the Edit Opportunity page, in addition to the role granted to the custom object.

What's a Security Policy?

For each custom object, you will need to update its security policy. A security policy specifies which users are authorized to access an object's data, and what type of access they have. Access includes both function security as well as data security. For example, does a user have view only access, or can the user create and update an object's record, as well?

As previously mentioned, custom objects are automatically assigned the Custom Objects Administration (ORA_CRM_EXTN_ROLE) role and creating a custom object record automatically grants you the owner role. Next, grant additional access to your custom object so that your end users can enter data.

For each custom object, you can grant access to multiple roles for a single object, or you can grant access to multiple objects for a single role.

• Define security policies for an object.

  Authorize the various custom roles whose users can access that object's data.

  You must define security policies for child objects, as well.

  See "Managing Security by Object: Explained."

• Or, define security policies for a role.

  Specify the role's access levels across multiple custom objects.

  See "Managing Security by Role: Explained."

Define the security policy for a custom object using the Security node in Application Composer, on the Define Policies page. On this page, you can manage an object's data security, which applies to a record of an object and an object's functional security, which applies to the object as a whole. The page provides options for the following security types:

• Create

  Users with the corresponding role can create a record of the object.

• Read

  Users with the corresponding role can view the object's work area pages.

• Update

  Users with the corresponding role can update a record of the object.

• Delete

  Users with the corresponding role can delete a record of the object.

The Read, Update, and Delete security types provide data security options for the following along with the functional security:

• Owner

• Owner and Management Chain

• All

The Owner field is available on all pages for custom objects. When you create a record, by default, you're the owner. With this security provisioned, you can filter records owned by you or your subordinates.

When you select any of the above data security options, the corresponding functional security is automatically selected.

Custom vs. Predefined Roles

The Define Policies page (for both custom objects and roles) displays custom roles. Custom roles are copies of the predefined roles that Oracle provides for all customers. You can't modify predefined roles, so they aren't displayed here. However, you can modify custom roles. Modifying a custom role means adding access to one or more custom objects so that role can view the custom object at runtime.

If you don't see a list of roles on the Define Policies page, then you must first copy the predefined roles that you need using the Security Console:

1. Use the Security Console to make copies of the predefined roles you need. These copied roles are known as custom roles.

   Refer to your product's security documentation for additional information. For example, for Oracle CX Sales and Fusion Service, see these topics in the Securing Sales and Service guide:

   • Copying Sales Roles: Points to Consider

   • Copying Job or Abstract Roles: Procedure

2. Navigate back to Application Composer, open the Security node for your custom object, then define the security policy across roles for your custom object.

If you upgraded from a previous release, then you might have made changes to predefined roles in an earlier release. During the upgrade to the current release, Oracle automatically copies those modified predefined roles for you, so they will appear as custom roles on the Define Policies page. See "Custom Roles and the Upgrade Process: Explained" in the Securing Sales and Service guide.

Application Composer and the Security Console

The Security Console manages the security policies that control access based on roles. However, you define the security policies for custom objects in Application Composer's object-centric and role-centric Define Policies pages. This is outside the Security Console.

Security policies defined in Application Composer can be modified in Application Composer. Don't use the Security Console to modify these policies.