[FEATURE REQUEST] - Source vs Target External IDs

[PotSeht]

As a consultant, sometimes, when migrating customer data, there are either:

• No easily configurable External ID (for example, any child record that has an Autonumbered Name, where the parent also has an autonumbered name). Sometimes, you need to combine 3-5 different field values in order to build a truly unique key.
• Duplicates, where you cannot rely on the External ID defined being unique.

In some cases, I spend a fair bit of time having to identify and validate external IDs across many objects.

What I am proposing
Allow the ability to set Source vs Target External ID

As the Salesforce Record ID is truly unique in a source system, in some cases, I would much prefer to simply create a field on the target object, such as Migration_Key__c which would populate the record ID from the source org. The source system would rely on Id, and the target system would rely on Migration_Key__c.

Benefits

• Guarantees uniqueness across a dataset.
• Removes the complexity for external IDs in cases where building a unique external ID is not straight forward.

I am not fluent with TS, but would upskill and investigate writing this code myself, if you agree with adding this type of feature. Please let me know

[PotSeht]

Personally, I think it just makes sense to just allow setting of the Target side. This is because the source side, its not necessary given if we use the Record ID value, it is guaranteed unique. I cant think of a use case where you'd set differing external ID fields between source and target, because in that case, you would just rely on the source field.

[hknokh]

Hello, @PotSeht

Thank you for your feature request.
I will review it as soon as possible and provide updates as they become available.

Cheers

[github-actions]

This case has been marked as 'to-be-closed', since it has no activity for the 3 days.
It will be automatically closed in another 3 days of inactivity.

[github-actions]

This case has been closed, since it has no activity for the last 6 days. Feel free to reopen it, if you need more help.

[hknokh]

Hi,

Thank you for your contribution and the idea.

I’m adding this ticket to my roadmap for review at a later time, but please note there's no guarantee of implementation. I’ll keep you updated on any progress.

Regards.

[hknokh]

Hello,

Thank you for the suggestion.
I reviewed this case again.
At this time, implementing this feature is not feasible.

Reasons:

• The current externalId matching path uses one shared externalId contract across source and target in core flows such as record matching, upsert resolution, parent lookup linking, and composite externalId handling. Adding separate source and target externalId contracts would require broad cross-module changes and has high regression risk for existing migration behavior.
• Current functionality already covers most key-identification scenarios with composite external IDs and field mapping, while the known upsert limitation for mapped externalId names is documented and expected behavior today.
• Given current priorities, the implementation cost and validation scope are too high compared to expected impact.

If additional opportunity appears, I will revisit this case.
Thank you for understanding.

Best regards