SIF data objects are identified using RefIds; these are basically GUIDs with a different formatting.
A RefId within a zone can be relied upon to be unique, however you should not rely on RefId to be unique between zones and for that reason you should safeguard against incorrect joins between SIF objects by matching on both RefId and ZoneId.
The RefId for a SIF object is ‘near-persistent’ within a zone; that is, it shouldn’t change but it is possible for it to (for example by virtue of a data integrity issue or due to re-initialisation of the agent providing data to XVault). The likelihood of change varies by source MIS as some products keep a suitable value within the MIS and some require the extracting agent, typically Xporter, to generate and assign RefIds against other MIS identifier values. The latter approach obviously carries a slightly increased risk of that mapping table being lost when e.g. a school reinstalls the agent.
RefIds do not move with any person (or other SIF data) between schools, as a learner’s UPN or ULN might. Hence a learner present in two schools would appear in XVault twice, once in each school zone and with a different RefId in each case. See below regarding Multi-site or Duplicate learners for more information.
In the case of LearnerAttendance and LearnerEntitlement, Groupcall Xporter agents assign a RefId that is computed rather than randomly generated. This is to ensure writeback compatibility for those data objects, and they remain guaranteed unique within a zone.