Extending Custom Objects and Applications : External Objects and Relationships

1. Configuring External Data Source and External Objects

Configuring external data sources and external objects In the previous lectures, we discussed the different types of relationships that we have in Salesforce. Starting from the lookup master detail many-to-many hierarchy, we discussed all these relationships. The only other two relationships that we are at liberty to discuss are external lookup and internal lookup. So now let's talk more about this external lookup and internal lookup. Both these external and internal lookup relationships, though they fall under the category of lookup relationships, are actually very different from the previous ones that we discussed. So when we say different, how are they different? They are different in such a way that they are linked to an external system, an external legacy system. In real time, that system can be SAP by Microsoft, Oracle by Oracle, or any other legacy system. So basically, we are integrating Salesforce with an external system. So when an external system is involved, we create these two types of relationships: the external lookup and the internal lookup.

So I think now we understand the difference between the other relationships and these two relationships in Salesforce. The other relationships that are lookup masterdetails for many to many self hierarchical all these relationships are within Salesforce.org. Let's quickly have a look at our data model for this master detail relationship lookup relationship, self relationship, hierarchical relationship the entire relationship was residing in Salesforce.org. The parent object, the child object, the everything was residing in Salesforce.org. There is no external system involved here, right? From the configuration to the data in the object fields, everything was residing inside Salesforce. However, when we integrate Salesforce with an external system, we have these two relationships: the external lookup relationship and the internal lookup relationship. So now when we talk about integrating Salesforce with an external system, let's understand how to make it happen. So whenever we want to connect and access data from legacy systems, Salesforce Connect comes into play. Salesforce Connect is an awesome feature that is given to us by Salesforce and is used for connecting Salesforce with other external legacy systems.

And as I mentioned before, in real time, that legacy system can be SAP, Microsoft, or Oracle, whichever system. And while we connect, we do not store any of the external data in our Salesforce.org. We basically store only the details of the link to the external data. So basically, what happens is that we start by configuring the external data source. So the external data source is a connection to the external database. So once we are done configuring the external data source, we create external objects. So what are external objects? External objects are pretty similar to our custom-created objects in Salesforce, except that they map to data that is stored outside of Salesforce.org. For instance, the student is a custom object, right? This instructor is a custom object, and departments are a custom object. So all these custom objects we created in Salesforce and the data that resides in them also reside in Salesforce. It's not elsewhere, right? But for external objects, the data as such do not reside in Salesforce. It resides in the external system. Salesforce only stores the link to the external data that is stored in the external system.

The external database may have many tables. So each external object that we create in Salesforcemaps corresponds to each table in the external system. Similarly, each of the external object fields maps to the table columns in the external system. So this is basically how the whole concept of an external data source and an external object works. Now that we have understood the concept, it's time for us to replicate and create this scenario in Salesforce. Go to the Salesforce application. Search for external objects. So under External Data Sources, we see no external data source here, and as for external objects, there are no such things defined. So to connect to an external system, we basically have to have an external data source connection to connect to the external database in real time, in a production environment. Basically, the legacy system would give us the details of the external data source for us to configure in Salesforce. But now we are only learning in our developer edition.

So as such, we do not have any real external system to work with. But for learners like us, Salesforce has very generously set up a sample external system so that we can better understand this concept better. So to configure and access that external system, Salesforce has created a complete trailhead for that. And that is a SalesforceConnect quick Start salesforce connect. So you can pretty easily pick this up. This whole trailhead unit is all about configuring the link to the external system, creating external objects, and thereby how to create external relationships. That is the indirect lookup and the external lookup. So for configuring this whole setup, we first need to install a package. So first click on the first module that is installing the schema package. This package basically creates all the necessary components for us to configure this setup. And once we install this package, we will be able to connect to this sample data source, which basically runs on Hiroku. So now let's go ahead and install the package. Install this package link. Choose this option. Install for all your users. Hit Install. It may take a few seconds. And now, like you see in the instruction, click the button to assign the customer IDs to account records. So set customer IDs. Customer IDs have been successfully assigned to account records. Click done. Perfect.

