[QUESTION] - onDataRetrieved add‑on updates externalId, but lookup columns still reference the old values

[parsam97]

Hi SFDMU team,

What I’m trying to do

• Give every record a fresh, sandbox‑unique DataMigrationId__c before export/import.
• I wrote a custom add‑on that runs in the earliest lifecycle event, onDataRetrieved, and sets DataMigrationId__c to a new value on every record that does not have it or has a non-unique value.

Minimal example

• Two objects:
  • A__c (parent) – externalId = DataMigrationId__c
  • B__c (child) – lookup to A__c, externalId = DataMigrationId__c
• Source org values
  • A__c: 00001, 00002
  • B__c: 000b1, 000b2

Add‑on code (simplified):

async onExecute() {
  const job = this.runtime.service.getPluginJob();

  job.tasks.forEach(task => {
    task.sourceTaskData.records.forEach(rec => {
      rec["DataMigrationId__c"] = "placeholder";   // or a UUID
    });
  });
}

What happens

1. I run

   sfdx sfdmu:run -u sourceOrg -s csvfile
   

2. Generated A__c.csv shows "placeholder" – good.
3. B__c.csv still contains the original lookup values (A__r.DataMigrationId__c = 00001 / 00002).
   SFDMU seems to have cached or resolved the relationship before my add‑on changed the IDs.

What I expected

B__c.csv should reference "placeholder" (the updated externalId) so the parent/child link survives the import.

Question

• Is there a lifecycle event later than onDataRetrieved where changing a field that is used as externalId will also refresh the lookup columns in dependent objects?
• Or is relationship mapping fixed at an earlier stage and cannot be altered by an add‑on?
• Any recommended approach for generating new external IDs that stay consistent across related objects?

My goal is to keep the logic out of Apex triggers and let SFDMU handle everything while keeping the CSVs in Git.

Thanks for any guidance!

[hknokh]

Hello, @parsam97

Thank you for reaching out.
I will do my best to assist you as quickly as possible and will keep you updated on my progress.

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]

Hello,

Thank you for reaching out.
And sorry for the very late response after the issue was accidentally closed by the bot.

According to our Support Policy, only runtime errors—critical failures that occur during code execution and stop the program with messages such as “Uncaught TypeError” or “ReferenceError”—will be handled.

Currently, we do not handle help inquiries, incorrect functionality, or other non-crashing behavior. Please consult our Help Center or developer forums.

Please review our Support Policy at: https://help.sfdmu.com/full-documentation/additional-information/support_policy

Thank you for your understanding and cooperation.

Regards.