Flow Designer Cannot Update Fields After Scheduled Job Updates Them on Domain-Separated Table

[RushikeshB65933]

Hi all,

We’re experiencing a strange issue after enabling Domain Separation on one of our custom tables.

Background:

• We have a Scheduled Job that updates a field called status on records in a custom domain-separated table.

• We also have a subflow in Flow Designer that updates the same status field during execution.

Issue:

After enabling domain separation, the following behavior is observed:

• If the Scheduled Job updates the status field, then Flow Designer appears to successfully update it, but within a second or so, the value reverts back to what was set by the Scheduled Job.

• No errors are thrown, and from Flow Designer’s perspective, the update is successful.

• Interestingly, other fields not touched by the Scheduled Job (e.g., notes) remain updated when modified by Flow Designer.

It appears that once a field is updated in a domain-separated table by the Scheduled Job, it somehow becomes "locked" or overwritten when Flow Designer tries to modify it — possibly due to domain context or record caching.

Our Observations:

• This may be happening because the Scheduled Job is still holding a reference to the original GlideRecord and performs a later update that overwrites changes made by the Flow.

• Alternatively, there may be domain context mismatches, where the Flow and Scheduled Job are operating in different domains and unintentionally stepping on each other’s updates.

Questions:

1. Has anyone encountered a similar issue with domain-separated tables?

2. Is this a known behavior where Scheduled Jobs can override Flow updates if both act on the same record?

3. Could this be related to GlideRecord reuse, domain caching, or execution timing?

4. Are there best practices to prevent these kinds of conflicts between Scheduled Jobs and Flow Designer in a domain-separated setup?

Any guidance, workarounds, or pointers to documentation would be greatly appreciated.

Thanks,