Multi-factor authentication (MFA) is a security feature that requires users to provide multiple forms of identification before accessing their Salesforce accounts.
There are several ways to implement MFA in Salesforce:
✅ Salesforce Authenticator
✅ Time-Based One-Time Password (TOTP)
✅ Universal Second Factor (U2F)
✅ SMS or Email verification
✅ Biometric authentication
1.Clone the sandbox
By far, the easiest way to back up your sandbox is to clone it. By cloning the sandbox, you create a new one with the exact same metadata as the current one.
Then, you can refresh your original sandbox.
After the original sandbox is refreshed, use a change set to move the changes from the cloned sandbox over to the original one.
2.Download a change set with sfdx
Another way to back up your Salesforce sandbox before refreshing it is to create an outbound change set and add all the changes you want to back up.
Once the change set is created, you can download its contents with sfdx (really).
Here's the command you need to run
sfdx force:source:retrieve -n [MyChangeSetName]
This is a good option if you are not interested in backing up the entire sandbox but just some metadata that is part of a project or feature you are working on.
Once the sandbox is refreshed, connect to it with sfdx, and run the following command to deploy the change set contents back to it
sfdx force:source:deploy -p [folder-where-changeset-was-retrieved]
3.Download the entire sandbox with sfdx
The third way is similar to the previous one, except here, we retrieve the entire metadata of your Sandbox.
-> sfdx command that allows you to retrieve all the metadata in the org without having to know beforehand what metadata types you have,
which fields to include, etc.
First, we'll run a command to generate a package.xml file that includes every single metadata item in your org
sfdx force source manifest create --fromorg [your org alias] --manifestname=allMetadata --outputdir manifest
Once you run this command, you'll see allMetadata.xml file under the manifest directory:
You'll notice this file lists all the metadata in your org!
The next step is simply to right-click the file, and select "Retrieve source in manifest from Org"
And that's it! Now all your Salesforce metadata is in the sfdx project.
Note :
That said, I got some feedback from the community that this command times out if your org is huge.
I also found that some of the metadata that is retrieved cannot be deployed back.
For this reason, I recommend options 1 and 2 first.
4.Use an appexchange app for metadata backup
The final way to back up your sandbox is to use an app from the Salesforce appexchange.
ex: Salto
𝐇𝐞𝐫𝐞 𝐚𝐫𝐞 𝐬𝐨𝐦𝐞 𝐞𝐬𝐬𝐞𝐧𝐭𝐢𝐚𝐥 𝐆𝐢𝐭 𝐜𝐨𝐦𝐦𝐚𝐧𝐝𝐬 𝐭𝐡𝐚𝐭 𝐞𝐯𝐞𝐫𝐲 𝐝𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫 𝐬𝐡𝐨𝐮𝐥𝐝 𝐤𝐧𝐨𝐰 𝐰𝐡𝐢𝐥𝐞 𝐮𝐬𝐢𝐧𝐠 𝐕𝐢𝐬𝐮𝐚𝐥 𝐒𝐭𝐮𝐝𝐢𝐨 𝐂𝐨𝐝𝐞 𝐟𝐨𝐫 𝐚 𝐩𝐫𝐨𝐣𝐞𝐜𝐭:
1️.𝐆𝐢𝐭 𝐜𝐥𝐨𝐧𝐞 - to clone a remote repository to your local machine.
2️.𝐆𝐢𝐭 𝐚𝐝𝐝 - to add changes to the stage area.
3️.𝐆𝐢𝐭 𝐜𝐨𝐦𝐦𝐢𝐭 - to commit the changes to the local repository.
4️.𝐆𝐢𝐭 𝐩𝐮𝐬𝐡 - to push the changes to the remote repository.
5️.𝐆𝐢𝐭 𝐩𝐮𝐥𝐥 - to fetch and merge changes from the remote repository.
6️.𝐆𝐢𝐭 𝐝𝐢𝐟𝐟 - to view the difference between the changes.
7️.𝐆𝐢𝐭 𝐬𝐭𝐚𝐬𝐡- to temporarily save changes that are not ready to be committed.
8️.𝐆𝐢𝐭 𝐛𝐫𝐚𝐧𝐜𝐡 - to create or list branches.
9️.𝐆𝐢𝐭 𝐜𝐡𝐞𝐜𝐤𝐨𝐮𝐭 - to switch between branches.
10.𝐆𝐢𝐭 𝐦𝐞𝐫𝐠𝐞 - to merge one branch into another.
These commands can be executed either in the terminal or using the Git lens extension in Visual Studio Code
Salesforce actually can revert this change for up to 72 hours after the refresh/deletion.
I have run into this exact issue, and SF support was able to revert the sandbox back.
You just need to make sure you contact them within 72 hours.
Although our Customer Success Rep told us that they can usually get it for up to a week,
they only commit to 72 hours, so I wouldn't push my luck.
Salesforce confirmed they can recover a refreshed Sandbox within the first 24-48 hours of Activation.
After this timeframe, their automated systems will permanently delete the Sandbox.
Use this code in apex class:
String ipAddress = ApexPages.currentPage().getHeaders().get('X-Salesforce-SIP');
'True-Client-IP' - when the request is coming via the caching integration.
'X-Salesforce-SIP' - when the request is not via caching integration (sandbox, developer edition orgs) or via the secure Url.
ex :
public class GetIPController {
public String ipAddress {get; set;}
//Constructor
public GetIPController(){
// True-Client-IP has the value when the request is coming via the caching integration.
ipAddress = ApexPages.currentPage().getHeaders().get('True-Client-IP');
// X-Salesforce-SIP has the value when no caching integration or via secure URL.
if (ipAddress == '' || ipAddress == null) {
ipAddress = ApexPages.currentPage().getHeaders().get('X-Salesforce-SIP');
}
// get IP address when no caching (sandbox, dev, secure urls)
if (ipAddress == '' || ipAddress == null) {
ipAddress = ApexPages.currentPage().getHeaders().get('X-Forwarded-For');
}
//get IP address from standard header if proxy in use
//ipAddress = ApexPages.currentPage().getHeaders().get('True-Client-IP');
}
}
Custom channels are useful when there are multiple subscribers and each subscriber
receives change events for a different set of objects.
Instead of subscribing to the default ChangeEvents channel,your app can create and subscribe to a custom channel
that receives only the events for the objects you're interested in.
you can create one or more custom channels to group change events on the channel
that your app subscribe to.
In addition to grouping change events, you can use a custom channel with event
enrichment to isolate sending enriched fields in change events on a specific channel.
How to create Custom Channel?
We can use tooling or Metadata Api to create a PlatfromEventChannel which represents a
custom channel.
Afterthat, we can create PlatformEventChannelMember to have multiple objects events associated to that channel.
we will provide the enriched fields in the JSON request body.
Custom channels allow you to group multiple events together, as well as work with filters and field enrichment.
Custom channels help you scale operations with event filtering and change event field enrichment.
ex :
1.create a custom channel
<INSTANCE_URL>/services/data/v57.0/tooling/sobjects/PlatformEventChannel
Use the following JSON for the request body.
{
"FullName": "Accounts_and_Contacts_CDC__chn",
"Metadata": {
"channelType": "data",
"label": "Custom Channel for Accounts and Contacts"
}
}
Note :
--> FullName is the API name of the custom channel. It must end with __chn.
--> channeType sets the type of members that the channel supports.
Its value is either data for Change Data Capture events or event for platform events.
2.Once you’ve declared a custom channel, you can add members to it by calling this endpoint
<INSTANCE_URL>/services/data/v57.0/tooling/sobjects/PlatformEventChannelMember
Use the following JSON for the request body.
{
"FullName": "Accounts_and_Contacts_CDC_chn_AccountChangeEvent",
"Metadata": {
"eventChannel": "Accounts_and_Contacts_CDC__chn",
"selectedEntity": "AccountChangeEvent"
}
}
Note :
--> FullName is the API name of the custom channel member. You are free to name it the way you want,
but a convention is to concatenate the channel API name with the selected entity name.
Note that this field does not allow double underscores, so you must modify the channel API name suffix to simply _chn instead of __chn.
--> eventChannel maps to the channel API name (the value of the FullName attribute of the previous request).
--> selectedEntity maps to a platform event or change event API name. In this example,
AccountChangeEvent is the standard change event for the Account object.
