Data Model - Visibility

https://architect.salesforce.com/fundamentals/platform-sharing-architecture

Profile and Permission Sets

Profiles set the foundational access controls for users, while Permission Sets allow for the customization of additional permissions to accommodate specific needs without changing the underlying profile.

Users → Permission Sets

Users → Profiles

Enable enhanced profile UI

Creating a Permission set

Navigate to Apps → Object Settings → select Access cards (click edit) and give permissions as shown below.

Click on Manage Assignments and assign it to a user.

FAQ

• Can we assign multiple Profiles to a user?

  No, in Salesforce, a user cannot be assigned multiple profiles. Each user is assigned a single profile that defines their basic level of access across the system. However, to grant additional permissions beyond what their profile allows, you can assign multiple permission sets to a user. This approach provides the flexibility to customize access for individual users without the need to create numerous highly specific profiles.

• Difference between permission set and permission set group

  Permission Sets in Salesforce provide a flexible way to grant additional access rights without altering user profiles, allowing for specific, granular permissions. Permission Set Groups bundle multiple permission sets into a single assignment, simplifying management by grouping related permissions and enabling the muting of specific permissions within the group. This grouping is particularly useful in complex permission environments in larger organizations.

Org-Wide Defaults

Org-Wide Defaults (OWD) are foundational settings in Salesforce that determine the baseline level of access users have to records they do not own. OWD settings are crucial for implementing a data security model that specifies whether records can be viewed or edited by other users across the organization.

Key Points:

• Purpose: Establishes the most restrictive level of access for records in the absence of other sharing rules or settings.
• Configurable per Object: OWD settings can be defined for standard and custom objects individually.
• Access Levels: Options include Private, Public Read Only, and Public Read/Write, among others depending on the object.
• Hierarchy Impact: Role hierarchies can override OWD settings, allowing managers to access the same records as their subordinates.

Where to View and Edit OWD Settings

OWD settings can be found in the Salesforce Setup menu under Security > Sharing Settings. Here, administrators can view and modify the default sharing access for each object.

Important FAQs

• How do OWD settings interact with other sharing tools?

  OWD settings provide the baseline access. Sharing rules, manual sharing, teams, and role hierarchies can then extend access beyond what OWD settings allow.

• Can OWD settings restrict access more than what's defined in a user's profile or permission set?

  No, OWD cannot restrict access further; it sets the base level. Profiles and permission sets grant minimum access rights, while OWD and sharing rules can extend these rights.

• What happens if I change the OWD settings?

  Changing OWD settings can have widespread effects on data visibility and access throughout your Salesforce org. Salesforce recalculates record access, which may temporarily impact system performance depending on the org's size and the extent of the change.

• When should I use "Public Read Only" vs. "Private" in OWD?

  • Public Read Only: Use this setting when you want all users to view records, but not edit them. Ideal for information that needs wide visibility but limited modification rights.
  • Private: Choose this setting when access should be restricted by default, with editing or viewing permissions granted only through role hierarchies, sharing rules, or permission sets.

Role Hierarchy

Records are shared vertically. Users → Roles

Salesforce role hierarchy is a structure that outlines the levels of access and visibility users have within a Salesforce organization. Here are the key points, properly numbered:

1. Role Definition: Each role within the hierarchy signifies a level of data access required by a user or group of users.
2. Data Visibility: Users can access data owned by or shared with users beneath them in the hierarchy, allowing managers to view data relevant to their teams.
3. Record Ownership: The hierarchy primarily affects record access, enabling users at higher levels to view, edit, and report on all data owned by or shared with users in lower roles.
4. Sharing Rules: The hierarchy can be utilized alongside sharing rules to extend additional record access across different branches of the hierarchy.
5. Territory Management: Salesforce's territory management feature can complement role hierarchies to assign access based on various criteria like geographical territories or product lines, especially in organizations with complex sales structures.
6. Customization: Administrators have the flexibility to customize the role hierarchy to align with the organization's structure, creating roles that mirror job functions and defining each role's access and visibility levels.
7. Impact on Reports and Dashboards: The role in the hierarchy also influences the data visible in reports and dashboards, ensuring that users only see the information they are permitted to view.

Sharing rules

Horizontal sharing. Sharing rules enable automatic record sharing with users per your defined criteria, maintaining the original record ownership. These rules, either criteria-based or ownership-based, can grant read or edit access to users in specified roles, public groups, or queues, facilitating horizontal access beyond the role hierarchy. Security → Sharing Settings

Public Groups

Create a public group with eastern and western sales team and inter share opportunity details. Users → Public groups

Use public groups in sharing settings

Manual Sharing

Manual sharing allows record owners or users with sufficient permissions to share individual records with other users, roles, or public groups on an ad-hoc basis. It's used to grant temporary or exception-based access when automated sharing rules don't cover specific needs.

Example

Alex, a sales representative, owns an opportunity record and needs to collaborate with Jordan, a product specialist outside the sales team. Using manual sharing, Alex shares the record with Jordan, granting read or edit access. This allows Jordan to assist with the deal without changing the record's ownership or broader access settings.

Queues

Queues in Salesforce are used to prioritize, distribute, and assign records to teams rather than individuals. They help manage and share workloads more efficiently, especially in cases where work items, like Leads, Cases, or Custom Objects, need to be worked on by different team members at different times. Users → Queues Here are some key points about queues:

1. Group Ownership: Queues allow records to be owned by a team instead of an individual, making them accessible to all members of the queue. This facilitates a collaborative approach to handling records.
2. Load Balancing: They help in evenly distributing work among team members, preventing any single person from being overwhelmed. Team members can pick items from the queue to work on, based on their capacity.
3. Increased Efficiency: By organizing records into queues, teams can prioritize work more effectively. Queues can be set up for different purposes or priority levels, helping teams to focus on the most urgent tasks first.
4. Flexible Assignment: Administrators can set up assignment rules that automatically route records to the appropriate queue based on specific criteria, ensuring that records are handled by the team best suited to deal with them.
5. Visibility and Access: Members of a queue can view and work on any item in the queue, but they don't have to be directly assigned to a record to work on it. This improves visibility across the team and ensures that no work item is overlooked.

Queues are particularly useful in customer service settings, where Cases might need to be addressed by the first available agent, or in sales environments, where Leads could be distributed among a team of salespeople. They streamline the process of managing records that require attention from multiple users or teams within an organization.

Digital Experience

Digital Experience refers to the integrated and interactive online environments designed to enhance user engagement and streamline service delivery across digital channels, such as websites and mobile apps. It aims to provide personalized, seamless interactions for customers, partners, and employees. In contexts like Salesforce, it's utilized for creating customer portals, partner portals, and employee communities to support sales, service, and community building, effectively driving engagement, self-service, and collaboration.

Dynamic Forms

Will demonstrate it by enabling a new field when Access card is deactivated.

Create a new field inactive date.

Select Edit page when inside an access card.

Enable the Inactive date visibility only when status is Inactive

Sandboxes

Sandbox types and templates: https://help.salesforce.com/s/articleView?id=sf.create_test_instance.htm&type=5

When to use a sandbox: https://help.salesforce.com/s/articleView?id=sf.deploy_sandboxes_intro.htm&type=5