Print      Open PDF Version of Online Help

Administering Oracle CRM On Demand > User Management and Access Controls > How Access Rights Are Determined > Example 1: Using the View Access Level

Example 1: Using the View Access Level

This topic provides one example of how Oracle CRM On Demand calculates the access rights of users.

In this example, Amanda Jacobsen has the Sales Rep role. Amanda can create new accounts and see all other account records. She is allowed to create opportunities, but she can see only opportunities that she owns or that she is authorized to see.

The following table shows the record-type settings on the Sales Rep role.

The Sales Rep role gives Amanda full control over the accounts and opportunities that she creates and restricted rights on records that she does not own. The Sales Rep role requires two access profiles: an owner access profile and a default access profile.

The following table shows the settings for the Sales Rep Owner Access Profile.

The following table shows the settings for the Sales Rep Default Access Profile.

In this example of calculating access rights, it is assumed that team inheritance is not enabled for the Opportunity record type, that is, the Enable Parent Team Inheritance for Opportunity check box on the Company Profile page is deselected. For more information about the behavior of the parent team inheritance functionality, see About Access Propagation Through Team Inheritance.

David Bloom also has a Sales Rep role in the same company. David has the same access rights as Amanda.

Amanda is the owner of Opportunity X, which is linked to Account 1. David creates an opportunity, Opportunity Y, and also links it to Account 1. Amanda is not on the opportunity team.

When Amanda views the list of the accounts in her company, she can see all accounts because her role allows her visibility to all accounts, including those she does not own. The following table shows the records that Amanda sees when she clicks the Account 1 account name to drill down on the record. For this example, only the relevant fields and columns are shown.

Related Record Visibility in Example 1

To determine which related opportunity records Amanda can see on the account in this example, Oracle CRM On Demand examines Amanda’s access rights, as follows:

1. Oracle CRM On Demand examines all of the applicable access levels for the opportunity related record type on this parent account record, as follows:

   NOTE: If multiple access levels are discovered from the various access-control components, all of them are considered when calculating access rights.

   • Determines if Amanda owns the parent account.

     In this example, the answer is no.

   • Determines if Amanda’s role allows her to read all account records.

     In this example, the answer is yes. Amanda’s role allows her to read all account records, therefore Amanda can see the account. Because Amanda is not the owner of the parent account, her default access profile is used. The access level for the opportunity related record type on Amanda’s default access profile is View.

   • Determines if the parent record is in a book where Amanda is a book member.

     In this example, the answer is no.

   • Determines if Amanda is a member of the account team.

     In this example, the answer is no.

   • Determines if any of Amanda’s subordinates (direct or indirect) is a member of the account team.

     In this example, the answer is no.

     If the answer to this question is yes (that is, one or more of Amanda’s subordinates is a member of the account team), Oracle CRM On Demand extracts the access level for the opportunity related record type for each of those subordinates from the appropriate access profile. The access profile assigned in the Account Access field on the subordinate's team membership on the account is used in that case (not the access profile assigned in the Opportunity Access field).

   • Determines if Amanda has access to the account record through delegation.

     In this example, the answer is no.

2. Oracle CRM On Demand then does the following:
   • Determines if Amanda‘s role allows her basic access to opportunity records.

     In this example, the answer is yes, because the Has Access option is selected for the Opportunity record type on the user’s role.

   • Determines if Amanda’s role grants her the privilege for the opportunity record type.

     Opportunities are not controlled through privileges, therefore, in this example, the privileges do not affect the calculation of Amanda’s access rights.

   • Determines if the access level on any of the access profiles in the calculation is set to Inherit Primary or one of its combinations.

     In this example, the answer is no.

3. Oracle CRM On Demand then examines all of the access levels found and determines the most permissive level. In this case, the most permissive access level found is View. The Inherit Primary access level is not present, therefore all child opportunity records, including those the user is not authorized to see, are shown.

Actions on Related Records in Example 1

When a user attempts to perform an action on a related record, Oracle CRM On Demand must determine whether the user has the appropriate access rights for that action. In this example, Amanda can attempt to read the record details, or to edit the record, or to delete the record. Two cases are considered:

