We’re rewarding the question askers & reputations are being recalculated! Read more.
16

First, I highly recommend you read Bob's post for yourself. He's a much better writer than I am. Also, Salesforce documents this behavior in Relating Records by Using an External ID and Creating Parent and Child Records in a Single Statement Using Foreign Keys. To relate a record to its parent record with an external ID, the parent object must have a ...


13

Unfortunately you are right, using external IDs can lead to multiple matches during upsert operations.. taken from the documentation on Upserting examples: If the key is matched multiple times, then an error is generated and the object record is neither inserted or updated. So in answer to your question, yes you will get an error! Frustrating as it is. ...


10

You need to use the external if in the update call upsert flist Externald__c; For part two of your question, seeing that you want to relate the parent and child foo records you can t do it the way you were trying but I also think that you need to create the parent separately, however I think you either need to build a map to successfully relate the parent ...


8

Yes, using the data loader you can look up to another record based on an external ID. However, note that the ID should be flagged as unique too. This would also be doable via the API.


8

TL;DR If you are querying on an indexed custom External Id field, the only way you will give yourself non-selective query errors is by including null in your filter collection. You should avoid that regardless of the percentage of indexed values which are null Scenario 1 (All External Ids Populated) I started out with a table containing ~110k records. ...


7

You can use external ids to relate records that you are loading with the parent (i.e. records that they look up to - both Master Detail and Lookup) Accounts and Contacts is a great example. If you have Accounts loaded in, and they have an External Id Field say External_Id__c, then you can use this field to relate the Contacts you are loading to the Accounts ...


7

The user with whose context the test is running should have View All Data permission on TOrg__c or should have system permission of View all Records if the external Id is not unique. This permission is required so that duplicate records are not inserted while performing an UPSERT operation because the user is not able to see the record which has same ...


7

Assuming all the objects are already created, you could create a file that simply contains the one field definition you need, copy it, and deploy it. I'd say this task is probably easiest with Ant, but you could conceivably do it in an IDE as well. First, set up your package.xml: <?xml version="1.0" encoding="UTF-8"?> <Package xmlns="http://soap....


6

It does not have to be defined on the child and the parent. The child will have the actual account relationship field (e.g., Account__c on your custom object, or whatever your child record is). The Account will have the External ID that identifies it. The child load file will then have the external ID in it instead of the Account ID. This is one reason ...


6

It's true. Auto-number fields can be external IDs. I can think of at least one good reason. Salesforce.com might be the source of record without explicitly using salesforce.com ID values, which may be case insensitive depending on the other application, which can cause unwanted complications. Using an auto-number field avoids case-sensitive ID values that ...


6

Yes, those fields can have a NULL value but wont serve the purpose. External ID: This is a field that usually references an ID from another (external) system. For instance, if the customer has an Oracle Financials system that they will be linking with salesforce.com, it may be easier for them to be able to refer to the Oracle ID of account records from ...


6

This approach only works with different types. Take a look at Creating Parent and Child Records in a Single Statement Using Foreign Keys (emphasis mine): You can use external ID fields as foreign keys to create parent and child records of different sObject types in a single step instead of creating the parent record first, querying its ID, and then ...


5

Upsert depends upon the value of External ID fields being unique. If you choose to not make External ID unique, you cannot leverage this feature. This means that you would need to leverage external logic in order to perform the upsert operations. Either clean up your data, or use external logic. One potential solution could be to write a trigger to eliminate ...


5

Unfortunately, the polymorphic nature of ParentId renders External ID values useless (it only works on concrete relationships). Instead, you'll have to match the External ID values to the appropriate Parent ID through Excel or some other mechanism. This is fairly trivial, and you could probably even write an Excel macro that can perform this task (or any ...


5

When you get to what appears to be the end of the New Upsert Wizard, you will be prompted to "Map & Finish" on a button. Click that, and you'll see a screen where you complete your mapping (see pic below). Any related objects that have available External Id fields will appear at the top of the right hand list of object fields with a "+" to expand. ...


5

An ID is comprised of four parts: AAA BBB CCCCCCCCC DDD | | | | | | | \----- Case Insensitive Modifier (optional) | | \--------------- Auto-Number Base62 (server-unique) | \------------------- Origin Server (1=na1, etc) \----------------------- Entity Key (001=Account, etc) Of all this metadata, there's nothing significant ...


5

If integration APIs are creating the record with its unique external ID, the field does not need to be required. Just make it read-only in the layout. If you are concerned that users may create these records manually, set up the permissions so that only the integration API process (and maybe admins) have permission to create this object type.


5

Here's an option I can think of.. not a straight forward one thou.. (and there might be an easier option that i can't think of) Create a Custom Setting (hierarchy) with a Number field and start with a base value Create a New Custom Number Field on Opportunity and set its default value to read from the Custom Setting field. You can mark the field as Read-...


5

When you create a new Auto number field you get an option to make this field an External field. You need to check that checkbox.


4

Ok so the solution can be found in the documentation. Apparently you can reference to the "User" object like this: { "Source_XML__c": "[Some xml-string]", "Salesman__r" : { "IPN__c" : "db02236" }, "IPN__c": "db02236" } Source: SalesForce documentation


4

Take a look here: http://blogs.developerforce.com/engineering/2012/02/cascade-insert-with-external-id-fields.html I think you can do something like this: Account a = new Account(); a.External_Id__c = ‘myExtId’; Lead.Account__r = a;


4

I don't think this is possible without a level of complication, no. Depending on where your list of external ids exist, you could do this using the developer console, and Execute Anonymous Apex.. Load a list of the records you want based on the external id criteria(/data) and then delete said list. Alternatively, a method we have used before with the ...


4

Just tried THIS: in the dev console Account a = New Account(Name='test', AccountNumber='1234'); upsert a accountNumber; and got this message: Invalid field for upsert, must be an External Id custom or standard indexed field: accountNumber So I guess the answer is NO.


4

Maybe it the one of the following situations, 1) If you integrate your Salesforce with more than one external systems. That situation, one database supports one format and the other supports another format. 2) Oracle and other databases use different AutoNumber strategy.


4

In short, no, there isn't a direct API to determine such limits. You shouldn't make any assumptions at all about the number of External ID fields that may be available. Even though the usual default is 7, there might be exceptions, for example, if Salesforce granted a higher limit upon request, or if the upgrade scripts missed an org and they're still at 3, ...


4

You need to specify the key field - in this case, it is just using Id as the key. So your upsert should look something like: upsert a AssetID__c;


3

This looks like an internal Salesforce.com error, possibly the result of a bug. Notice the similar error encountered by another user in 2009 at this link: similar error I would contact Salesforce.com support directly to get this resolved. When or if you get an answer for them, please add the answer here as well.


3

Short answer: no, a lookup is related to a record in your org, and a polymorphic lookup is not different Long answer: Polymorphic lookups are Salesforce internal lookups to any kind of object, or a restricted list of objects. You can configure which records you can relate to events, checking the field "Track Activities" in a custom object for example. The ...


3

Yes, definitely. What are you trying to accomplish? In the scenario I am assuming based on your question, you have two truly unique but nullable fields, already populated on existing records, and you wish to create a third field that is an external ID for the purposes of indexing and uniquely identifying records with at least one of the two previously ...


3

CORRECTIONS The above solution did not work as you cannot convert a Managed package back to Beta if it was already released. And the version where we added the relevant field was released years before I contacted support. So no, the only thing you can do is either deprecated and remove the old field from the package and migrate it to a new packaged ...


Only top voted, non community-wiki answers of a minimum length are eligible