Relationships In Salesforce

 

1. Lookup relationship

Parent record is not required when creating a child record as parent and child objects are loosely coupled.

Lookup relationship does not support roll-up summary field.

Lookup fields are not required on the page layout of the detail record but if you make them a required field, it is advised!

Standard object record can be on the detail side of a custom object in a lookup relationship.

By default record ownership of child records is not controlled by the parent.

Can have a child record without a parent.

Can have a maximum of 40 lookups on an object.

No cascade delete.

2. Master-detail relationship

Parent record is always required when creating a child record. That means parent and child object are strongly coupled.

Master detail relationship support roll-up summary field.

Parent record is required in order to save a child record.

Master-detail field is always required on the page layout of the detail record.

Standard object record cannot be a child.

The parent controls the record ownership of child records. The owner field is not available on the detail record in master-detail relationship queues, sharing rules and manual sharing is not possible for detail records as it requires the owner field.

You cannot have a child record without a parent.

You can have a maximum of two master details on an object.

Cascade delete.

 

3. Many-to-Many Relationships: 

If there is need to create the many-to-many relation then we need to use the Junction object in Salesforce. A junction Object is a type of custom object which allows linking two custom objects.

A junction Object in simple terms can be called a custom object with two master details fields.

Records of a particular object can connect with various records of different objects and vice versa.

 

4. Self-Relationship:

It means an Object is creating a relationship with itself. 

It creates a tree diagram of the objects.

 

5. Indirect lookup relationship:

This allows a relationship to be formed between a SF object and an external object. If your Salesforce org was the family, then the objects would be related but not in the same family. A great example of such is relating payment records to an account from an ERP system–the ERP system is external to Salesforce but the records are important. The way they relate is via an external ID to match the payments to the account.

External lookup relationships- allow a relationship to be formed between two external objects. Your two friends from outside of your group are now in a relationship. Maybe that ERP system links the payment records to a bank account.

6. Hierarchical Relationships:

This unique relationship can only be used on the user object and is designed to create a hierarchy of users. For example, it could be used to create a lookup field for the user object, which can be used to list the user’s manager.

Different MFA in Salesforce

 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

Back up your Salesforce sandbox before refreshing

 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

E𝐬𝐬𝐞𝐧𝐭𝐢𝐚𝐥 𝐆𝐢𝐭 𝐜𝐨𝐦𝐦𝐚𝐧𝐝𝐬

 𝐇𝐞𝐫𝐞 𝐚𝐫𝐞 𝐬𝐨𝐦𝐞 𝐞𝐬𝐬𝐞𝐧𝐭𝐢𝐚𝐥 𝐆𝐢𝐭 𝐜𝐨𝐦𝐦𝐚𝐧𝐝𝐬 𝐭𝐡𝐚𝐭 𝐞𝐯𝐞𝐫𝐲 𝐝𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫 𝐬𝐡𝐨𝐮𝐥𝐝 𝐤𝐧𝐨𝐰 𝐰𝐡𝐢𝐥𝐞 𝐮𝐬𝐢𝐧𝐠 𝐕𝐢𝐬𝐮𝐚𝐥 𝐒𝐭𝐮𝐝𝐢𝐨 𝐂𝐨𝐝𝐞 𝐟𝐨𝐫 𝐚 𝐩𝐫𝐨𝐣𝐞𝐜𝐭:

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

Recover a sandbox after accidental refresh/deletion

 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.

How to get IP Address of user in Salesforce apex?

 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 Channel and Field enrichment

 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.