System Validation Rules (SVR)
Before-Save RT Flows
Apex Before Triggers
Runs Most SVR Again and all Custom Validation Rules
Duplicate Rules
Save Record but does not Commit.
Apex After Triggers
Assignment Rules
Auto-Response Rules
workflow Rules
Escalation Rules
Process/Autolaunched Flows
After-Save RT Flows
Rollup Summary Fields
Commits All DML Operations to Database
Post-Commit Logic Like Email Send
Data Encription :
The process of applying a cryptographic function to data that results
in ciphertext,also known as encrypted data.
Salesforce Shield :
Salesforce Shield is a suite of products that gives you more control over your security and monitoring of sensitive data.
Platform Encription :
Platform encryption is Salesforce's product that gives you a point-and-click way to encrypt data at rest.
Platform encryption also allows you to select objects and fields that will be encrypted and what key and schema that will be used for the encryption.
Event monitoring :
Event monitoring is the counterpoint of that data security.
It enables you to monitor how that data is accessed in the platform and also taken out of that platform.
Within event monitoring, you can set up policies that will monitor specific criteria that has been met and proactively block or notify you when that data is being accessed.
Common Terms :
1.Data Encription keys :
Keys used to encrypt and decrypt data on the database.
2.Encription at Rest :
Data that is store on disk in an encrypted state.
3.Bring your Own Key :
When you're able to bring your own material to encryption.
Tenant Secret :
A piece of the encryption credential that is specific to your organization.
Note :
A tenant secret is an organization-specific secret used in conjunction with the master secret Salesforce has to generate the information needed to actually encrypt your data.
Shield Features :
1.Specify what fields & objects should be encrypted at rest.
2.Control over key permission
3.Bring your Own key.
4.Maintain most existing functionality with encryption*
5.Monitor key activities performed by your users.
Encription Schemes :
How does this encryption actually work?
Within Salesforce, they use two different types of algorithms.
1.Probabilistic schema
2.Deterministic schema
Probabilistic schema :
This is the default encryption of Salesforce, and this is where data is fully randomized and is the most secure option.
Each bit of data is turned into a fully random ciphertext string every time it's encrypted.
Encryption generally doesn't impact users who are authorized to view the data.
The exception is when logic is executed in the database or when encryption values are compared to strings or each other.
In these cases, because the data has been turned into a complete random, patternless string, filtering isn't possible.
It's recommended to use probabilistic on fields that are not going to be used for filtering or comparisons such as Social Security numbers,
phone numbers, etc.
Deterministic schema :
To be able to use filters when data is encrypted, we have to allow some type of pattern into our data.
Deterministic encryption uses a static initialization vector so that encryption data can be matched to a particular field value.
The system can't read that piece of data that's encrypted, but it does know how to retrieve the ciphertext that can stand for that piece of data.
The IV is unique to a given field in a given org and can be only decrypted with an org-specific encryption key.
Classic Encryption vs Shield Encryption :
Features Classic Encryption Shield Encryption
Encryption at Rest Y Y
Native Solution Y Y
Masking Y -
Encrypt Standard Fields - Y
Encrypt Custom Fields Only in special field Y
Encrypt Files - Y
Encrypt Search & Events - Y
Tenant secret :
Generate tenant secret is where Salesforce generates everything for you on your behalf and manages everything inside of a protected encrypted schema.
Bring your Own Key :
Bring your own key, however, is the opposite of that where you come to the table with more information and manage that yourself and give Salesforce enough information to be able to encrypt the data with your own key.
Tenant secret Type :
1.Data in Salesforce
2.Search Index
3.Event Bus
Note :
1.Probabilistic algorithm
Probabilistic algorithm is the default encryption of Salesforce.
This is where data is fully randomized and is the most secure option.
Each bit of data is turned into a fully randomized cipher text string every time it's encrypted.
Encryption within Salesforce generally doesn't impact users who are authorized to view the data.
The exceptions are when logic is executed in the database or when encryption values are compared to a string or to each other.
In these cases because the data has been turned into a random patternless string, filtering is not possible.
2.Deterministic algorithm
To be able to use filtering when data is encrypted, we have to allow some patterns into our data.
Deterministic encryption uses a static initialization vector, or also known as IV, so that encryption data can be matched to a particular field value.
The system can't read a piece of data that's been encrypted, but it does know how to retrieve the cipher text that stands for that piece of data.
The IV is unique for each given field in a given org and can only be decrypted with your org‑specific encryption key.
Within deterministic, there's two subtypes.
1.case-sensitive deterministic
2.case-insensitive deterministic
Note : This is very important when you're using deterministic that you choose this correctly. Otherwise, you will not get the results you're expecting within your filters.
Event Monitoring :
Event Monitoring within the Salesforce Platform is a granular detail view of how users and how the system is performing at an event level.
Every time an action is placed or a record has changed, what Salesforce called as an event is created within the platform.
Within the Salesforce Shield, you have a granular view of being able to monitor what's happening within the platform.
1.monitoring activity
2.Increase Adoption
3.Optimize Performance
within Event Monitoring, they have something called transaction security policies.
These are the policies that allow you to monitor or take actions on certain types of data interaction with the system.
1.Condition Builder
Condition Builder actually allows you to apply these rules with no code and with the interface.
2.Apex
The second is you can apply Apex to your transaction security policies to get a fine-grained way of controlling what notifications on what field and objects these Event Monitoring events are actually occurring.
Within the transaction security policy, there are four types of notifications.
1.Block
This block allows you to block a user's interaction completely when they've done a specific thing, such as try to load a report that has more records than you've allowed.
2.multi-factor authentication
The second is require a multi-factor authentication so that a user can prove that they are actually who they say they are.
3.Email Notification
A simple notification to your system admins or a group of individuals so you can understand what's happening in real time.
4.In-app notification
An In-app notification back to that system admin or a group of admins to make sure you understand what's happening.
Tableau CRM for Event Monitoring :
This platform gives sales, service, and the other core applications inside of CRM the ability to have advanced analytics and gives you the ability to slice and dice and create tables and visualizations that are above and beyond the standard reporting and dashboarding tools inside of core.
Benefits of the Event monitoring App
1.Easy Access
2.Visual
3.Filter & Facet
4.Shareability
To make components Internationalize you can use Internationalization Properties in Salesforce as shown below
import internationalizationPropertyName from @salesforce/i18n/internationalizationProperty;
The Property values will be returned for current user.
render lwc components outside of the shadow tree.
-> Enables global application styling
-> Ease 3rd party tools integration.
<template lwc:render-mode='light'>
<my-header>
<p>Hello World</p>
</my-header>
</template>
import { LightningElement } from 'lwc';
export default class LightDomApp extends LightningElement {
static renderMode = 'light'; // the default is 'shadow'
}
No Shadow root is created within the component.
Styles aren't scoped anymore.
Event's are retargeted.
<slot> elements aren't rendered in the DOM.
SFDX :
Salesforce Developer Experience(DX) is command line interface which provides tools
to manage data and metadata on salesforce environments.
DH: Dev Hub :
Organization feature which provides access to create and manage scratch orgs and
create and manage second generation package.
Package :
Bundled container of code and metadata which can be published on AppExchange or shared directly to subscribers.
2GMP :
Second-Generation managed package,created,developed and managed by SFDX CLI.
1GMP :
First-Generation managed package also known as classic package,created and managed from Packaging or Patch Orgs.
ISV :
Independent Software Vendor
The company, who releases the managed package.
NS :
Namespace is the prefix used by managed packages to isolate the metadata scope.
AppExchange :
Salesforce marketplace where packages can be found for installation or published by ISV.
Security Review :
Salesforce acknowledgement of managed package required for publishing on AppExchange.
NO :
Namespace Org, the org where namespace is registered.
PKO :
Packaging Org, the org where the package is created, built and registered.
PTO :
Patch org, the org where the patch version of package is developed and built.
Sbo :
Subscriber Org, the org where your subscriber clients install and use your package.
Sco :
Scratch Org i the source driven temporary disposable organization.
Push Upgrades :
Feature, which allows to push upgrades to the subscribers without their consent.
Package Version :
Package snapshot, which is defined by Major,Minor,Patch and Build Version.
How 2GMP are different from 1GMP ?
1. What is the source of truth ?
Source of truth : Packaging Org vs VCS
2.Who is the owner of package and metadata?
Owner of package and metadata : Pko vs DH+VCS.
3.How many packages may belong to an Org?
Number of Packages per org : 1 vs many
4.Where is the namespace registered?
namespace : PKO vs Namespace Org(NO) linked to DH.
5.How many packages may share namespace?
Number of package per NS : 1 vs many
6.Which are the options to share code?
Share code : global or @namespaceAccessible
ex :
@namespaceAccessible
public with sharing class JQ {
public class InvalidJSONQueryException extends Exception{}
@testVisible Map<String,Object> internalRepresentation;
@namespaceAccessible
public JQ(String data){
internalRepresentation=(Map<String,Object>)JSON.deserializeUntyped(data);
}
}
7.Can package create or uninstall be automated?
SFDX commands can be used to create or uninstall.
8.Is branching supported in package versioning?
Package versioning : linear vs branching
9.How patch versions can be created?
Patch versions: Patch Org vs VCS
which functionality is supported in 1 GMP but not in 2 GMP?
1.Components can't be deleted from packages.
2.Package versions can't be deprecated.
3.Apex versionProvider isn't supported.
4.A default language for labels in packages can't be specified.
Q)SFDX CLI command to create a new package version fails to be create because of exceeding limit Package2VersionCreates,
but developer needs to create a new version urgently for a client.What developer can do?
sfdx force:package:version:create --skipvalidation
Include --skipvalidation switch in the SFDX CLI command
Skip validation during package version creation;
you can't promote unvalidated package versions
However,unvalidated package verions have a separate limit which has
much higher value even for free developer orgs.The value of Package2VersionCreatesWithoutValidation is 500
While the value of Package2VersionCreates is 6.
Transaction Security is a feature that monitors Salesforce events in real time and applies actions and notifications based on rules you create. These rules, or policies, are applied against events in your org.(ex : our policy was to have no more than three active sessions per user.) You create policies for certain event combinations, and specify actions to take when those events occur.
Using Transaction Security Policy, you can define events to monitor and take action when that event happens.
Here are a few examples of the events that you can monitor.
1.You want to block and notify the administrator when somebody tries to export the ‘Contact’ information
2.You want to raise the session security to Two-Factor Authentication (2FA)
when a user tries to access Salesforce from two different IP Address within the last 24 hours
3.You want to block the access when someone tries to login from a particular country or from a particular operating system or browser
4.You want to block chatter posts containing particular keywords
5.You want to limit the concurrent number of sessions for a user or for an administrator
And when these events occur, you can take these actions
1.Block – Don’t let the user complete the request
2.Two-Factor Authentication – Step up the security and prompt the user to confirm identity by using two-factor authentication, such as the Salesforce Authenticator app
3.Freeze user – Prevent further logins into your org by the user.
4.End session – Prompt the user to end an existing session when the number of concurrent sessions a user is allowed to have is strictly limited.
Note :
Transaction Security is a framework that intercepts Salesforce events in real-time and applies appropriate actions and notifications based on the security policies you create.
Transaction Security Policy requires purchasing 'Salesforce Shield' or 'Salesforce Event Monitoring' add-on subscriptions.
Salesforce has an undocumented function called PICKLISTCOUNT. This function returns the number of selected values in a multi-select picklist. This function is helpful in validation rules.
Use case: Salesforce users with ABC profile can select only one value in a multi-select picklist field.
Validation Rule: PICKLISTCOUNT( MultiSelect_Picklist__c ) > 1 and $Profile.Name is ABC
