Resumen Sharing and Visibility

Levels of Data Access

You can control which users have access to which data in your whole org, a specific object,
a specific field, or an individual record.

Organization
For your whole org, you can maintain a list of authorized users, set password policies, and
limit logins to certain hours and locations.

Objects
Access to object-level data is the simplest thing to control. By setting permissions on a
particular type of object, you can prevent a group of users from creating, viewing, editing, or
deleting any records of that object. For example, you can use object permissions to ensure
that interviewers can view positions and job applications but not edit or delete them. You can
use profiles to manage the objects that users can access and the permissions they have for
each object. You can also use permission sets and permission set groups to extend access
and permissions without modifying users' profiles.

Fields
You can restrict access to certain fields, even if a user has access to the object. For
example, you can make the salary field in a position object invisible to interviewers but
visible to hiring managers and recruiters.

Records
You can allow particular users to view an object, but then restrict the individual object
records they're allowed to see. For example, an interviewer can see and edit her own
reviews, but not the reviews of other interviewers. You can manage record-level access in
these four ways.

● Organization-wide defaults specify the default level of access users have to

each others’ records. You use org-wide sharing settings to lock down your
data to the most restrictive level, and then use the other record-level security
and sharing tools to selectively give access to other users.
● Role hierarchies give access for users higher in the hierarchy to all records
owned by users below them in the hierarchy. Role hierarchies don’t have to
match your organization chart exactly. Instead, each role in the hierarchy
should represent a level of data access that a user or group of users needs.
● Sharing rules are automatic exceptions to organization-wide defaults for
particular groups of users, so they can get to records they don’t own or can’t
normally see. Sharing rules, like role hierarchies, are only used to give
additional users access to records. They can’t be stricter than your
organization-wide default settings.
● Manual sharing allows owners of particular records to share them with other
users. Although manual sharing isn’t automated like org-wide sharing
settings, role hierarchies, or sharing rules, it can be useful in some situations,
 such as when a recruiter going on vacation needs to temporarily assign
ownership of a job application to someone else.

Profiles provide default settings for each user, such as default record type, IP range,
and so on. Salesforce recommends using the Minimum Access - Salesforce profile
as a best practice for assignment to users. Each user has only one profile.

Permission Sets are collections of settings and permissions. Profiles allow users to
perform some tasks, but permission sets allow additional tasks (tasks not enabled by
profiles). For example, you can add permissions to create and customize list views,
activate contracts, or any number of other permissions.

Permission Set Groups bundle permission sets together. Users assigned to a

permission set group receive the combined permissions of all the permission sets in
the group. Permission set groups correspond to the job functions of users.

Muting lets you customize a permission set group by muting (disabling) selected
permissions in it. To mute a permission, you add the permission to a muting
permission set in the selected permission set group. When you mute a permission in
a permission set group, the muting affects only users assigned to the permission set
group, not users assigned directly to a permission set outside of the permission set
group. So, muting offers you great flexibility when you design your permissions
model.
Login Hours: if they are in the middle of a session it will log out. And if they are not within
hours they will be denied access.
Transfer only available on Lead and Cases
Org Wide Defaults never grants more access that what the user has through
profile/permissions.
Role Hierarchy can not grant more access that what an user has for the profile permission.

Implementation Notes
 ● Encrypted fields are encrypted with 128-bit master keys and use the Advanced
Encryption Standard (AES) algorithm. You can archive, delete, and import your
master encryption key. To enable master encryption key management, contact
Salesforce.
● You can use encrypted fields in email templates but the value is always masked
regardless of whether you have the View Encrypted Data permission.
● If you have the View Encrypted Data permission and you grant login access to
another user, the user can see encrypted fields in plain text.
● Only users with the View Encrypted Data permission can clone the value of an
encrypted field when cloning that record.
● Only the <apex:outputField> component supports presenting encrypted fields in
Visualforce pages.

