Sharing and Visibility
Classic Encryption
128-bit Advanced Encryption. Mask Data. View Encrypted Data Permission Required to Read Encrypted Field Values. No support for standard fields. Classic encryption lets you protect only a special type of custom text field, which you create for that purpose. Dedicated custom field type, limited to 175 characters
Default Account Team
A Default Account Team is a predefined team that the Account Owner can set up, which can then be assigned to an Owner's accounts, when applicable. setup in personal settings and Team role can be selected.
Case Team
A case team is a team of users, contacts, or partner users, that work together on a case. For example, your case team may include a support rep, support manager, and a product manager. Every member of a case team has a role that he or she plays for the case, such as "Customer Contact" or "Case Manager." Roles determine access to the case, like Read Only or Read/Write access, and whether the member in the role is visible to users in the Customer Portal. Predefine case teams so that users can quickly add & provide record access to people with whom they work. Create assignment rules that add predefined teams to cases that match specific criteria, such as when cases originate from email-to-case.
Named Credentials
A named credential specifies the URL of a callout endpoint and its required authentication parameters in one definition. To simplify the setup of authenticated callouts, specify a named credential as the callout endpoint. If you instead specify a URL as the callout endpoint, you must register that URL in your org's remote site settings and handle the authentication yourself. For example, for an Apex callout, your code handles authentication, which can be less secure and especially complicated for OAuth implementations. Named credentials are supported in these types of callout definitions: -Apex callouts -External data sources of these types:Salesforce Connect: OData 2.0Salesforce Connect: OData 4.0Salesforce Connect: Custom (developed with the Apex Connector Framework) -External Services
sharing set
A sharing set grants site users access to any record associated with an account or contact that matches the user's account or contact. You can also grant access to records via access mapping in a sharing set. Access mappings support indirect lookups from the user and target record to the account or contact. For example, grant site users access to all cases related to an account that's identified on the users' contact records. Sharing sets apply across all site that a user is a member of. Record access granted to users via sharing sets isn't extended to their superiors in the role hierarchy.
Account Teams
Account Teams identify who is working on an account, by Team Roles, and the team members are displayed in Related Lists (on the Account Detail Page). Account Owners (or Admins) grant record-level access to account team members for the Account object, and Related Opportunities, Contacts, and/or Cases. (Read, Read/Write, or Private access; Not Create or Delete) Account Team Members' record access rolls up the role hierarchy (like standard sharing rules) Account Team Members still need Object-level access to view/edit records 'Account Team' is the Plural Label of the Object 'Account Team Member'
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.
Granular Locking
By default, the Lightning Platform platform locks the entire group membership table to protect data integrity when Salesforce makes changes to roles and groups. This locking makes it impossible to process group changes in multiple threads to increase throughput on updates. When the granular locking feature is enabled, the system employs additional logic to allow multiple updates to proceed simultaneously if there is no hierarchical or other relationship between the roles or groups involved in the updates. Customers can lessen the chance of locking errors by: • Scheduling separate group maintenance processes carefully so they don't overlap • Implementing retry logic in integrations and other automated group maintenance processes to recover from a failure to acquire a lock By default, granular locking is enabled The key advantages of granular locking are that: Groups that are in separate hierarchies are now able to be manipulated concurrently. Public groups and roles that do not include territories are no longer blocked by territory operations. Users can be added concurrently to territories and public groups. User provisioning can now occur in parallel.Portal user creation requires locks only if new portal roles are being created.Provisioning new portal users in existing accounts occurs concurrently. A single-long running process, such as a role delete, blocks only a small subset of operations
Scema class methods
CRUD isCreatable() isAccessible() IsUpdateable() isDeletable() object Schema.sObjectType.ObejectName.method() FLS Schema.sObjectType.ObjectName.fields.FieldName.Method() Schema.DescribeSObjectResult Schema.DescribeFieldResult
cyrpto class
Can be used for encryption in transit. Provides methods for creating digests, message authentication codes, and signatures, as well as encrypting and decrypting information. The methods in the Crypto class can be used for securing content in Lightning Platform, or for integrating with external services such as Google or Amazon WebServices (AWS).
start and stop test
Can be used to test governor limits. Limits are reset within the startTest() and stopTest()start and stop marks the point when the test starts and stops. everything before start should be used to initialize data.
Sharing Rules
Criteria or Owner based. Can share records with roles, roles and subordinates public groups, Territories, internal and external users You can use sharing rules only to grant wider access to data, not to restrict access. No Sharing rules for object with OWD of public read/write or controlled by parent You can assign either Read-Only or Read/Write acces
Cross-Site Scripting (XSS)
Cross-site scripting is a vulnerability that occurs when an attacker can insert unauthorized JavaScript, VBScript, HTML, or other active content into a web page viewed by other users. A malicious script inserted into a page in this manner can hijack the user's session, submit unauthorized transactions as the user, steal confidential information, or simply deface the page. Cross-site scripting is one of the most serious and most common attacks against web applications today. XSS allows malicious users to control the content and code on your site — something only you should be able to do!! JSENCODE -- performs string encoding within a Javascript String context. HTMLENCODE -- encodes all characters with the appropriate HTML character references so as to avoid interpretation of characters as markup. URLENCODE -- performs URI encoding (% style encoding) within a URL component context. JSINHTMLENCODE -- a convenience method that is equivalent to the composition of HTMLENCODE(JSENCODE(x
Custom Permissions
Custom permissions let you define access checks that can be assigned to users via permission sets or profiles, similar to how you assign user permissions and other access settings. For example, you can define access checks in Apex that make a button on a Visualforce page available only if a user has the appropriate custom permission.
field accessibility
From setup you can see who has access to the field by profile, page layout and record type.
Parent child skew
Happens if a records has more then 10k child records. parent-child data skew can cause serious performance problems in the maintenance of implicit sharing. You can split up accounts if they have more then 10k records or set the OWD to public read/ write or read
Making Realignment Smoother
Here are some specific suggestions. • If the time required to recalculate sharing is affecting your overall realignments schedule, consider using parallel recalculation of sharing rules. • Consider whether it is more efficient to: - Set aside specific maintenance windows - Defer organizational or sharing rule maintenance while processing your updates
Tuning Data Relationships and Updates for Performance
Here are some specific suggestions. • Use a Public Read Only or Read/Write organization-wide default sharing model for all non-confidential data. • To avoid creating implicit shares, configure child objects to be Controlled by Parent wherever this configuration meets security requirements. • Configure parent-child relationships with no more than 10,000 children to one parent record. • If you are encountering only occasional locking errors, see if the addition of retry logic is sufficient to solve the problem. • Sequence operations on parent and child objects by ParentID and ensure that different threads are operating on unique sets of records. • Tune your updates for maximum throughput by working with batch sizes, timeout values, the Bulk API, and other performance-optimizing techniques.
High-Volume Community or Site Users
High-volume community or site users in Experience Cloud are limited-access users intended for orgs that have thousands to millions of users. Unlike other users, high-volume community or site users don't have roles, which eliminates performance issues associated with role hierarchy calculations. High-volume users include the Customer Community, High Volume Customer Portal, and Authenticated Website license types.
Share Records
Include: ParentID, GrouporUserID, AccessLevel(read,edit) and Rowclause Standard objects: AccountShare Custom objects: object__share Exists for an object if OWD is not controlled by parent or public read write Manual shares written using Apex contains RowCause="Manual" by default. Only shares with this condition are removed when ownership changes. Apex Sharing Reason on the object must be created to enter a different RowCause.
Lightning Locker
Lightning Locker provides component isolation and security that allows code from many sources to execute and interact using safe, standard APIs and event mechanisms. Lightning Locker is enabled for all custom Lightning web components. In JavaScript, strict mode is enforced in modules but optional in regular programs. However, Lightning Locker implicitly enables JavaScript strict mode everywhere. You don't need to specify "use strict" in your code. JavaScript strict mode makes code more secure, robust, and supportable.
Territory Management Permissions
Manage Territories permissions- create and view territory states and View models. To create and edit assignment rules. Manage Territories permission and "view all" permission on Account is needed some features can only be accessed in setup. User will need permission to view setup.
External OWD
Must be equal or more restrictive than internal OWN of an object
Parallel Sharing Rule Recalculation
Normally, when an administrator creates, deletes, or edits a sharing rule, the recalculation required to make those changes take effect is processed synchronously. The same is also true when sharing rules are recalculated because of updates, such as a movement of roles or changes to the membership of the source group for rules. The calculation proceeds as a single job and typically completes within a few minutes. However, when a sharing rule change affects access rights to a very large amount of data, the recalculation can run longer. In addition, a recalculation job can get killed if it is running when Salesforce performs a scheduled feature or patch release. If you have experienced long-running processing times or jobs that were killed during realignments, consider using parallel sharing rule recalculation. When this feature is turned on, sharing rules are processed asynchronously and split into multiple simultaneous execution threads based on load. The processing is also more resilient; during a server restart, the jobs will be reinstated on the queue, and the process will continue when the server comes back online.
record sharing
OWD Role Territory Sharing rules Teams Manual sharing programmatic sharing
Implicit Sharing
Parent Records Read-only access to the parent account for a user with access to a child record. • Not used when sharing on the child is controlled by its parent • Expensive to maintain with many account children • When a user loses access to a child, Salesforce needs to check all other children to see if it can delete the implicit parent. Child records Access to child records for the owner of the parent account • Not used when sharing on the child is controlled by its parent • Controlled by child access settings for the account owner's role • Supports account sharing rules that grant child record access • Supports account team access based on team settings • When a user loses access to the parent, Salesforce needs to remove all the implicit children for that user.
Territory Management States
Planning, active and archived
Profiles
Read only user profile- Has read access to all the standard objects Minimum Access- included chatter internal user, Access Activities and Lighting console user. is the profile with the least access. Standard User- Create and edit access to most objects Standard platform- Core platform functionality access to Account and Contacts.
data access categories
Record access- OWD, Roles, sharing rules, Account/ chase teams, territory, manual sharing, apex sharing Object access- Profiles and permission sets. CRUD operations Field level security(FLS)- Read and edit access on fields from profiles and permission sets.
Assigned territory
Related list is only on account. There is a territory field on opportunity
system-defined groups
Salesforce also uses system-defined groups to implement hierarchies. During recalculation, Salesforce creates two types of system-defined groups, Role groups and RoleAndSubordinates groups, for every node in the role hierarchy. If the organization has external organization-wide defaults enabled, a third type of system-defined group, RoleAndInternalSubordinates, is created. System-defined groups support Territory Management in a similar way. For each territory, Salesforce creates a: Territory group, in which users who are assigned to the territory are direct members, while users assigned to territories higher in the hierarchy are indirect members TerritoryAndSubordinates group, in which users who are assigned to that territory or territories lower in the hierarchy are direct members, while users assigned to territories higher in that branch are indirect members modifying a queue or hierarchy causes Salesforce to recalculate its associated system-defined groups accordingly. Thus, the size and complexity of an organization's queues and hierarchies directly affect the duration of record access calculations.
Share Group
Share groups allow you to share records owned by high-volume Experience Cloud site users with authenticated internal and external users.
Territory Management
Territory Type - Territory types help you organize your territories by key characteristics important to your company. Every territory you create has a territory type. Territory types are used for organizing and creating territories only. They don't appear on territory model hierarchies. Territory- Territories organize groups of accounts and the Salesforce users who work with those accounts. Territories are created based on territory types. Territory Type Priority- Specifying and managing territory type priority information helps you choose the appropriate territory type for territories you create or edit. You create your own priority scheme. For example, 001 can indicate that a territory type is the highest priority or the lowest. Make sure that your scheme can scale as you add more territory types. Territory Model- A territory model represents a complete territory management system for your company. Modeling lets you create and preview multiple territory structures and different account and user assignments before you activate the model that works best. Territory Hierarchy- The territory hierarchy shows a model's territory structure and serves as its main interaction point. Start from the hierarchy to create, edit, and delete territories; run assignment rules for territories, and navigate to territory detail pages for more information. From the hierarchy, you can also assign territories to opportunities, run assignment rules at the model level, and activate or archive the model. Territory Model State- Territory model state indicates whether a territory is in the planning stage, in active use, or archived. You can have only one active territory model at
Group Maintenance Tables
These tables store membership data for every Salesforce group, including system-defined groups. System-defined groups are groups of users that Salesforce creates and manages internally to support various features and behaviors, such as queues. This type of management lets the data that supports queues and personal or public groups coexist in the same database tables, and unifies how Salesforce manages the data.
File Upload and Download Security Settings
To provide more security, control the way some file types are handled during upload and download.
SOQL Queries Using WITH SECURITY_ENFORCED
Use the WITH SECURITY_ENFORCED clause to enable field- and object-level security permissions checking for SOQL SELECT queries in Apex code, including subqueries and cross-object relationships. WITH SECURITY_ENFORCED applies field- and object-level security checks only to fields and objects referenced in SELECT or FROM SOQL clauses and not clauses like WHERE or ORDER BY. In other words, security is enforced on what the SOQL SELECT query returns, not on all the elements that go into running the query
stripInaccessible Method
Use the stripInaccessible method to enforce field- and object-level data protection. This method can be used to strip the fields and relationship fields from query and subquery results that the user can't access. The method can also be used to remove inaccessible sObject fields before DML operations to avoid exceptions and to sanitize sObjects that have been deserialized from an untrusted source.
Super User Access
When you enable super user access, you can grant super user access to partner users. Super user access allows partner users to view the data of other users with the same role in the partner role hierarchy or below them.
Shield Platform Encryption
With Shield Platform Encryption, you can encrypt a variety of widely used standard fields, along with some custom fields and many kinds of files. Shield Platform Encryption also supports person accounts, cases, search, approval processes, and other key Salesforce features. At rest encryption. 256-bit Advanced Encryption. Shield Platform Encryption relies on a unique tenant secret that you control and a master secret that's maintained by Salesforce. By default, we combine these secrets to create your unique data encryption key. You can also supply your own final data encryption key. We use your data encryption key to encrypt data that your users put into Salesforce, and to decrypt data when your authorized users need it.
Import related records with an external ID in Data Loader
You can use an External ID in place of a related record's Salesforce record ID to relate or associate records to each other as you process an Upsert operation in Data Loader. Similar to Salesforce record IDs, when a field is marked as an External ID, its values can be used to match and associate related records to one another. External IDs are commonly used to store unique record identifiers from external systems and allow for routinely loading data into Salesforce without having to prepare your import file with existing or related Salesforce record IDs each time.
Mass Reassign Opportunity Teams
add, remove or replace team members. There are search options. To transfer any records that you don't own, you need the required user permissions and read sharing access on the records. If you transfer closed opportunities, the opportunity team is maintained, regardless of this setting.
bulk upload of records
group records by parentID Use serial Bulk api
Lightning Security
hird-party Lightning components and apps operate in a special domain (lightning.force.com or lightning.com) that's shared with Salesforce-authored Lightning code -- in particular, setup.app, which controls many sensitive security settings. Visualforce applications, by contrast, are served from a different domain (force.com or visualforce.com) that isn't shared with Salesforce code. Because Lightning code shares the same origin as Salesforce-authored code, increased restrictions are placed on third-party Lightning code. These restrictions are enforced by Lightning Locker and a special Content Security Policy. There is also additional scrutiny in the AppExchange security review.
RunAs method
only enforces record sharing and can be used to test if user has access to the records. Cannot be used to verify FLS or system permissions can only be used in test classes Used to perform mixed DML operations
owner skew
owns more then 10k reocrds should not have a role in the hierarchy or should be at the top of the hierarchy in a sperate branch User should not be in public groups used in sharing rules
file security
prevent others from sharing and unsharing is an option on the file record.
SOQL injections
static queries with bind variables string.escapeSingleQuotes() typeCasting replace characters AllowListing
view all, modify all, view all data and modify all data
view all and modify all are on the object. Provided read and edit access to all records on the object regardless of sharing. View all data and modify all data provide access to all records. FLS is still needed to read or edit a field.
Apex record sharing enforcement
with sharing- takes into account if user has access to a record. without sharing (default)- runs in system contact. Access to all records. inherited sharing- runs as with sharing if not called from another class. inherits sharing if called from another class.