Now we can see that this package has been successfully installed. Now this is installed. The next step would be to create a data source connection. So let's go back to the trial head module. Go to the second module that is creating the external data source connection, and here it gives the instructions to copy this URL. We'll be using it in Salesforce now. So go to an external data source. Now let's create a new data source connection. So hit the new external data source and use the URL that we just copied. Give a name for the external data source here. Let's say we order DB. Or maybe you can give it some other name that makes more sense, like external order, external system, or something like that. And here in type, select the first option. And once you select the first option, you will have this URL field. So use the URL data that we just copied and leave the others as a default, then hit the Save button. Now click "validate" and "sync." So when we do that, Salesforce basically retrieves the schema from the external system. So, as we see here, these are the different tables that are available in the external system. As such, categories include order details, orders, payments, payment mechanisms, and all. And of these, for our learning purposes, we need the orders and the Order Detail table. So select these two tables and click Sync. Perfect.

So now Salesforce has retrieved the Orders and Order Details tables from the external system. and that's what we see here. Orders and order details are the two external objects. Now let's take a quick look at these external objects. Either you can click this Orders object, which will take you to that page, or you can search for external objects, and we should be able to see these two external objects out here. And as we know, though these objects look similar to the custom objects that we create in Salesforce, the main difference is that the data does not reside here. The data actually resides in the external system. And these external objects only hold the link to the data that is there in the external system. So click on the object to take a look at it. This is the object definition page for this external object. The main difference that we see here is the API name for all custom objects in Salesforce. We have underscore underscore C. However, this being an external object, it is underscore underscore X. So make a note of it.

And similar to the Standard Name field that we have in custom objects, here we have the externalID field, and there are some four custom fields that we have for this object. So this is the Orders object. Let's also have a look at the Order Details object (similarly underscore underscore X), which has a few custom fields and this standard field out here. Perfect. So now that we have these two external objects out here, I think the next best thing to do would be to create some tabs and expose these two objects in the UI. So let me quickly create a couple of tabs so that I can see these objects. Orders give a meaningful description. Don't skip that out and then give it for all profiles.

However, in real time, we'll be giving access only to the respective people. So an orderly stab is created. Similarly, create the order details tab. Don't skip the description. Perfect. So now we have created two tabs for the orders and the order details. So here you can see all the records that are there in the orders object, and you can see all the records that are there in the order details. Okay, it is displaying only the external ID and the URL. So what I'm going to do is create a new view for all external orders and include all the fields out here so we'll have a clear understanding and view of the data that is stored in this object. Similarly, do it for the order details as well. So this is our whole orders object. So we see here that there are many records in this order, and there is an external ID. There is one other ID. This ID is a Salesforce ID, actually. And there are other details. Customer ID, order date, order ID, and ship details These are the data that we actually pulled from the external system. Similarly, for order details. Also, we have a lot of data here.

This is the Salesforce ID. And this is the display URL. You know, basically this URL maps it to the external system, and we have an order ID here, order line, product quantity, and other data. Also, we have it perfectly configured. So now what have we done? We have configured an external datasource connection to an external system. Basically, this is a Hiroko system, the sample system given by Salesforce. And we have two external objects with us: the orders object and the order details object. So for this object, we have created two tabs so we can access those objects and see what data is in them. And we have also created two views with all the fields that are available, so we can have a better view of the data. So we have these two external objects with us now: the order object and the order detail object. Now that we have these two objects in place, the next step would be to create a relationship, that is, the external lookup relationship and the indirect lookup relationship, and how do we create that relationship and the other details we will discuss in the forthcoming session?

2. Experimenting on the External Objects

We understood how to do the configuration setup using the Salesforce package and for setting up a sample external system. Right now, let's dig more into that. In fact, this is completely optional. This is a way if you want, if you like to experiment more, and if you like to play around with the Hiroko app that we have, then maybe you can experiment with all these things.