• In Case 1, Amanda attempts to perform an action on Opportunity X.
• In Case 2, Amanda attempts to perform an action on Opportunity Y.

Case 1: Amanda attempts to perform an action on Opportunity X, which she owns.

Oracle CRM On Demand examines Amanda’s access rights, as follows:

1. Oracle CRM On Demand examines all of the applicable access levels for the opportunity related record type on this parent account record, as follows:

   NOTE: If multiple access levels are discovered from the various access-control components, all of them are considered when calculating access rights.

   • Determines if Amanda owns the parent account.

     In this example, the answer is no.

   • Determines if Amanda’s role allows her to read all opportunity records.

     In this example, the answer is no. Although Amanda can see the parent account record because her default access profile is used, her default access profile is not used for the opportunity record.

   • Determines if the opportunity record is in a book where Amanda is a book member.

     In this example, the answer is no.

   • Determines if Amanda is a member of the opportunity team.

     In this example, the answer is yes. Amanda is the owner of the opportunity, and is therefore in the opportunity team. The access level of the primary opportunity record type from Amanda’s default access profile (the Sales Rep Default Access Profile) is Read/Edit/Delete.

   • Determines if any of Amanda’s subordinates (direct or indirect) is a member of the opportunity team.

     In this example, the answer is no.

   • Determines if Amanda has access to the account record through delegation.

     In this example, the answer is no.

2. Oracle CRM On Demand then does the following:
   • Determines if Amanda’s role allows her basic access to opportunity records.

     In this example, the answer is yes, because the Has Access option is selected for the Opportunity record type on Amanda’s role.

   • Determines if Amanda’s role grants her the privilege for the Opportunity record type.

     The Opportunity record type is not controlled through privileges. Therefore, in this example, the privileges do not affect the calculation of Amanda’s access rights.

   • Determines if the access level on any of the access profiles in the calculation is set to Inherit Primary or one of its combinations.

     In this example, the answer is no.

3. Oracle CRM On Demand then examines all of the access levels found and determines the most permissive level. In this case, the most permissive access level found is Read/Edit/Delete.

Case 2: Amanda attempts to perform an action on Opportunity Y, which is owned by David Bloom.

Oracle CRM On Demand examines Amanda’s access rights, as follows:

1. Oracle CRM On Demand examines all of the applicable access levels for the opportunity related record type on this parent account record, as follows:

   NOTE: If multiple access levels are discovered from the various access-control components, all of them are considered when calculating access rights.

   • Determines if Amanda owns the parent account.

     In this example, the answer is no.

   • Determines if Amanda’s role allows her to read all opportunity records.

     In this example, the answer is no. Although Amanda can see the parent account record because her default access profile is used, her default access profile is not used for the opportunity record.

   • Determines if the opportunity record is in a book where Amanda is a book member.

     In this example, the answer is no.

   • Determines if Amanda is a member of the opportunity team.

     In this example, the answer is no.

   • Determines if any of Amanda’s subordinates (direct or indirect) is a member of the opportunity team.

     In this example, the answer is no.

   • Determines if Amanda has access to the account record through delegation.

     In this example, the answer is no.

2. Oracle CRM On Demand then does the following:
   • Determines if Amanda’s role allows her basic access to opportunity records.

     In this example, the answer is yes, because the Has Access option is selected for the Opportunity record type on Amanda's role.

   • Determines if Amanda’s role grants her the privilege for the Opportunity record type.

     The Opportunity record type is not controlled through privileges, therefore, in this example, the privileges do not affect the calculation of Amanda’s access rights.

   • Determines if the access level on any of the access profiles in the calculation is set to Inherit Primary or one of its combinations.

     In this example, the answer is no.

3. Oracle CRM On Demand then examines all of the access levels found and determines the most permissive level. In this case, the final access level is No Access.

Related Topics

See the following topics for additional examples:

• Example 2: Using the Inherit Primary Access Level
• Example 3: Securing Data Through Books