Restrictions
Encrypted text fields:
● Can’t be unique, have an external ID, or have default values.
● Aren’t available for mapping leads to other objects.
● Are limited to 175 characters because of the encryption algorithm.
● Aren’t available for use in filters such as list views, reports, roll-up summary fields,
and rule filters.
● Can’t be used to define report criteria, but they can be included in report results.
● Aren’t searchable, but they can be included in search results.
● Aren’t available for Connect Offline, Salesforce for Outlook, lead conversion,
workflow rule criteria or formulas, formula fields, outbound messages, default values,
and Web-to-Lead and Web-to-Case forms.

Best Practices
● Encrypted fields are editable regardless of whether the user has the View Encrypted
Data permission. Use validation rules, field-level security settings, or page layout
settings to prevent users from editing encrypted fields.
● You can still validate the values of encrypted fields using validation rules or Apex.
Both work regardless of whether the user has the View Encrypted Data permission.
● To view encrypted data unmasked in the debug log, the user must also have the
View Encrypted Data in the service that Apex requests originate from. These
requests can include Apex Web services, triggers, workflows, inline Visualforce
pages (a page embedded in a page layout), and Visualforce email templates.
● Existing custom fields can’t be converted into encrypted fields nor can encrypted
fields be converted into another data type. To encrypt the values of an existing
(unencrypted) field, export the data, create an encrypted custom field to store that
data, and import that data into the new encrypted field.
● Mask Type isn’t an input mask that ensures the data matches the Mask Type. Use
validation rules to ensure that the data entered matches the mask type selected.
● Use encrypted custom fields only when government regulations require it because
they involve more processing and have search-related limitations.
Campos del equipo de cuentas
Los datos de miembro del equipo de cuentas se almacenan en campos estándar. El formato de
página de un usuario determina qué campos son visibles y el acceso de un usuario a la cuenta
determina qué campos son modificables.

Built-in Sharing Behavior

Salesforce provides implicit sharing between accounts and child records (opportunities, cases,
and contacts), and for various groups of site and portal users.

Built-in sharing behaviors apply only to standard relationships.

Sharing between accounts and child records

● Access to a parent account—If you have access to an account’s child record, you have
implicit Read Only access to that account.
● Access to child records—If you have access to a parent account, you have access to the
associated child records. The account owner's role determines the level of access to
child records.
Sharing behavior for site or portal users
● Account and contact access—An account’s portal or site user has Read Only access to
the parent account and to all of the account’s contacts.
● Management access to data owned by Service Cloud portal users—Since Service Cloud
portal users don't have roles, portal account owners can't access their data via the role
hierarchy. To grant them access to this data, you can add account owners to the portal’s
share group where the Service Cloud portal users are working. This step provides access
to all data owned by Service Cloud portal users in that portal.
● Case access—If a portal or site user is a contact on a case, then the user has Read and
Write access on the case.
Group membership operations and sharing recalculation
Simple operations such as changing a user’s role, moving a role to another branch in the
hierarchy, or changing a site or portal account’s owner can trigger a recalculation of sharing
rules. Salesforce must check access to user’s data for people who are above the user’s new or
old role in the hierarchy, and either add or remove shares to any affected records.

Implicit Sharing
The sharing capabilities of the Lightning Platform include a wide variety of features
that administrators can use to explicitly grant access to data for individuals and
groups. In addition to these more familiar functions, there are a number of sharing
behaviors that are built into Salesforce applications. This kind of sharing is called
implicit because it’s not configured by administrators; it’s defined and maintained by
the system to support collaboration among members of sales teams, customer
service representatives, and clients or customers.
This table describes the different kinds of implicit sharing built into Salesforce
applications and the record access that each kind provides.

Experience Cloud User Licenses

The following licenses are used for external users:
What are login-based licenses?
Each community license can be either a member-based license or a login-based license. To use a
login-based license, you first purchase a specific number of logins to be used every month. External
users associated with that license consume one login each time they log into a site. However, logging
in multiple times during the same day still only consumes one login and, once logged in, switching
between sites doesn’t consume extra logins. This type of login is referred to as a daily unique login.

MEMBER-BASED LICENSES LOGIN-BASED LICENSES

