3776272 - After connector execution, records are counted as 'Updated Entities' when there was no update to them in the file

When some connectors run and consume their input files, a number gets at the 'Updated Entities' column, when looking at the execution's results page. Is this expected, even when the input file consumed by the connector contained no updates to the entities?

• Sample affected connectors: Item Connector, Organization Connector;
• Sample non-affected connectors: Jod Code Connector.

SAP SuccessFactors Learning

1. Log into HCM >
2. Considering an input file that contains only a few columns, and the data present in it has no updates to the entities >
3. Navigate to Learning Administration > System Administration > Connectors > for a sample affected connector, such as Organization Connector >
4. Click on 'View Results' >
5. For the execution successfully that consumed the input file and where the entities were processed, click on 'View Details' >
6. At the 'Connector Run Details' page, look at the Activity Summary section >
7. Notice that the column 'Updated Entities' shows a high value and the column 'Unchanged Entities' displays "0" >
8. This seems to indicate that all organization records present in the input file were touched by the connector during this execution >
9. When checking the entities in the database, is possible to see that the 'Last Updated Timestamp' information has been updates as well, to match the connector's execution.

As per Engineering team, the affected connectors (such as Organization Connector) compare the incoming file data against the existing database records to determine if any changes need to be applied. This comparison is done across all fields — not just the ones present in the input file.

When the input file contains only a subset of columns (e.g., ORG_ID, ORG_DESC), the other fields that are absent from the file (like DMN_ID or EMAIL_ADDR) are treated as blank/null during the delta comparison. If the database already holds a value for those fields, the comparison detects a mismatch and marks the record as "Updated" — even though no intentional change was made.

For example, let's consider the Organizations A and B and an input file that has data for 3 columns only (ORG_ID, ORG_DESC, STATUS):

• In the input file, the columns present contain the same info already set for the entities (that is, no changes are being made);
• However, A and B have other fields populated as well, such as DMN_ID (and this column is not present in the input file);
• So, when the Organization Connector runs and DMN_ID is not present in the file, this field is treated as blank/null and is detected as a mismatch by the delta comparison, thus marking the record as "Updated".

Now, regarding non-affected connector, here's an explanation on the different behavior:

• The Item Connector and Organization Connector manage a significantly richer set of attributes per record (such as title, description, classification, contact details, domains, etc., and such as domain, description, email address, branding style, notification settings, billing and shipping details, etc.) compared to the Job Code Connector (which handles less fields);
  
  
• Because the Job Code Connector manages a smaller and simpler set of fields, it includes a built-in step where, before writing any record, it fetches the full existing record from the database and automatically fills in every field that was not present or was left blank in the input file with the value already stored in the database:
  • By the time it actually writes the record, it is writing back exactly what was already there;
  • Since the final record being written is identical to what the database already holds, the system detects no real change and correctly counts those records as 'Unchanged Entities';
  • This behavior is possible precisely because the Job Code Connector's simpler field set makes that complete fill-in step straightforward to apply consistently across all its fields.

In summary, regarding how field values are handled during the connector execution:

• Fields present in the input file with a value are updated in the database with the new incoming value;
• Fields not present in the file, or present but sent as blank/null are protected by the connector's built-in field-preservation logic (that is, their existing database values are retained);
• The Job Code Connector's design includes an extra field-filling step that prevents unnecessary updates by always completing the record with existing database values before writing;
• The Organization Connector and Item Connector do not have such step (because they handle more fields), so this explains why they behave differently;
• This is currently the application's expected behavior.

The design of connectors such as the Organization Connector is to process a record whenever the input file does not fully represent all the fields it manages, as it has no way to distinguish between "this field was intentionally left blank" and "this field was simply not included in the file":

• Fields present in the file with a value are updated in the database with the incoming value;
  
  
• Fields not present in the file, or present but sent as blank, are protected by the connector's built-in field-preservation logic and their existing database values are retained;
  
  
• However, even though no data is lost or incorrectly overwritten, the record is still counted under 'Updated Entities' at the Connector Run Details report because the connector processed it. That is, the connector detected a difference between the incoming file data and the full database record and proceeded with the update flow.

There is however an important behavioral change when the setting noUpdateOnNull is configured:

• When organization.connector.noUpdateOnNull=ORG_DESC,EMAIL_ADDR is set (for example), only the fields explicitly listed in that configuration are guaranteed to always retain their existing database values — whether they are part of the connector run or not;
  
  
• Any field not covered by noUpdateOnNull that is not part of the connector run will no longer be protected by the field-preservation logic and its existing database value will be nullified during the update;
  
  
• This means configuring noUpdateOnNull introduces a trade-off: while it safeguards the listed fields, it removes field-preservation protection from all other fields not included in the file.

So, when the setting noUpdateOnNull is not configured for the connector, the field-preservation logic applies to all fields absent from the file. The triggering fields (such as DMN_ID, going back to the example above) are simply absent from the file (which means that their existing database values are retained and no data loss occurs). However, the records are still counted under 'Updated Entities' due to the mismatch detected during the delta comparison.

The Job Code Connector also supports the setting noUpdateOnNull. However, even without noUpdateOnNull, the connector fills in absent fields from the database before writing, which is what prevents unnecessary updates (as explained above).

Alternatively, to suggest a different system behavior, it would be possible to have an enhancement request created for it (as per KBA 2090228), where the Learning Product Management team can further review and assess the requested functionality to be considered in a future release.

KBA 2090228 - How to submit enhancement ideas for SAP SuccessFactors Products

sf, sfsf, lms, learning, connector, updated entities, Unchanged Entities, Connector Run Details, organization, item, job code, noUpdateOnNull, change , KBA , LOD-SF-LMS-CON , Connectors , Problem