Uploaded by Narapat Patcharapornpun

SFDC AdminCert-Note

advertisement
A Guide to Sharing Architecture
• Components of Sharing
Profile Access Permissions
• Restrict a user’s access to a whole object (table)
Permissions are Create, Read, Edit and Delete.
For example, if a user doesn‘t have the read permission on opportunities, he can’t see any of
these records – even if he owns them.
Opportunity Name
Type
Probability
Commission
Amount
Contract End
Date
Acme – 1,000,000 widgets
New Business
30%
$2,000
Midway Associates – services
Add-on business
75%
$1,500
12/31/04
Genwatt Corp – maintenance
contract
Add-on business
10%
$3,500
11/30/05
Universal Containers – custom
fittings
New Business
25%
$7,000
Sharing Matrix
• Source: https://certifiedondemand.com/security-model-matrix/
Organization
Objects
Fields
Records
Login Hours
Login IP Ranges
API Enabled
Create
Read
Edit
Delete
Read (Listed as "Read-Only" in config)
Edit (Listed as "Visible" in config)
View All Data
View All (Per Object)
Modify All Data
Modify All (Per Object)
API Enabled
Create
Read
Edit
Delete
Read
Edit
View All Data
View All (Per Object)
Modify All Data
Modify All (Per Object)
Permission Set
Role
No Impact
No Impact
No Impact
Sharing Rules
Role Hierarchy
Group Member
No Impact
No Impact
No Impact
Sharing Rules
Org-Wide Default
No Impact
No Impact
No Impact
Default Access per Object
Profile
Record share
Use Cases and Considerations
Component
Use Cases
Considerations
Org Wide Defaults
• Identifies the most restrictive
visibility for an object
• Public vs. Private trade-offs
Ownership and Queues
• Defines user or collection of
users who can own a record
• Always assign owner from queue
• Minimize data skews
Role Hierarchy
• Provides management access and • Foundation of sharing
reporting
• Design to visibility requirements
• Allows for organization data
and not org chart
partitioning
• Keep role count and depth to a
minimum
Use Cases and Considerations
Component
Use Cases
Considerations
Public Groups
• Provide arbitrary access to data
• Create ad-hoc hierarchies
• Requires other mechanisms to
share data
• Limit nesting
• < 100,000 groups
Sharing Rules
• Create overlay structures
• Provide Peer/team access
• Owner vs. Criteria
• Ensure design is scalable
Teams
• Support external territory
management
• Assign multiple account owners or
overlays
• Add escalated case workers
• Account and Case team are not
first class objects
• API/Apex need to create shares as
well
Use Cases and Considerations
Component
Use Cases
Manual Sharing
• Add manual exceptions to sharing
Implicit Sharing
• Define child sharing to account’s
children
• Provide parent sharing to children’s
related account
Considerations
• Child sharing defined in role
hierarchy or team
• Parent sharing is native to
Salesforce
• For Case, Contact and Opportunity
Download