Customer Community Customer Community Login

Customer Community Plus Customer Community Plus Login

Partner Community Partner Community Login

External Apps External Apps Login

Channel Account Channel Account Login

The ratio between the number of monthly logins you purchase and the number of login licenses that
are provisioned in your org is 1–20. For example, if you purchase 1,000 monthly logins, then 20,000
login licenses are provisioned in your org.
Focus On Force

Permission Set Groups

Instead of assigning multiple permission sets to a user, a Permission Set Group can be created which
groups permission sets together and then assigned to the user.

● Multiple permission set groups can also be assigned to a single user.

● Permissions in a permission set group can be disabled or “muted” by adding a Muting Permission
Set
● Only one muting permission set is allowed in a permission set group

The ‘Minimum Access’ profile has very limited access to objects and records, and the ‘Standard User’
profile allows creating and editing most major types of records. This is why they cannot be used for specific
object and field-level requirements. In order to create a custom profile, an existing profile can be cloned.

The ‘Minimum Access - Salesforce’ profile it is a least-privilege profile that grants only a few permissions,
namely, Access Activities, Chatter Internal User, Lightning Console User, and View Help Link.

Reports Permissions
1.‘Run Reports’ in the User Permissions section - This permission allows the user to view the reports tab,
run reports, and view dashboards based on reports.

2. ‘Create and Customize Reports’ in the 'System Permissions' section - A user with this permission can
create, edit, and delete reports. If the Enhanced Profile User Interface is disabled, then this permission
appears in the ‘Administrative Permissions’ section within the profile.

3. ‘Report Builder’ in the User Permissions section - This permission gives a user access to the Report
Builder interface which can be used to create, edit, and delete reports.

4. ‘Report Builder (Lightning Experience)’ in the Administrative Permissions section - This permission gives
a user access to the Report Builder interface in Lightning Experience.
Manual Sharing
Sometimes, granting access to one record includes access to all its associated records. For
example, if you grant another user access to an account, the user automatically has access to all
the opportunities and cases associated with that account.

To grant access to a record, you must be one of the following users.

● The record owner

● A user in a role above the owner in the hierarchy (if your organization’s sharing settings
control access through hierarchies)
● Any user granted Full Access to the record
● An administrator
If a user transfers ownership of a record, Salesforce deletes any manual shares created by the
original record owner, which can cause users to lose access. When account ownership is
transferred, manual shares created by the original account owner on child records, such as
opportunities and cases, are also deleted.

When the parent account for a contact associated with a portal or community user changes,
manual shares for custom object records that were shared with the portal or community user are
deleted.

Account Teams
’can be enabled in ‘Account Team Settings’ to allow users to collaborate on accounts. For this
requirement, team roles can be created for the two sales reps and the product manager. The
Account Team related list can be added to the Account page layout. The sales rep who owns the
account record can add, edit, and delete team members from the Account Team related list. He
can add the other sales rep and the product manager to the account team and specify their
access level to the account.

To edit or delete an account team member, one must be the account owner, above the owner in
the role hierarchy, any user granted full access to the record, or an admin.

Opportunity Teams
‘Team Selling’ can be enabled in ‘Opportunity Team Settings’ to turn on ‘Opportunity Teams’ in
Salesforce, which allow users to collaborate on opportunities and share them with other users.
Every opportunity team member has a role in that opportunity.

Multiple roles can be created by navigating to ‘Team Roles’ in Setup. Opportunity teams share
roles with account teams. The ‘Opportunity Team’ related list can be added to the Opportunity
page layout to allow sales reps to add members such as sales managers to their opportunity
team. The access level of the team members can be specified while defining the team.

Once a default team has been defined, it can be added by the sales rep to any opportunity
owned by him. While defining a default opportunity team, it is possible to specify whether it
should be automatically added to opportunities that the user creates or any open opportunities
that are transferred to the user. Any open opportunity teams can also be updated with the default
team members.