However, again, this is completely optional, and you can very much skip this step and go ahead to the next lectures to understand more about the relationships. So, what we basically did was create an external data source connection and configure two objects, namely the orders and the order details. And we also have this URL for the Hiroko app. Generally, in real time, this URL is given by the external system so that we can connect to that system. All right, so now that we have this URL, what you can do is copy and paste it, and that will give you the overall structure of all the objects that are present in the Heroku app. As you can see, there are not only orders and order details; you also have subcategories for categories, payments, and payment mechanisms. So if you want to learn more about the other objects—or even the order and order details—what you can do is, after the URL, just type in "orders," and that will give you the data that is there in the Orders object.

This is the sample data that is preloaded in the Orders object. Similarly, for order details, this gives you the list of sample data that is stored in the order details object. If you have already worked with the XML data, then this should be pretty easy for you. For example, for this order, we have many records. Let's say, for example, one record. So this gives the details of one record. The customer ID is eight, and the order date is this. The order ID is 1004 and the ship date is this. This is a single order record. The other order record is this. The next ordered record is this. So this is how we generally read XML data. Similarly, you can also try for the order details object. So this gives all the details. So this is the order ID, orderline, product quantity, and unit price. So this forms one single order detail record. And similarly, this is the next record. This is the next record. So this is how we read XML data, and this is available in the link that Salesforce has given us. So just view all the objects that are available. We only experimented with the orders and the order details object to learn our relationships. However, there are other objects, such as payment mechanisms.

For example, let me select payments. There is detail in the payments object as well, and there are other objects as well. Payments and payment mechanisms have the same names, but I think payment and payment mechanisms are connected, and we have categories and subcategories. So I assume, with the naming convention, that these categories and subcategories might be connected. So just explore all these objects, and once you think that's what you want, you can just bring it out to the Salesforce UI to experiment more on that. What we can do is, in the external data source connection, we have already validated and synced these two objects: orders and order details. So hit validate and sync again, and it will show you all the other objects as well. So now what we can do is just try categories and subcategories or other objects that we did not select before and hit sync. So this way, just try to bring it out in the Salesforce UI and see how the data is. And then you can also try to create more relationships through an external lookup or an Internet lookup. Now this is a pure way of experimenting more with the data that is available to us. And as I mentioned before, this step is completely optional. You can very easily skip this and go ahead with the upcoming lectures. That is the external lookup and the indirect lookup relationship.

3. Indirect Lookup Relationship

Now that we are done with the configuration setup, it's time for us to understand more about the indirect lookup and the external lookup relationship. So what is the configuration setup that we did in the previous lecture? Basically, we used Salesforce Connect to establish a connection between Salesforce and the external system. So when we say "external system," we should know that it is not a real external system as such but a sample data source that runs on the Hiroko platform. So for that, we initially started off by installing a package that is given by Salesforce, and then we created a data source connection and thereby configured a couple of external objects. So the external objects are our orders and order details. So all the components that are involved in this entire configuration are provided by Salesforce through that package that we install. So we have successfully installed that, and we have those external objects ready to use.

So let's go on to the Salesforce UI. These are the couple of external objects that we used and that we are going to use, basically orders and order details. So using these external objects, we would be basically learning more about the indirect lookup and the external lookup relationship. So one important thing that we need to understand while using these external objects is the type of relationships that we have and the options that are available to us. So whenever we use external objects in our Salesforce.org, there are three different options that are available to us. What are all the three different options? That is the general lookup relationship that we generally create, and the other two are the indirect lookup and the external lookup relationship. So when the child object is an external object, then these three options are available to us. Because we know about indirect lookup and external lookup, both of these relationships fall under the category of lookup relationships. However, these two indirect lookups and external lookups are used whenever external objects are involved, right? So whenever a child object is an external object, then we have these options in front of us. So when we know that there are three options in front of us, we should know which option to use when, right?

