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 custom ...


14

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

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'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 creating ...


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

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 ...


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

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

Change: aff.npe5__Organization__c = accReference; To upsert accReference; aff.npe5__Organization__c = accReference.Id; accReference is an Account sObject, you need the ID. Same thing goes for the contact record. UPDATE: After careful investigation and getting the idea of what you're actually trying to do, you need to set the __r relationship ...


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

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 ...


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;


4

I will put 2 scenarios over here. I have created following csv file to upload data into my org, where External Site Id is External Id (unique is not selected) External Site key is External Id and also unique Scenario 1: By default, Batch size of dataloader is "200" So, if we perform upsert based on External Site Id or External Site Key, then in ...


4

The error message is phrased confusingly. It means there's three qualities that must be met for the field to be used: Must be an External Id Must be custom or standard Must be indexed This doesn't really express much more than that it has to be an External Id. For clearer discussion, see Upserting Records and the Upsert SOAP call. The nomenclature there ...


3

What about using saveResults to see whats happened? All depends on whether you want to check before insert that the data is valid; in your 'trivial' case looking at EID and whether it exists or not. Or whether you want to try it and see what the results is; this can be useful when validation rules, triggers, etc... may come into play. An example maybe:- Y ...


3

Just to make it clear, External Id and Unique are two completely independent configurations in a field. External Id performs two important actions on the underlying metadata of a field. First is creates an ExtId-to-Id map that is can be used for cross-object mapping during upsert operations and data imports. Second, it indexes the field. It does not force ...


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