Instance Configuration
Instance hierarchy and cloning
ServiceNow recommends a tiered model: production, one or more sub-production instances (test, staging), and development/sandbox instances. Clone copies configuration (and optionally data) from a source to a target. The hard rule: production is always the source for clones into non-production. You never clone non-production into production, because test data would overwrite live records. Cloning preserves sys_id values so references stay intact; the target instance is unavailable during the copy.
System properties
Properties are key/value settings stored in sys_properties (browse sys_properties.list). Platform properties use the glide. prefix (e.g. glide.ui.session_timeout); custom properties should use your own prefix. Properties can be read and set from scripts with gs.getProperty() and gs.setProperty(). Prefer properties over hard-coded values so behaviour can be tuned without a code change.
Update sets and plugins
An update set captures configuration changes (records, scripts, metadata) made in one instance and moves them to another. Update sets do not carry data records, and they must be completed, exported, and committed in dependency order. Plugins activate larger capabilities (e.g. Performance Analytics, Flow Designer); they are installed per instance and are not transferred by update sets.
Traps
Expect questions that flip the clone direction, that claim update sets move data, or that confuse system properties with user preferences (preferences are per-user, stored in sys_user_preference).
Rule of thumb
"Configuration travels by update set or clone; data travels by import or clone-with-data." If an option suggests update sets carry records, eliminate it.