So when our child object is an external object, we have the indirect lookup, or the external look up. And as you can see in the stable differentiation, when the child object is an external object and the parent object is a Salesforce standard or custom object, we can create a lookup or an indirect lookup relationship. And when the parent object is also an external object, then we create an external lookup relationship. So that differentiation is pretty clear, right? When the parent object is a Salesforce standard or custom object, we create either the general lookup relationship or the indirect lookup relationship. And if the parent object is an external object, then we create an external lookup relationship. So now again, we have to understand when we create a regular lookup and when we create an indirect lookup relationship. So, when the child object is an external object and the parent object is a standard, Salesforce standard, or custom object, then two options are available for lookup: indirect lookup and regular lookup.

When the external object contains a column that has a Salesforce record ID, then we create a regular lookup relationship. But when the external object does not store any Salesforce 18-digit record ID but instead has an external ID that can be mapped with our Salesforce standard or custom object, then we go for the second option, which is the indirect lookup relationship. In fact, this is a pretty common option, and this is a general scenario that is usually available even while doing real time projects. That is, a child object is an external object, and the parent object will be a standard Salesforce standard or custom object with no Salesforce 18-digit ID stored on the external object. So in that scenario, we'll go for the indirect lookup relationship. So this is the main concept behind the three options that are available to us. So let's learn more about this indirect lookup relationship. So, for our learning purpose, the option that we are going to consider is that we know that for a lookup relationship we need a parent object and a child object. So in our scenario, the parent object is going to be Accounts, which is a standard Salesforce object, and the child object will be Orders. That is one of the external objects that we have, along with the matching field and parent. So what is this matching field?

We have to understand more about this part. So let's go to the Salesforce UI. We have the Orders object, which is the external object, which will also be the child object. In our case, let me also add the standard Accounts object. Perfect. So now we have the parent object, which is Accounts, and the child object, which is Orders. And now we are going to create an indirect lookup relationship between the external object orders and the parent object accounts. So for connecting these orders and accounts, there needs to be some common data, right? Definitely. Because whenever we establish a connection, there needs to be some common data with which we can map. So basically, in every parent object, there has to be a field that stores the data using which we can connect to the child object. So in our scenario, the field that we would be using is the Customer ID field. So this Customer ID field now, first we have to understand how this Customer ID field got created, right? So this customer ID field got created as part of the package installation that we did.

So, while we installed the package automatically, this field got created in the Accounts object. But in real time, what happens is that whenever we map a particular object to an external system or external object, we create this external field. And the external field is always unique in most of the scenarios because that is a unique field that we use for mapping to the records, right? So that will be unique. And we also say that it is an external ID field. Meaning this particular field will be used for mapping the data with the external object or the external system. So that is why we mark it as externalID and we also mark it as unique. So every order record would map itself to the account record based on this value, Customer ID." So some sample data has also been loaded into this Customer ID field. So go to Accounts—sorry, go to all Accounts—and you must be able to see the Customer ID field. If not, you can just pull it from the layout. It might not be visible on the layout, so just pull it onto the page layout. So you can see the customer ID has some value. That's two here.

So all orders with that ID, two, would automatically get mapped to this particular account. But now, as we have not created any relationship between accounts and orders, they are just two independent objects. You can see there are no related lists like orders. We have not created any relationships as such; we just have the data. So what would basically happen after we create a relationship is what we are talking about. So, in the Orders object, we have a field called "Customer ID," right? So this customer ID would be mapped with a customer ID that we have in the accounts object. This customer ID in orders has a customer ID, which would be mapped to a customer ID in accounts. So when we say the customer ID is 2, all the orders with the customer ID of 2 will be mapped to this particular account. So this is the purpose of the externalID field that we have in Salesforce. This external ID field we specifically use whenever we establish a connection between the Salesforce standard or custom object with an external object. In our case, it is accounting. And we saw we have a field here that is a customer ID, which is a unique external ID field.

