Does a sys_updated_on applied to a child table always update the extended table, too?

[SB87]

I have tested the following scenario:

- Updated a field that belongs to an incident e.g. resolved_at and can see the incident records returns a sys_updated_on value of when I performed this update

- I then checked the extended [task] table, even though the above field does not belong to the [task] table, to see if this too returned a sys_updated_on value too, for which it did

Assumption:

Following the above, I've assumed any updates applied to a child table will also apply an update to the extended tables for which it extends. Is this generally correct?

Side question:

I have come across a scenario where another team appears to have created another sys_user record for the same user but under a new sys_id (two separate records for the same user) and then updated an asset (alm_asset.assigned_to) to point to the new user sys_id which is confirmed when reviewing the asset in ServiceNow and then previewing the assigned_to user account, however the asset did not receive a sys_updated_on update.

My guess is that they performed this activity via a script and used autoSysFields(false) which updated the asset but did not force an update to the sys_updated_on. Does this sound plausible? 

[Mark Manders]

For your second question: you need to check how they did this and what kind of audit is on the table, because it could have numerous reasons.

For the first one, 'sys_updated' is an inherited field. It is present on TASK and therefor available on all other tables, extended from task. When you update an incident record, sys_updated gets updated and if you look at the incident record from the task-list view, you will see it there (incident is extended, so available from task to be looked at). The 'sys_updated' field you see from the task table is the same field as on the incident record. It's not two fields that are updating, it's the same. 

So you are correct: if I update assigned to on a Change request, you will see the same assigned to if you look at the change from task level. 
However: not all fields (or field attributes) are available from task. The state field is a notorious one, where choice options can have the same value on different tables, but show different labels.

[SB87]

Thanks, Mark. 

For the first one, 'sys_updated' is an inherited field. It is present on TASK and therefor available on all other tables, extended from task. When you update an incident record, sys_updated gets updated and if you look at the incident record from the task-list view, you will see it there (incident is extended, so available from task to be looked at). The 'sys_updated' field you see from the task table is the same field as on the incident record. It's not two fields that are updating, it's the same.

I never thought about it this way and of course that makes sense given the sys_updated_on is present in task. What about a scenario where a sys_user gets updated where the sys_user record is being reference by an asset (for example, assigned_to). Would the asset get updated if the reference sys_user record is updated?

However: not all fields (or field attributes) are available from task. The state field is a notorious one, where choice options can have the same value on different tables, but show different labels.

Ah yes, I know this well from experience, further complicated by there being a [task].state and [incident].incident_state to consider just to add additional complexity. 

Thanks for your reply.