How can I create physical items in batch using an Excel file? (Cloud App)
Answer
For a long time we needed to use an import profile to create lots of items at once in Alma. More recently a Cloud App has emerged that is in some ways a more straightforward path to accomplishing this goal, if you are just adding items that are to be linked to existing bibs and holdings records.
Add the cloud app
The cloud app is called Item Creator by Excel.
I'm not going to walk through how to add the cloud app. Ex Libris provides this information in their documentation. The app is enabled in the Los Rios IZ.
Note that while the name is Item Creator by Excel at its documentation page at the Developers Network, in Alma it seems to appear as Items [plural] Creator by Excel.
Prepare your metadata
The cloud app will only create items; any bibliographic and holdings records must already exist in Alma. So if they don't exist yet, create and save them, e.g. via the Metadata Editor.
Use the cloud app
You can read about this app at the Ex Libris Developer Network page linked above, barely; not much info is supplied. But the concept is plain: create a spreadsheet with headers of, at minimum, mms_id and holding_id. You will then want most likely to include things like barcode, copy ID, receiving date, etc. These headers are based on the Alma Bibliographic Records and Inventory APIs, specifically the item object. The app's page links to an .xsd file that includes the various headings from this object. However, I think it's much easier to look at the page on item objects in the API docs.
It's possible not all fields present in the item object are supported by the cloud app, but the ones I've tried as of January 2025 are (some were added only recently).
Here are some values you might use for monographs / technology items:
| Alma field label | Table header | notes |
|---|---|---|
| MMS ID | mms_id | Required |
| Holdings ID | holding_id | Required |
| Barcode | barcode | |
| Copy ID | copy_id | |
| Item Policy | policy | Code, not description (see tip below) |
| Material Type | physical_material_type | Code, not description. This refers to the item-level material type, not bib-level. Bib material type comes from MARC fields |
| Receiving Date | arrival_date | I'm not totally sure what formats are supported, but the following worked: YYYY-MM-DDZ So, example: 2025-01-21Z |
| Provenance | provenance | Code, not description |
| Replacement Cost | replacement_cost |
Obviously if you are doing serials, stuff like Chronology and so on will be helpful.
Once you've created (and saved!) the spreadsheet, open the cloud app, drag the file to the app window, and click Create Items. If there's a problem with the file, the cloud app will tell you. When it is complete, it will display a brief summary of what it did.
Note, the first time you try this, it's a good idea to do just one row, to make sure the test item was created the way you want it. Then you can do the rest.
Tips
- When you are initially creating the Excel file, select all cells and change the format to Text, to avoid situations where Excel "helpfully" transforms numbers by e.g. ending your MMS ID in 00.
- Be careful if you "pull down" MMS ID or other numbers to populate all the rows—Excel might increment them. You might do better with copy-paste.
- Note that in some cases, Alma stores both codes and descriptions, which are a more reader-friendly thing. Descriptions are what we see in the Alma interface. What the app wants is the code (in the API object this is found in the value property). You can find these codes in Alma configuration, in the relevant code tables. If you go to configuration and search for e.g. "item policy" or "material type" you will find the matching code table. So at Los Rios, sample physical_material_type code values would be
Code (to use in spreadsheet) Description (for reference) BOOK Book LPTOP Laptop CHARG Laptop Charger - Of course in some use cases you could just include a small number of fields where the values vary, such as barcode and copy id, and then after creating the items, use the Change Physical items Information job to fill in values that are common to all, e.g. replacement cost, material type etc. But it's nice to get it done all at once.
Cloud App vs. Import Profile
The page on accomplishing this goal via an import profile has gotten a lot of hits over the last few years! The import-profile approach does have some stuff to recommend it, e.g.:
- you can populate default values in the profile instead of repeating values for dozens/hundreds of rows
- similarly, when you set these values in the import profile, you will see the value's description rather than code; you don't need to know or look up the code
- you can decide what table headers to use (e.g. 949$i), rather than needing to find out which headers are expected
- it gives you a proper job report. I think this is especially nice for a very large import. But many of the things that you might mess up, e.g. putting in the wrong MMS ID, would be caught when you try to run the cloud app.
- it runs as a background process. I'm a little unsure about cloud apps; do they run in the background? I should test it. My impression has been that if you navigate away from them, they stop doing their thing. So again, if you're creating hundreds of items, maybe it's better to use an import profile
Personally I'm inclined to go the cloud app direction in the future. Import profiles are really designed to control bib/holdings metadata (add, merge, overlay etc.), so if no metadata is at stake—you're just adding items to already-existing bibs/holdings—then the cloud app, which is designed specifically to do just that, seems more apropos.