And in that field, we use it to map to our external object. That is an order. But now that we have not created any relationship between account and orders, they are just two individual objects that we have with no relationship. But now we are going to create an indirect lookup relationship between account and orders. So, going back to the basics, we are going to create an indirect lookup relationship. The parent object would be Accounts. The child object would be "Orders." So just the regular way of creating a lookup relationship So what do we do when we want to create a lookup relationship? We go to the child object, and then we create a relationship field, right? So here our child object is "orders." So go to the fields, and this is the customer ID field. Basically, this field is what we would be using for mapping it to the parent object. But now that we have not established a relationship, they are just independent objects. You can see the data type is "number." So what we are going to do is change the data type from number to a relationship field.

So hit Edit and change the field type. And now, as you can see, the child object is the external object, so we have all three options available to us. That is a lookup relationship. external lookup and indirect lookup. And now we are going to choose indirect lookup. And why are we choosing indirect? Lookup. Because basically we choose indirect lookup whenever the child object is an external object, And the parent object is a Salesforce standard or custom object. And the Salesforce 18-digit ID is not stored on the external object. So in our case, the external object orders do not store any Salesforce record IDs there, right? So we go for the indirect lookup relationship. So you're going back? Choose indirect. Lookup. Hit next. Related to the meaning of the parent object, that is, Accounts, is the target field. So basically, it is asking for the matching field. Which field should I pick from the Accounts object? Which field should I compare in the Accounts object?

So this is the only external ID field that we have in the Accounts object. In case you have multiple external ID fields, all the ID fields will be listed here. And you need to choose the right one. So here we are choosing this Customer ID field. Fill in the details here, give a meaningful description, and name the child-parent relationship name. For now, let me make it visible for all profiles. However, in real time, that would basically depend on the people who should have access to that data. The related list label Let me make it "external orders" so that will be more applicable here. Hit Save. Perfect. So now what we have done is change an existing field, that is, customer ID, which was a number field, to a relationship field that is an indirect lookup relationship. So how the relationship basically works is that all orders with the customer ID mapped to the customer ID of accounts would be tagged together. In our scenario, data was already existing in the Accounts object, and for that field, Customer ID and related data were also existing in the Orders object.

So now that we have created a relationship, automatically, a relationship has been created between orders and accounts. How do we see that? First, let's go to the Orders object. This is the ordering record that we have now. You can see this "Customer ID" field, which was a number field. It is now a relationship field. So when we click on that field, it automatically takes us to the account to which it is tagged to.If you see this customer ID, it is six. So all orders with a customer ID of 6 have been mapped to the account with a customer ID of 6. And now that we have created a relationship, this related list is also available here. So we can see all the orders that are mapped to this account. So what is a common factor? All these orders have the customer ID of six, and this account also has the customer ID of six. Similarly, all the other orders that we have also got mapped to the irrespective account, for example, twelve. So it automatically takes me to the account that is a parent account, and we should be able to see all the orders that are tagged to this account. So all the orders have the customer ID of twelve, and this particular account also has a customer ID as well. So that is the reason we say that the parent field has to be a unique field.

Because whenever the order record, which is a child record, searches for a parent, there should definitely be only one account with that particular Customer ID, right? So that is why the external ID fields are generally marked as unique, so as to avoid any sort of data duplication. So this is how we create an indirect lookup relationship. So, to repeat for our indirect lookup relationship, the parent object is an account, and the child object is orders. So whenever we create a relationship field, we always create it on the child object. But initially in this setup, basically the field was already present with preloaded data. So basically, we converted the number data type to a relationship field that is an indirect lookup. And when we created the relationship, we also configured the page layout,the related list labels, and everything. So once we are done creating the relationship in the accounts object, which is a parent object, one related list was created, which is external orders, that list down all the orders that are tagged to that particular account. The other important thing to note here is the external ID that is created on the parent object, which connects the Salesforce object and the external object. So this is how we create an indirect lookup relationship between a Salesforce standard or custom object and any external object.

