"externalId" in this context is less "this is an ID that comes from an external identity reference" and more "this is an ID the creator of the record provided d

"externalId" in this context is less "this is an ID that comes from an external identity reference" and more "this is an ID the creator of the record provided during the creation request" - in contrast with an internal ID, which is what the server uses internally to refer to the record (usually a sequential or random integer - in SCIM's case, a UUID). This is pretty common for enterprise software; you'll have the software itself generating an internal ID, but the user will provide an external ID to relate that record to its equivalents in other systems. Like with other enterprise software (that I've worked with), SCIM's externalId is optional - and you can see in the examples that it's usually duplicating some other field, like the username or an employee number. That optionality is a double-edged sword, though; if you're integrating software that expects an externalId to be set, then you gotta make sure it's indeed being set. Back when I was doing NetSuite administration/development full-time that bit me in the ass on many occasions; middleware would be opinionated about the externalId being set, and I'd have to make sure that was getting populated from whatever record-specific unique ID (e.g. tranId for transactions).