1. Visibility & Data Access
1.1. Organization Wide Defaults
1.1.1. Private
1.1.1.1. No record access granted - Only the creator can see
1.1.2. Public Read Only
1.1.2.1. Read only record access granted
1.1.3. Public Read/Write
1.1.3.1. Read / Write record access granted
1.1.4. Public Read/Write/Transfer
1.1.4.1. Full record access granted
1.1.5. Controlled by Parents
1.1.5.1. Parent record controls access.
1.2. Roles
1.2.1. Extends Record visibility vertically
1.3. Groups
1.3.1. To streamline the process of sharing access to records and folders.
1.3.2. A group is comprised of users, roles and other groups
1.4. Sharing Rules
1.4.1. Extend access to users in roles, public groups ...
1.4.2. Sharing Rules can never be stricter than your organization-wide default.
1.4.3. Can extend either Read Only or Read/Write Access.
1.4.4. TYPES
1.4.4.1. Account Sharing Rules
1.4.4.2. Account territory sharing rules
1.4.4.3. Assest Sharing Rules
1.4.4.4. Campaign sharing rules
1.4.4.5. Case sharing rules
1.4.4.6. Contact sharing rules
1.4.4.7. Custom object sharing ules
1.4.4.8. Lead sharing rules
1.4.4.9. Opportunity sharing rules
1.4.4.10. Order sharing rules
1.4.4.11. User sharing rules
1.4.4.12. User provisioning request sharing rules
1.5. Security
1.5.1. Org Security
1.5.1.1. When, where and how a user can login.
1.5.2. Object Security
1.5.2.1. What actions a user can take on the records of a particular object.
1.5.3. Record Security
1.5.3.1. What actions a user can take on an existing record
1.5.4. Field-level Security
1.5.4.1. Determins which fields a user can view and update for each object.
1.5.5. Folder Security
1.5.5.1. Determines access to a variety of information including reports , dashboards, email templates, and more.
1.6. Queue
1.6.1. When a user is a member of a queu and a record is owned by a queue, then the user will inherit "Full Access" to that record.
2. Master Detail
2.1. Child record Must have a parent
2.2. Cascade Record-level security
2.3. Roll-up Summary fields on parent Object
2.4. Standard object cannot be detail object
2.5. EXAMPLE
2.5.1. Master - School
2.5.1.1. Rollup on how many classrooms a school has
2.5.2. Children - Classroom
2.6. LIMITS
2.6.1. Each custom object can have up to two master detail relationships.
3. Lookup Relationships
3.1. Relationships are optional
3.2. No impact on Security
3.3. Roll-up Summary fields cannot be established
3.4. If a lookup Field is optional you can specify behavior on deletion
3.4.1. Clear the values of this field
3.4.2. Don't allow deletion of the lookup record that's part of a lookup relationship.
3.4.3. Delete this record also.
3.5. EXAMPLE
3.5.1. Venue
3.5.1.1. Rollups are not possible.
3.5.2. Campaign
3.5.2.1. Campaign can have a Venue, but does not need.
4. Many-to-Many
4.1. Allows each record of one object to be linked to multiple records.
4.2. EXAMPLE
4.2.1. A bug object that relates to the standard case object such that a bug could be related to multiple cases and a case could also be related to multiple bugs.