4. External Lookup Relationship3

Let's understand what the external lookup relationship is. So, in the previous lecture, we talked about the general lookup relationship, the indirect lookup relationship, and also when we use that kind of relationship. So now let's talk more about the external lookup relationship. So, as already understood, let me just do a quick recap. So when the child object is an external object and the parent object is a Salesforce standard or custom object, we go for either the general lookup relationship or the indirect lookup relationship.

So we go for the general lookup relationship in case the child external object stores the digit Sales Force record ID in that. But if it is not, and if it is connected through a different common ID, then we go for the indirect lookup relationship. That is why the matching field in the parent is a Salesforce Record ID here, whereas the matching field here is some other custom, unique external ID field. In our case, that was the customer ID field. That was a unique external ID field in AccountsObject that we used to establish that relationship. Perfect. So all that aside, now coming to the external lookup relationship, we create the external lookup relationship when the child object is an external object and the parent is also an external object. So in that case, we create an external lookup relationship. So, with that information on the basics, let's go to the Salesforce UI and take a look at our external objects. So these are the two external objects—orders and order details—that we have.

So now what we are going to do is create a relationship between this order and the order details object. So the functional usage of these two objects is like, say, when we place an order online, we order a book, we order a pen, and we order a shirt. So these are all the order details. The pen is an order detail; the shirt is an order detail; and the book is an order detail. And all these are grouped under one single heading. all right? So basically, that is just a sample that I gave for you to understand how the order object and order details object work. So one order record can have multiple order detail records. So in one order, we place three different items, and those form the order details. So the order record is a parent object, and the order details are a child object. So that is why we form an external type of relationship where the parent and the child are both external objects. In our case, the parent object would be orders, the child object would be order details, and both are external objects. And here, the matching field and parent would be the standard external ID field that we have in every external object. Let's quickly go to the orders object and have a look at the fields. As you can see, every external object would have the standard external ID field. It wouldn't have the name field that we have in the standard or custom Salesforce objects. It would have an external ID field.

So this external ID field would be the field that the child record looks up to map to a parent object record. That is why, in an external lookup, the matching field in parent would be the standard external ID field. So now let's create an externallookup relationship between these two objects. That's orders and order details. And as we already know, external lookup is also a kind of lookup relationship. just that it involves external objects. So for creating an external lookup relationship, what we do is go to the child object. In our case, it is order details, and then we would create the relationship field. And as we did for the internal lookup relationship, we already have that field in place. That is the order ID field. just that it is a number field with preloaded data. We'll be converting this field to an external lookup relationship field. So hit edit Change the field type. Choose an external lookup relationship. And now it is asking for the parent object. We only have two external objects. Choose orders. Fill in the details here. Please give a meaningful description. Let me make it visible for all profiles and then add the related list label.

Let me make them external order details. Perfect. So now what we have done is create a relationship field in the order details that is a child object. So what should ideally be created in the child object? Whenever we navigate to any record, we have this order ID field. Previously, this order ID field was just a number. But now that it is a relationship field, when you click that field, it automatically takes you to the parent record. That is an order. And how are these two objects connected? That is the order and the order details through the standard external ID field. That standard external ID field is not visible here in the UI. So let's quickly add it to the layout. Just drag and drop. Perfect. The external ID is here. So all the order details with the orderID matching with the external ID of the parent object, which is orders, automatically get mapped. So every order list has all the external order details within it. So here is the related list that gets created as soon as we create our external lookup relationship. This is how we use the standard external field, the standard external ID field on the parent object, to map both the parent and the child object. And this is how we create a lookup relationship between two external objects.

5. Considerations while using External Objects

Now that we have understood in detail the various types of relationships—the external lookup and the internal lookup—how do we do the configuration and set up? Let's take a quick look at some of the considerations and restrictions that we have when using external objects in Salesforce. In the first, only lookup, external lookup, and indirect lookup relationships are available for the external objects. No other relationship types are supported. We are well aware of this. All right, so whenever we create relationships on external objects, we can only create the lookup, the external lookup, or the indirect lookup. For example, we can consider these external object orders. So what we did was basically change the field type, right? So now if I try to change the field type, I can see only the lookup, external lookup, and indirect lookup. These are the three options that are available.

