Changes made within a named Update Set in a different application scope:
Changes made within a named Update Set in a different application scope:
Changes made within a named Update Set in a different application scope will not be captured. An update set only captures changes made within the same application scope and cannot capture changes that cross different scopes. This ensures that each application scope remains isolated from others, maintaining the integrity of the application.
C is the correct answer. Customizations captured in update sets are restricted to the scope for the application being changed. A scope may contain several update sets, but an update set cannot cross application scopes. Consequently, an update set name could appear identical in more than one scope, but is actually different (due to the namespace), a consideration for the naming policy.
This seems very logical, will test it out
A is the correct answer. The change is indeed captured by ServiceNow, even though it may be in a separate Update Set due to scope differences. The question likely aims to assess whether the change is tracked at all, rather than the specifics of how it's managed across scopes (batches and children)
"1. Limitations of update sets: The biggest limitation is that an update set cannot capture updates across the different application scopes. In order to capture updates across different application scopes, you need to create multiple update sets catering to each application scope."
Changes made within a named Update Set in a different application scope are not captured because each application scope in ServiceNow is designed to be a separate and isolated environment.
I actually think this is B. The updates will be captured but will throw errors when promoting. I have seen this happen multiple times in code promotion.
Actually, I tested this in my PDI and it does not allow you to have an update set for another application open in a separate scope, so I agree with the others who said C.