Administering Oracle CRM On Demand > User Management and Access Controls > How Access Rights Are Determined > Example 2: Using the Inherit Primary Access Level
Example 2: Using the Inherit Primary Access Level
This topic provides one example of how Oracle CRM On Demand calculates the access rights of users.
In this example, Amanda Jacobsen is a Sales Rep in her company. 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.
Primary Record Type
|
Has Access
|
Can Create
|
Can Read All Records
|
Account
|
Yes
|
Yes
|
Yes
|
Opportunity
|
Yes
|
Yes
|
No
|
The Sales Rep role gives Amanda full control over the accounts and opportunities 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.
Primary Record Type
|
Access Level
|
Related Record Type
|
Access Level
|
Account
|
Read/Edit/Delete
|
Opportunities
|
Inherit Primary
|
Opportunity
|
Read/Edit/Delete
|
Not applicable
|
Not applicable
|
The following table shows the settings for the Sales Rep Default Access Profile.
Primary Record Type
|
Access Level
|
Related Record Type
|
Access Level
|
Account
|
Read-Only
|
Opportunities
|
Inherit Primary
|
Opportunity
|
Read-Only
|
Not applicable
|
Not applicable
|
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 is also a Sales Rep 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.
|
|
|
|
|
Account Detail: Account 1
|
Account Detail
|
Account Name:
|
Account 1
|
Owner:
|
Jonathan Hope
|
Opportunities
|
Opportunity Name
|
Owner
|
Opportunity X
|
Amanda Jacobsen
|
Account Team
|
Last Name
|
First Name
|
Account Access
|
Hope
|
Jonathan
|
Owner
|
Bloom
|
David
|
Member
|
Related Record Visibility in Example 2
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:
- Oracle CRM On Demand examines all of the applicable access levels for the opportunity related record type on this parent account record, as follows:
- 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 Inherit Primary.
- 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 the 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.
- 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.
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 yes, therefore Oracle CRM On Demand displays the following opportunity records on the account:
Actions on Related Records in Example 2
When Amanda attempts to perform an action on Opportunity X in this example, the calculation is the same, and the outcome of the access rights is the same as that in Case 1 in Example 1: Using the View Access Level. The final access level is Read/Edit/Delete.
Related Topics
See the following topics for additional examples:
|