You cannot create a master detail menu for many and all using external objects. Depending upon the availability of the external system, related lists of child external objects may load slowly when users view the parent record detail pages. Perfect. So, as we have established a connection between Salesforceand the legacy system, and if the parent object is a standard object in our case, like accounts, So whenever we go for a particular parent record, we see all the related child records in the related list. So one of the considerations that we need to have is that this related list may load a little slower than usual depending upon the availability of the external system. Okay, moving on. Cascade delete isn't available for external object relationships. We know that cascade delete automatically happens in master detail relationships and does not happen in lookup relationships. However, in lookup relationships, there is an option wherein we can request a cascade delete but for that, we have to contact sales for support. But here, for external objects, that option is not available. Moving on.

With external lookup and indirect lookup relationships, the parent record appears as a clickable link in the relationship field of the child record. So our first relationship that we created was an indirect lookup. Accounts was the parent object, and Orders was the child object. So whenever you pick a child record, the parent record appears as a clickable link. So basically, you can click on that particular record, and that will automatically take you to the parent record. But what we have to note here is that if a user who is accessing the child record does not have access to the parent record, then in that case it will not appear as a clickable link. So that it goes, it says if the child record is viewed by a user who does not have access to the parent record, the parent record appears in the relationship field as just plain text instead of a link. The next consideration is that lookup filters are not available for external lookup and relationship fields. So when we created a lookup relationship field, the option of lookup filters wasn't available.

Let's again recall the field that we created in the Orders object. This was the relationship field that we created. So let me hit the Edit button, and now you can see all the details that are available for us to edit, and we can see that the Lookup filter is not available. But when we generally create a lookup relationship, a regular lookup relationship, or a master detail, then we have that option of lookup filters, wherein we can filter out the values of the lookup. But that option to look up filters is not available when we use external objects. Only objects that have a custom field with an external idea and unique attributes are available as parent objects in an indirect lookup relationship. If you do not see a desired object when you create an indirect lookup, then there is a possibility that there are no unique external ID fields available in that object. meaning whenever we create an indirect lookup relationship. So in our case, we created an indirect lookup relationship between accounts and orders. So for that, we basically converted this particular field to an indirect lookup field. So let me hit the edit button and let me change the field type. And here it is already an indirect look up. I'm just like, "I want to show you." So indirect lookup and step two are to choose the related object. Basically, the parent object In this scenario, if you see only account listed out here, right? There are no other standard or custom objects listed here. Why? Because only objects that have a unique externalID field will be listed out here, So of all the objects that we have in our.org account, this is the only one that has this custom, unique external ID field.

So that is the reason only one account is listed here. So for experimenting more, what you can do is create the unique external ID fields in other custom or standard objects, and you can see if it is getting listed out here and in real time. If your desired object is not appearing, the chances are that there are unique external ID fields available in that object. So first create that field, and then create this relationship. Perfect. So this is one of the catchy ones, and then about case sensitivity. So if the external column name is case-sensitive, make sure that the parent object's custom field is also marked case sensitive. We know that the option of case-sensitivity is available to us in Salesforce. So make sure that you make the parent object fields also extra case sensitive because, basically, those two fields will be matched and the value from the child object that is an external object will be matched with this external ID field in the parent object. So if one is case sensitive, also make the other one case sensitive so that the matching will happen. So these are some of the considerations that we need to keep in mind while using external objects in Salesforce.

Prepared by Top Experts, the top IT Trainers ensure that when it comes to your IT exam prep and you can count on ExamSnap Administration Essentials for Experienced Admin certification video training course that goes in line with the corresponding Salesforce ADM-211 exam dumps, study guide, and practice test questions & answers.