The default team can be added to the opportunities using the ‘Add Default Team’ button by an
administrator, owner, or any user above the owner in the role hierarchy. In order to add, remove,
or replace team members every three months, it is possible to use the ‘Mass Reassign
Opportunity Teams’ wizard on the home page of the Opportunities tab.

It is possible for the owner of an opportunity, system administrator, a user with the ‘Transfer
Records’ permission, or a user above the owner in the role hierarchy to change the ownership of
the opportunity.

Case Teams

A case team is a group of people that work together to solve cases. After setting up case team
roles, predefined case teams can be created for the support groups in Setup. The access level of
‘Read/Write’ can be selected while creating the case team roles.
The ‘Case Team’ related list can be added to the Case page layout, and a predefined case team
can be added to a particular case by an administrator based on the criteria specified by the
support director.

In addition, a list view can be created for the support reps based on the same criteria in Lightning
Experience. The list view can be filtered by ‘My case teams’ or ‘Queue owned cases’ by
accessing the Filters panel on the right.

The ‘Manage Public List Views’ permission allows a user to create, edit, or delete public list
views.

Report folder ‘Manager’ access level allows a user to give others access to a report or dashboard
folder.

To allow the support managers to give access to a report or dashboard folder, the ‘Manage
Reports in Public Folders’ permission and the ‘Manage Dashboards in Public Folders’ permission
can be selected in their custom profile.

The sales agents can be given the ‘View Reports in Public Folders’ permission in their profile to
allow them to view reports in the public folder created by the Business Intelligence Officer.
A sharing set can be created by navigating to Digital Experiences | Settings in Setup.

‘Partner Super User Access’ can be enabled by navigating to Digital Experiences | Settings in
Setup. Super user access can be granted to partner users to give them access to data owned by
other partner users who have the same role or a role below them.
Enterprise Territory Management can be enabled in Setup by navigating to Territory Settings. For
the company’s primary requirement, a new territory model can be created by selecting ‘Territory
Models’ in Setup. A new territory model is always created in ‘Planning’ state. The territory
hierarchy of the model can be viewed to create territories for the regions and states that should
be part of the hierarchy.

The default access levels for accounts and related records can be selected in Settings. If
required, it is also possible to customize the label of ‘Territory’ and ‘Territories’ on end-user
pages on the ‘Rename Tabs and Labels’ page in Setup. Account-Territory Assignment Rules can
be created and then run to automate the assigning account records to the appropriate territory.

When the territory model is in ‘Active’ state, assignment rules can be run to assign accounts to

territories automatically according to the rules .

Collaborative Forecasts can be used for forecasting since it works with Enterprise Territory
Management. When using Collaborative Forecasts with Enterprise Territory Management, it is
possible to enable territory forecasts by using the forecast type of ‘Opportunity Revenue by
Territory’.

The role-based forecasts hierarchy is based on the user role hierarchy and specifies which users
are forecast managers. The territory-based forecasts hierarchy is based on the territory hierarchy
and specifies which territories have forecast managers.

Territory types can be utilized to organize territories by key characteristics. Every territory has a
territory type. For example, a territory type called ‘US Sales’ can be created, and territories can
be created from that type for states or regions in the United States. Territory types do not appear
on territory model hierarchies.

Filter-based opportunity territory assignment can be enabled and configured to assign territories
to opportunities based on the filter logic defined in an Apex class. The Apex class can be
specified in Settings. An option can be selected to automatically run the filter-based opportunity
territory assignment job when opportunities are created.

It is also possible to manually assign a territory to an opportunity by using the ‘Territory’ field on
the opportunity record. Users who have full access to the opportunity’s account, such as the
owner of the account, can assign any territory from the active model to the opportunity. Users
who do not have full access can assign only a territory that is also assigned to the opportunity’s
account.

The ‘Assigned Territories’ related list can be added to the Account page layout to allow users to
see which territory is assigned to a particular account record. The ‘Users in Assigned territories’
related list can be added to allow viewing all users assigned to the territory that is assigned to a
particular account. The ‘Territory’ field on an opportunity record should allow viewing the territory
that is assigned to the opportunity.