function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
HowardKatzHowardKatz 

Would be nice to have multiple external Id fields for AppExchange apps

I am currently using a custom external id field in order to upsert external data into Salesforce from my AppExchange application.  Unfortunately, since my application is a partner app, there is no guarantee that the one external id field isn't already being used by a given company.  So either I take the chance that it isn't being used, or I roll my own upsert with creates and updates, which requires more requests and is slower.

I'm guessing that from within the Salesforce database, an external id field has an associated database index (and the resulting tablespace), so perhaps the rationale of having only one external id is to limit the tablespace.  This would be a shame, because the overhead of the additional requests is a drag for both Salesforce and its partners.

Any chance this will be changed in the future?

-Howard
adamgadamg
I think there are two seperate issues here (I think); first, external ID isn't a constrained unique field.  Second, the fact that you are using a partner app doesn't effect the properties/behaviors of the data types - you never need to worry about what other orgs may be doing.
HowardKatzHowardKatz
Here's a specific scenario to clarify:

Company X is a Salesforce customer and to integrate with one of their in house applications, they've created a custom Activity field and marked it as an external id.

Then, Company X browses the AppExchange and finds my product and wants to use it.  However, my product requires them to declare a custom external id field on the Activity object (because we use it for upsert).

Because there is a currently a limit of one external id field per object, it won't work; they won't be able to declare a second custom external id field because of the current limit of one.  And unfortunately, upsert returns an error if you try to use a field which is not an external id.
JesterJester
In your case, looks like the customer will have to choose.  They could always disable the external id, and then upsert your activities.  Your problem won't ever be solved though, as long as there is a limit.   If the limit is two, what if they are already using both.  Then you need 3.  And so on and so forth. 

I imagine that there is some technical magicalness going on in the back end that prevents limitless external ids.  And from a business perspective, it makes sense to have 1, because if it is meant to be a unique identifier in an external system,  you only need one "universal" id. 

Though we should push em for 2.  Because it's even.
HowardKatzHowardKatz
No doubt the "Technical Magicalness" (TM) is that there is an index in the SF database for the external id.  This means tablespace for the index, which means disk space which means...

I agree with you that only one external id is needed if you're integrating SF with you existing IT infrastructure, but with the AppExchange, you can have n different systems, each with its own id.

I see two ways around this: Either make separate create and update requests, or maintain the "external id" mapping in my application.  From an EAI perspective, it would be nice if SF could serve to centralize the ids in various AppExchange apps- perhaps it will evolve into that (with a proper SSO, centralized provisionning, etc).  We can always hope.
adamgadamg
Ok, I understand the issue now, thanks.

Here is my recommendation; have your code do describe to see if your field exists on activities and is external ID; if is does, you upsert, if it doesn't, fall back to update/insert.  My guess is that not many folks are using external ID on activities (as opposed to contact/account, which its primary use case), so you may be in luck.  Not ideal, but may work.

I'll ask around to see what the status of multiple external IDs is - I'm not familar enough with the design/contraints to know.
benjasikbenjasik
You can have more external ids, but customer support needs to enable this feature.