Tech Blog

External user data: behavior of SIS synchronization and API

Avatarby Tamar Fuches Ex Libris November 17, 2016 (Updated: May 13, 2021)
ALMA SIS

External users are stored and managed outside the library’s scope, usually in another system maintained by the institution (for example, in a Student Information System). These users’ information is loaded into Alma and is synchronized on a regular basis. During SIS synchronization, the user data from the SIS overrides the user data in Alma:

Core user information

These fields are replaced by those in the input file. There are, However, several user fields that behave in a different manner:

  • user_group
  • job_category
  • pin_number
  • preferred_language
  • campus_code
  • rs_libraries
  • user_title
  • library_notices
These fields will NOT be overridden by the SIS synchronization if they have been updated manually.
This behavior is because these fields are not “pure user data” but a definition of the user’s library status. Hence, manual changes in the Alma UI (if done) take priority.
You can see in the Alma Edit user details page, that these fields are open for edit, while the other fields are not:
Sometimes the user data has been updated in SIS, but it is still not updated in Alma (e.g. in case the synchronization will run only tomorrow). For such cases, Alma gives the option to open the fields for update:
Changes for most fields will be lost after the next SIS synchronization job. Regarding the special fields above, Alma prompts you to determine whether they will also be overridden by the next SIS synchronization job or not:

Pressing Yes means that most of the fields (e.g. middle name) will be overridden by the next synch, but the special fields (e.g. campus) will not be overridden.

Pressing No means that all fields will be overridden by the next synch, including the special fields.

The behavior of the above fields in case they are empty in the incoming record is different for the API and for SIS synchronization job

  • API: if empty in the incoming record – existing value of the above fields will not be updated
  • SIS synchronization job: if empty in the incoming record – existing values will be deleted, and if they cannot be empty (preferred_language for example) – they will be set to default values.

User Related segments

Segments are:

  • Identifiers
  • addresses
  • phone numbers
  • email addresses
  • notes
  • blocks
  • statistics

An external user might have an external and internal segments:

The existing external segments are deleted and the segments from the input file are added. Internal segments (that were added manually) are not deleted by the SIS. Note that the existing external segments are deleted even if the input user file contains a list of empty segments.

PUT user API

Core user information

By default, the PUT user API behaves in a similar manner to SIS load – i.e. the incoming information overrides the existing user data, with the exception of the above special fields. It is possible to have the API to behave like the UI – i.e. update all the fields – by using the override parameter. Note that after updating a special field by the API (using the override parameter), this field is considered as “updated manually”, hence this data will not be overridden by the next SIS synch.
User Related segments
The API manages external and internal information:
Incoming internal segments (based on the “segment_type” attribute) will replace the existing internal segments.
Incoming external segments (based on the “segment_type” attribute) will replace the existing external segments. If the incoming list is empty, existing segments will be deleted.

2 Replies to “External user data: behavior of SIS synchronization and API”

Leave a Reply