The Standard Model

Details

The Standard Model introduces a new record summary field available in every data source The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on., and, in Record details View, two panels in most data sources that improve support for procedural, administrative and financial data:

the Actions panel is used to plan or register a range of actions such as meetings, reviews, photography sessions, etc.
the Expenses and income panel is used to register costs of activities such as cleaning, insurance, crate construction, painting, shipping, etc.

Tip: Application Administrators can extend the lists of actions or expenses in these panels by adding new action types or fee activities in the System lists data source.

While not new to Axiell Collections, free fields and the Free fields panel have been improved and made available across more data sources. The Free fields panel provides a location for any data that does not have a native field in Collections, and it is intended as an alternative, where appropriate, to customization of the application.

Tip: The Common panels topic assembles the following descriptions of panels and descriptions of several others that are widely available.

Also introduced with the Standard Model and available in every data source is the Record summary (record_summary (Z0)) field, a field that provides an auto-generated summary of a record's key data taken from one or more key fields in a record.

And finally, it is now possible to mark a record as read-only when there is no longer a reason to alter it.

New and changed fields

Media references (FN)

A back-end change to the (FN) media field in the Standard Model delivers more flexibility without requiring a change to the way we work with media in Collections.

The FN field is found in two place in Collections:

In the Media1 data source, where it is called Media reference (reference_number (FN)):

Media reference is used to upload new media (such as image, video, audio or PDF2 files), creating a record for the media that can be linked to other records throughout Collections (details here).
On the Media3 panel in many data sources, where it is called Reference (media.reference (FN)):

Reference is used to link the current record The record currently displayed in Record details View or highlighted (with a solid background) in Result set View or Gallery View for instance. to an existing Media record OR to upload a new media file, create a Media record on the fly and link the current record to it (details here).

Reference is typically repeatable and more than one occurrence If a field in the current record can have more than one value, we add an occurrence of the field for each value (e.g. a book can have multiple authors so we add an occurrence of the author.name (au) field for each author). An occurrence can be a member of a group of fields, and adding an occurrence of the field adds all members of the group at once. can be added, which allows multiple media files to be associated with a record.

The change introduced with the Standard Model is to the field type of the FN field from Image to Application:

The change was implemented because Application fields can hold a greater range of file types than Image fields, making them more versatile.

There is a consequence of changing the field type however. Media viewer is used to display images and PDFs4, and to play video and audio files found in any field in the current record with a field type of Image, not Application. To address this, and to provide even greater flexibility when working with media files, the Playback URL (media.playback_url (mu)) Image field has been added alongside the FN field:

In the image above, we see Playback URL (highlighted) on the Media panel in a Catalogue record. Whenever an image, video, audio or PDF file is linked to the FN field, the file's path / URL / file name is automatically copied to the Playback URL field, ensuring that it displays in Media viewer.

Note: It is worth stressing that this does not change the way we work with media files5 and we continue to use the FN field to add media to a Media record, and to link media (including images, PDFs, video, and audio) to records in other data sources.

Playback URL provides greater flexibility when working with media as it is possible to edit the value copied to the field to point to an alternate version of the media file (perhaps downscaled, watermarked, and so on). It is necessary to edit the value of Playback URL in the Media record (not in the Catalogue for instance). However, it is a simple matter to edit the Media record from another data source by clicking the value in the Reference field; this will display the linked Media record in a Zoom screen A Zoom screen is a pop-up screen similar to Record details View but with fewer options, fields and panels. It will pop-up and display summary details of a Linked record (for a term, person, location, etc.) when an underlined value is clicked in Display mode or the Details button is selected when linking records in Edit mode, for instance. Typically, record details in a Zoom screen can be edited., which can be edited:

Note: The original file and alternate version must be saved to the same location.

See Media and digital file storage locationbelow for details about where uploaded files are now stored in Collections.

Output formats (reports)

Note that Output formats An Output format is an XSLT style sheet or Microsoft Word or Excel template that specifies what fields are included in a report or printed output, and how the data is laid out and styled. in the Standard model now use tag mu to print images, instead of FN.

Reports created in earlier Model Applications that use the FN field for image references will need to be updated to use mu instead.

Publish on web (publish_on_web (wp))

In Model Applications prior to the Standard Model the Publish on web (publish_on_web (wp)) checkbox is found in the Catalogue and Multimedia documentation data sources; in the Standard Model it is also available in other data sources, including:

References and citations
Events
Exhibitions and venues
Geographical thesaurus
Locations and containers (called Publish? and found on the Identification panel)
Persons and institutions
Thesaurus
Use of Collections

When the Publish on web checkbox is selected (ticked), the record will be available (discoverable) in the public front-end (e.g. a public facing website); if the checkbox is unticked, the record will not be discoverable in your public facing website.

Read-only records (record.read_only (zz))

Introduced with the Standard Model, the Read only (record.read_only (zz)) checkbox is used to make a record read-only, allowing it to be read but no longer edited.

In most data sources The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on., the Read only checkbox is found on the Management details panel (typically under a Record access heading):

In some data sources (Archives catalogue and Accessions for instance) it is found on a Notes and description control panel:

You would mark a record as read-only when a final record Status (current_status (sS)) has been assigned and there is no longer a reason to alter it: records for a past exhibition, deaccessioned objects, cancelled acquisitions, and the like.

Once a record has been marked as read-only it can only be edited by Application Administrators (anyone with $ADMIN access); for everyone else a message will pop-up indicating that the record cannot be edited. For Application Administrators a pop-up will give them the option to re-enable editing of the record:

Tip: A response must be provided within 10 seconds (a count down is shown in the No button); if a response is not provided, the pop-up disappears and the record remains uneditable.

New and changed panels

Accompanying texts

In systems running Model Applications older than the Standard Model, the Accompanying texts panel found in Catalogue records only includes a Labels group of fields, and it is used to record text about an item in your collection for purposes such as wall labels, press releases and website content. A Web texts section is added to the panel with the Standard Model and it is intended for recording text for online publication on your own public-facing website or to record text found elsewhere; an advantage of a dedicated Web texts section is that it is able to provide control over the publication of each occurrence If a field in the current record can have more than one value, we add an occurrence of the field for each value (e.g. a book can have multiple authors so we add an occurrence of the author.name (au) field for each author). An occurrence can be a member of a group of fields, and adding an occurrence of the field adds all members of the group at once. of a web text:

The Web texts group of fields is repeatable A field that is repeatable can have multiple occurrences. A book, for instance, can have more than one author: the Author field can be repeated as many times as necessary to capture all of the book's authors. Use the Occurrences options in the Record details View toolbar to add occurrences of a field., and for each occurrence it is possible to specify the URL of the web page where the text is (or will be) published. Text is entered and formatted in an HTML field; where text is intended for your own website, a Publish? checkbox is provided that can control whether the text is available for publication or not.

Field / System name	Details
Type / web_text.type (O1)	A Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). to the Thesaurus. Identify the type of web text (e.g. online exhibition text, object text, etc.). Start typing a term, or click the Link icon to display the Find data for the field box; search for the relevant term or create a record in the Thesaurus and link to it (if authorized to do so). Details about working with the Find data for the field box can be found here.
Author / web_text.content_by (O6)	A Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). to Persons and institutions linking to records where Role(s) (name.type (do)) = staff by default. Start typing the name of the person who authored the web text in Text ( web_text.content (O7)), or click the Link icon to display the Find data for the field box; search for the relevant person or create a record in Persons and institutions and link to it (if authorized to do so).
Date / web_text.date (O2)	Date field. The date on which the web text in Text ( web_text.content (O7)) was authored. Type a date or click the Calendar icon to select a date (details about date fields and how to use the Calendar can be found here).
Publish? / web_text.publish (O5)	Important: Configuration is required to enable this feature By default, the Publish? checkbox only flags that the web text can be published and additional configuration is required in order to enable this setting in Axiell Internet Server (AIS). Contact Axiell Support for details about how the Publish? setting is enabled. Checkbox. When selected (ticked), the web text entered in Text ( web_text.content (O7)) can be published in your public front-end (e.g. a public facing website); if the checkbox is unticked, the web text cannot be published in your public facing website.
URL / web_text.url (O4)	An `Application` field (a URL entered here can be clicked to open the web page in a browser). The Web texts fields can be used to record and manage text to be published on your public facing website, and to record web content published elsewhere. In either case, enter the URL of the web page where the web text is (was / will be) published.
Notes / web_text.notes (O3)	Text field for providing any details about the web text (will expand to hold a significant amount of information).
Text / web_text.content (O7)	An HTML field. Enter and format the text.

Actions panel

The Actions panel is a basic workflow tool designed for managing tasks (actions) relating to the current record. The type of action tracked depends on the data source you are working in (actions in the Catalogue will not necessarily be the same as actions in Loans for instance); actions might include anything from scheduling meetings, reviews, to photography sessions, etc. Managing tasks might entail scheduling an action (a meeting for instance), tracking an action's progress (the crate has been ordered) or documenting that an action has been performed (the object was moved). This functionality is not meant to replace dedicated project management software, but it can be used to prescribe standard procedural tasks (setting default actions) and to track and log tasks relating to the current record.

Default and conditional actions

Application Administrators can define default actions for any new record in the System admin – occurrence defaults data source.

If an action is required when certain conditions are met, occurrence defaults can be set up to facilitate this; for example, in Acquisitions and acquisition proposals a Send Deed of Gift action can be added when a record has an Acquisition method (method (sm)) of gift and a Status (current_status (sS)) of approved.

An example Actions panel

Although the actions we document and track may differ from one data source to another the method for using the panel is the same. Here we see the Actions panel in the Acquisition items data source, where we select actions from the Type drop list that affect an item during its acquisition:

The purpose and use of many fields are clear and straightforward, and we only highlight those of particular importance below:

Field / System name	Details
Type / action.type (U0)	A Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). to the System lists data source. Start typing the term for an action and select it from the drop list, or click the Link icon to display the Find data for the field box; search for the relevant term or create a record in System lists and link to it (if authorized to do so). Actions might include: acquisitions meeting, conservation review, meet with donor, etc. Tip: Application Administrators can add additional action types in the System lists data source. Details about working with the Find data for the field box can be found here.
Responsible / action.person_responsible (UA)	A Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). to Persons and institutions. Start typing the name of the person responsible for the action and select it from the drop list, or click the Link icon to display the Find data for the field box; search for the relevant person or create a record in Persons and institutions and link to it (if authorized to do so). Details about working with the Find data for the field box can be found here.
Requested by / action.requested_by (U6)	A Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). to Persons and institutions. Specify the person who requested the action.
Request date / action.request_date (uA)	The date on which the request was made. Type a date or click the Calendar icon to select a date (details about date fields and how to use the Calendar can be found here).
Priority / action.priority_level (Uc)	Drop list of values. Indicate the priority of the action: non-priority low medium high
Date due / action.date_due (u2)	The date the action should be completed.
Start date / action.date_start (U1)	The date the action commenced.
Date completed / action.date_complete (U4)	The date the action completed.
Confidential? / action.confidential (U9)	Checkbox indicating the sensitivity of the action. Tip: Although selecting the checkbox does not trigger any action in the software, it could be used by a script to exclude confidential actions when running a report, for instance.
Status / action.status (U8)	Drop list of values. Select the current status of the action: pending pending approval approved open suspended completed rejected cancelled
Status date / action.status_date (u8)	The date the status was set.
Rec. Ref. / action.record_reference (u9)	Short for Record reference: if an action is part of a larger project, enter the reference number for that project. Although there is currently no functionality built around this or the following field, Job no., it is anticipated that an Action Request tool will become available in a future release that will connect individual actions back to an original request or project.
Job no. / action.job_number (uB)	Used for internal numbering of individual actions. This is useful if actions are generated (or referenced) by an originating Action Request.
Description / action.action_text (u1)	Provide detail about the action. As Type is a Linked field, Description can be useful for providing nuance for what is expected from an action.
Notes / action.notes (u7)	Document any outcomes, problems, or information that might be helpful for completing the action.

Digital references panel

A Digital references panel has been added to most data sources, allowing documents to be linked consistently to records throughout Collections. The key field for uploading documents is File (digital_reference (RF)), which is distinct from the Reference (media.reference (FN)) field on the Media panel used for uploading other types of media files (images, etc.). An advantage of having a separate field for digital and media references is that it is possible to implement different access permissions for documents and other types of media file.

On the Digital references panel we link to relevant digital documentation (Word docs, PDFs, URLs, etc.):

Word docs and URLs (and other digital references) are linked to a record using a field with an Application data type such as File (File (RF)) on the Digital references panel. A field with an Application data type is associated with an application, such as a PDF reader; depending on your browser's configuration, clicking the underlined file name for a .pdf file will open the document in a browser tab:

Alternatively, click the Download icon to download and view the document.

Use these repeatable fields to link to one or more digital documents (Word docs, PDFs, URLs, etc.) relevant to this acquisition item.

Field / System name	Details
Type / Type (Ro)	A Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). to the Thesaurus. Start typing the term for the type of document and select it from the drop list, or click the Link icon to display the Find data for the field box; search for the relevant term or create a record in the Thesaurus and link to it (if authorized to do so).
File / File (RF)	If you know the path to the digital reference, type it into this field; alternatively, for digital documents, select the Upload button to locate and upload a document accessible to your device.
Description / Description (RT)	Enter a brief description of the digital reference.

See Media and digital file storage location below for details about where uploaded files are now stored in Collections.

Expenses and income panel

The Expenses and income panel is available in data sources where costs and / or income are incurred for activities relating to the current record, such as cleaning, insurance, crate construction, painting, shipping etc.

Note: In data sources where income is not generated but expenses are incurred, the panel is called Expenses and it does not include the Direction column.

For each activity, the cost can be registered, and totals calculated.

A line item can be for a specific item in your collection, in which case you would select an object number from the Item drop list, or it can be a general cost unrelated to a specific item, in which case you can ignore the Item drop list.

The purpose and use of many fields are clear and straightforward, and we only highlight those of particular importance below:

Field / System name	Details
Activity / cost.activity (Pa)	A Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). to the System lists data source. Start typing the term for an activity and select it from the drop list, or click the Link icon to display the Find data for the field box; search for the relevant term or create a record in System lists and link to it (if authorized to do so). Expense activities might include: cleaning, crate construction, shipping, etc. Income activities might include conservation (performed for external clients), licencing (fees for use of collection items by third parties), ticket revenue, etc. Tip: Application Administrators can add additional activity types in the System lists data source. Details about working with the Find data for the field box can be found here.
Name / cost.name (Pb)	A Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). to Persons and institutions. Start typing the name of the person responsible for the activity incurring the cost / generating income, or click the Link icon to display the Find data for the field box; search for the relevant person or create a record in Persons and institutions and link to it (if authorized to do so). Details about working with the Find data for the field box can be found here.
Direction / cost.direction (Pe)	Indicate whether the activity generates income or is an expense. Drop list of values: income expense
Item / cost.item.link (PI)	A drop list of object numbers for items in your Catalogue. If the line item relates to a specific item in your collection, select its object number from the drop list; otherwise ignore this drop list.

Free fields panel

When we talk of types of field we typically refer to the field's data type (date and geolocation fields) or a particular quality (inherited fields). In the case of free fields, it is their purpose that characterizes them.

Most fields in Collections are intended to hold a specific piece of information (an object number, a title, a birth date, and so on) often defined by an industry standard (SPECTRUM or ISAD(G), for instance). Free fields, which are found on a Free fields panel typically near the bottom of the list of tabs in Record details View, provide more flexibility; while not new to Collections, their use in the past was mostly limited to holding data migrated from fields in legacy systems that had no obvious equivalent in Collections.

Note: In systems running Model Applications prior to the Standard Model, there is a single text type of free field.

The release of the Standard Model saw a significant increase in the number of fields and data sources available in Collections so that there is almost certainly a suitable field to hold your data without the need for customization. This has allowed for a new approach to the use of free fields in systems running the Standard Model, and Free fields panels are now intended as an alternative, where appropriate, to customization of the application. To that end, Free fields panels are now available across more data sources; and it is no longer necessary to store all types of data in a generic text field as there are now free fields to hold text, dates and numbers, and there is also a checkbox variant:

Their use is straightforward. You specify the purpose of the field in Type (name the field) and enter the value in the Content field:

Note: As values in the Type field are managed in the System lists data source6, Application Administrators ($ADMIN users) are free to add new values as required.

As each group of fields on the Free fields panel (Texts, Dates, Checkboxes, Numbers) is a repeatable group of fields, you can use the Occurrences drop list in the Record details View toolbar to add / remove / move a group of fields.

If there is no native field for a piece of data, consider whether a free field can be used to hold it, avoiding the need to customize the application.

Data sources for (users) managing collections data

With the Standard Model a number of data sources have been expanded and improved (including Persons and institutions, Locations and containers, Exhibitions and venues; and new data sources have been introduced, in some cases by taking fields that were available in a limited form in the Catalogue or another data source and moving them to a dedicated data source, greatly expanding the scope of information that can be documented (including Deaccessions and Disposals, Rights and Licensing, References and citations, Movement history, Movement and shipping logistics, Incidents, Events, Entry, Deliverables, Collections audit). By far the most significant enhancement to collections management has been the introduction of a new category of data source, Items. There are four Items data sources, Acquisition items, Exhibition items, Loan items and Collections audit items; these sit between data sources like the Catalogue and Loans, and they hold extensive granular detail about collection items involved in a particular activity, such as a loan or exhibition.

Here you will find an overview of data sources that are new to Axiell Collections and those that have been expanded and improved with the Standard Model, and a link to more comprehensive information in the Data sources sections of this Help where required.

Data source

New or changed

Details

Assessments and treatments

Changed

Used to manage and track conservation, restoration, and condition checks / assessments performed on items in your collection.

Changes introduced with the Standard Model

In Model Applications up to version 5.2 condition information can be documented in either (or more often both):

an object's Catalogue record: by completing the repeatable A field that is repeatable can have multiple occurrences. A book, for instance, can have more than one author: the Author field can be repeated as many times as necessary to capture all of the book's authors. Use the Occurrences options in the Record details View toolbar to add occurrences of a field. Condition group of fields on the Condition | Conservation panel;
an Assessments and treatments record, documenting the assessment / treatment work, linked to the Catalogue record for each affected object (read on for details about how to link to objects).

To avoid any ambiguity about where details are recorded, condition information is only documented in an Assessments and treatments record in the Standard Model.

An Assessments and treatments record lists the Catalogue record of all affected objects on the Linked objects panel; condition details about each linked object are then documented on the Condition description panel. Details about the Assessments and treatments record automatically display in the Assessment / Treatment log table on the Condition | Conservation panel in the object's Catalogue record.

The recommended way to add one or more objects to an Assessments and treatments record is to use the Add to objects Links option in the Result set View toolbar (the same method applies for all Model Applications):

Creating an Assessments and treatments record in the Standard Model

When creating a record there is the choice of two record types:

Type

Details

treatment

A treatment record can be used to plan treatments, track and manage the status, requests and authorizations of the treatment (on the Treatment details panel):

And to document the full process from pre to post treatment (Treatment process panel):

All available panels:

check/assessment

A check/assessment record can be used to track and manage the status, authorizations and follow-up activities of an assessment (on the Assessment details panel). Note that assessments can have successive follow-up treatment and assessment activities as often as required, each in their own record, via the repeated Requested activity fields:

The Condition descriptors field group on the Condition description panel can be used to link controlled condition terminology to items on the record:

All available panels:

It is possible to create Assessments and treatments records directly in a number of data sources, including:

Loan items - in the Reference number field on the Condition assessments panel;
Incidents - in the Post-incident assessment field on the Objects and containers panel.

As can be seen above, Assessments and treatments records include the Actions, Expenses and income and Free fields panels.

Collections audit and Collections audit items

New

In Model Applications prior to the Standard Model, undertaking a locations check of multiple objects is handled with the Collections review data source; and a more ad-hoc locations check of individual items is managed with the Location checks group of fields on the Location | Future movements panel:

The Standard Model improves locations checking with the introduction of two data sources designed exclusively for this purpose, Collections audit, in which we document and manage the overall status and details of a locations audit, and Collections audit items, in which we document and manage the details of an individual item involved in a locations audit. Task-driven workflows are provided for large scale audits and for more ad-hoc locations checks.

Details about performing a locations check with the Collections audit and Collections audit items data sources can be found here.

Collections review

Changed

The Collections review data source, which was introduced with Model Application 5.0, is used to document and manage formal assessments of collection items, the scope of which might be a few items to the entire collection. A collections review is undertaken to acquire a deeper understanding of the collection, including the condition, provenance, and significance of items.

Collections review has been improved with the Standard Model with the addition of several useful panels, including Digital references, Free fields and Status history, and an improved PIDs and other identifiers panel; however the most significant change is that locations checking, which is a function of Collections review, is now managed far better with the new Collections audit and Collections audit items data sources, described below.

Deaccessions and Disposals

New

Deaccession and disposal are related but distinct processes, typically involving a formal and documented review that takes into account your institution's collections policy, as well as legal and ethical considerations. In Model Applications prior to the Standard Model, deaccession and disposal data is registered in a limited set of fields in Object Catalogue records on a Disposal panel, with a focus on documenting the disposal of an object. The Standard Model moves these fields to a dedicated Deaccessions and disposals data source, greatly expanding the scope of information that can be documented.

Details about how to record deaccessions and disposals can be found here.

Exhibitions and venues

Changed

Previously called Exhibitions. Now used to document and manage the status and details of exhibitions and the venues at which they take place; used in conjunction with Exhibition items (see Items data sources below). Venue records can be used independently of an exhibition, to document the display of items in collection galleries for instance.

Details about how to document exhibitions, venues and exhibition items can be found here.

Insurance and indemnity and Valuation

New

In Model Application 5.2 and earlier, valuation, insurance and indemnity information about objects is managed on the Value | Insurance panel in Object catalogue records. The fields on this panel are adequate for recording key financial and risk management details, but comprehensive valuations, insurance and indemnity documentation of collection items can involve more information and activities (actions) than these fields can accommodate. This is addressed with the Standard Model and the introduction of two data sources dedicated to managing valuations and insurance and indemnity matters: Insurance and indemnity and Valuation.

As well as recording information about the provider, policy, and coverage amount, an Insurance and Indemnity record lists all covered objects, with a link to a Valuation record that assesses an object's value, and it identifies locations and shipments that are covered by the policy. On the Actions panel, a basic workflow tool for managing tasks related to the current record, it is possible to document and manage any related activities (actions), such as scheduling meetings. Digital copies of documentation can be made available on the Digital References panel.

Details about how to document an institution’s insurance and indemnity policies can be found here.

A Valuation record holds valuation details for a specific Catalogue item, including amounts, currency, exchange rate, who conducted the valuation, why it was undertaken and when. On the Actions panel, a basic workflow tool for managing tasks related to the current record, it is possible to document and manage any related activities (actions), such as scheduling meetings. Digital copies of documentation can be made available on the Digital References panel.

Details about how to document object valuation details can be found here.

Items data sources

New

Introduced with the Standard Model, Items data sources are used to document and track collection items involved in day to day activities like loans and exhibitions. In prior Model Applications, when a collection item is on loan its Catalogue record (with details about the item) links directly to a Loans record (with details about the loan); what is lacking is somewhere to record details about the item in the loan, to track the status of each item as it navigates the loan workflow, or to plan actions that impact an item's involvement in the loan. The same is true of items involved in acquisitions, exhibitions and collections audits. Items data sources fill this gap by providing a place to manage and document each item individually as it participates in activities like loans and exhibitions. They include Acquisition items, Exhibition items, Loan items and Collections audit items.

An overview of Items data sources can be found here.

Guidance is provided for working with each of the Items data sources:

Locations and containers

Changed

The management of locations has been enhanced in a number of ways, not least the addition of fields and panels (notably Media, Digital references, Free fields and Actions) to the Locations and containers data source, increasing the amount and type of information that can be recorded. New fields include Status, Unavailable, On view and Publish?, as well as a group of Contacts fields on the Identification panel for names and phone numbers of a Location manager and Emergency contact.

With the introduction of the Movement and shipping logistics and Movement history data sources, details abut the movement of containers have been removed from Locations and containers records; a Movement history panel is now provided for container records with a link to one or more records in the Movement history data source providing comprehensive details about the container's movements.

Details about new fields and panels can be found here.

Movement and shipping logistics

New

The Movement and shipping logistics data source is used to plan incoming, outgoing, internal, and external movements of collection items7 from single stage movements (from a storage location to a conservation studio, for instance) to multi-stage movements (from storage location to truck, to flight, to truck, and so on). The Current location of an object is automatically updated when its Status (object.status (TS)) in the Movement and Shipping Logistics record is set to completed.

For those familiar with previous Model Applications, Movement and shipping logistics replaces the Transport data source. Details about the planned movement of objects in previous Model Applications are found on the Location|Future movements panel in the Future movements fields. In the Standard Model this panel is renamed Location|Audits and the Future movements fields have been removed; instead, a Movement and shipping logistics panel is provided, where any Movement and shipping logistics records documenting an object's movement are listed. Movement and shipping logistics records are capable of managing more complex movements and documenting far more detail than was possible with the Future movements fields, including movement reasons, methods, recipient and courier contact details, and so on.

In the Standard Model,

Details about documenting locations and managing movements can be found here.

Movement history

New

A full history of the movement of objects and containers in Model Application 5.2 and earlier is retained in an object's Catalogue record and a container's Locations and containers record. Whenever an object is relocated, details about the previous location, relevant dates, who authorized the movement, the reason for the movement, and so on are saved on the Location history panel in the object's Catalogue record; when a container is relocated the details are documented on the Container details panel in its Locations and containers record.

One consequence of this approach is that movement history details can proliferate in an object or container record, potentially making them slower to load; another is that working with location history data can be complex.

In the Standard Model the movement of objects and containers is comprehensively documented in a dedicated Movement history data source. Every change to an object or container's Current location generates a record in the Movement history data source that is automatically listed on the Movement history panel in the object or container record, allowing the granular movement history details to be removed from Catalogue and Locations and containers records.

Details

It is worth stressing that every change to an object or container's Current location generates a record in the Movement history data source; movement history in prior Model Applications is only updated when the Change locations task is used to document a relocation.

Here we see the Movement history panel for a container, chronologically listing the Movement history record for each relocation of the container:

Clicking a Reference number will display details of the relocation in a Zoom screen A Zoom screen is a pop-up screen similar to Record details View but with fewer options, fields and panels. It will pop-up and display summary details of a Linked record (for a term, person, location, etc.) when an underlined value is clicked in Display mode or the Details button is selected when linking records in Edit mode, for instance. Typically, record details in a Zoom screen can be edited..

Alternatively, open Related records View to list the Movement history records linked to the current record The record currently displayed in Record details View or highlighted (with a solid background) in Result set View or Gallery View for instance.:

Clicking one of the Movement history records in Related records View will make it the current record (switching to the Movement history data source and displaying that record only). Clicking the Movement history header will switch to the Movement history data source listing all of the related records (seven in this example); this allows you to manipulate the records in various ways (sorting them in Result set View, for instance).

Packed objects (objects located in a container)

In Model Application 5.2 and earlier, when an object is located in a container and the container is relocated, only the movement history of the container is updated (on the Container details panel in the container's Locations and containers record); the movement history of the object is not updated. As a consequence, it is necessary to investigate the location history of the container in order to identify where a packed object was at any moment in time.

When a container is relocated in the Standard Model a Movement history record is created for the container AND for each object contained within it. Each object's Movement history record identifies the container it was packed in, as well as the full location of that container in the Context field:

Fixed (unchanging) context

Additionally, the detail shown in Context is now a fixed value stored in the Movement history record; in prior Model Applications the context is not stored in a record but is retrieved dynamically when the record is displayed. This means that the location context details accurately capture the full (historically accurate) location at the time of a move, rather than updating if, say, a gallery changes its name sometime after a move, or the location hierarchy changes; amongst other reasons, this can be important when performing collections audits.

Chronological order

Every relocation of an object or container is listed on the Movement history panel in chronological order. This means that if the Change locations task is used retrospectively to document that an object or container was moved in the past, the resulting record will slot into the Movement history at the appropriate point in time (rather than being treated as the newest move).

Persons and institutions

Changed

New fields, field groups and panels have been added to Persons and institutions, expanding and enhancing data management of individuals and organizations interacting with your collection.

Details

Notable new and changed panels and fields:

Identification panel

Field group

Field

Details

Authorised form of name

Record type / record_type (oG)

Chief amongst the new fields is the Record type (record_type (oG)) drop list on the Identification panel:

While Record type is not mandatory, it is a useful conditional field: selecting a value in the drop list will tailor which fields are available, and potentially auto-populate fields. Enter a name in the mandatory Name field, and select an option from the Record type drop list.

Here we enter a name in the Name field (Surname, Forename or Forename Surname) and select Individual from the Record type drop list:

Tip: In earlier Model Applications it is generally best practice to enter names as Surname, Forename, but that is no longer required with the Standard Model as a name entered as Forename Surname will be parsed and sorted by surname automatically.

A number of things happen:

Name sort is auto-filled with the contents of Name, capitalized; if Record type = Individual, the name is formatted as <surname>, <forename>.
A Person’s name elements group of fields is added below the Authorised form of name group of fields, with Surname and Forename(s) auto-filled.
Note: If, for some reason, the value in Name is not automatically split into its Surname and Forename elements, click the Generate name checkbox.

Name role / name.type (do)

Many more roles have been added to the Name role (name.type (do)) drop list. Name role is an enumerative Read-only drop lists; their values are added and translated by Application Administrators in the Collections administration tool, Axiell Designer: users can select a value in an enumerative field, but cannot add or translate a value. list of domains A subset of records in an Authority data source, grouping similar sorts of records. When a search or Linked field is associated with a domain, only records in that domain are available to that field. For example, records for authors can be assigned to the AUTHOR domain (using the Name Type / name.type (do) field). When linking a record for a book to a record for its author, the Author Linked field will point to the AUTHOR domain, a subset of records in Persons and institutions exclusively for authors. In the Thseaurus, a record is assigned to a domain using the Term Type / term.type (do) field..

A person or institution can have one or more roles in their interaction or involvement with your collection (which is why the field is repeatable A field that is repeatable can have multiple occurrences. A book, for instance, can have more than one author: the Author field can be repeated as many times as necessary to capture all of the book's authors. Use the Occurrences options in the Record details View toolbar to add occurrences of a field.); a person can be a creator, publisher, borrower, etc. or might only be identified as having a role of person. Roles are important in Catalogue fields that link to the Persons and institutionsAuthority data source; many Linked fields A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). are configured to link to a specific domain so that only appropriate records can be linked to (the Creator field in a Object catalogue is configured to link to people with the creator role, for example).

Name variations

Managing variations in names has been improved. Previously, the Use (use (us)) and Used for (used_for (uf)) fields under Other forms of name on the Identification panel were used to record non-preferred / alternative versions of a name:

Each Use or Used for value is a Persons and institutions record in its own right, which can lead to a proliferation of records.

Now, a more intuitive and efficient Name variations group of fields is provided:

As before, Name (name (BA)) is the authorized form of the name, but now any variations are registered in the repeatable A field that is repeatable can have multiple occurrences. A book, for instance, can have more than one author: the Author field can be repeated as many times as necessary to capture all of the book's authors. Use the Occurrences options in the Record details View toolbar to add occurrences of a field. Name variations field group, notably Name variation (name_variation.name (vn); unlike before, these name variations are not recorded in separate records.

How does this affect searching and linking?

The Name variation (name_variation.name (vn)) field is indexed alongside Name (name (BA)) so that a search for a name variation will always locate the authorized name: if you enter a name variation in a search field in Persons and institutions itself or a field linked to Persons and institutions, the record with the authorized name will be located. For example, this Standard search in Persons and institutions will return the record for British Broadcasting Corporation:

When linking to a record, a name variation entered into a Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). will pull back the authorized name. Here we see the Persons and institutions for Jan Vermeer, with multiple name variations:

When linking to this record in the Catalogue and entering one of the name variations, the record for the authorized name is located:

and when selected, automatically replaces the name variation:

Contacts panel

Contacts is a new panel used for linking to other records in Persons and institutions where Name role (name.type (do)) = contact. It contains two groups of repeatable A field that is repeatable can have multiple occurrences. A book, for instance, can have more than one author: the Author field can be repeated as many times as necessary to capture all of the book's authors. Use the Occurrences options in the Record details View toolbar to add occurrences of a field. fields, Contacts and Contact for:

We use this panel to identify one or more contacts for an institution, or perhaps for another person.

Obviously, a person can be a contact for an institution, and a person can be a contact for another person, but an institution could also be a contact for a person, or another institution for that matter. To simplify the following description, we assume that a person is the point of contact for an institution.

In the Persons and institutions record for an institution, we link to the record for someone who is a point of contact using the Name (contact (Cn)) field in the Contacts table; this will copy over details from that person's record (name, address, phone number, email address, etc.). Here we see the Persons and institutions record for Axiell with a contact added to the Contacts panel:

Field	Details
Name / contact (Cn)	A Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). to Persons and institutions. Start typing the name of the person and select it from the drop list, or click the Link icon to display the Find data for the field box; search for the relevant person or create a record in Persons and institutions and link to it (if authorized to do so). Details about working with the Find data for the field box can be found here. In Display mode A record is either in Display mode (we view its details) or Edit mode (we add or edit its details). A record enters Edit mode as soon as we create a new record, copy a record in Record details View or edit an existing record., click the link to display the contact's Persons and institutions record.
Contact Type / contact.type (ct)	A Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). to the Thesaurus. Identify what type of contact the party is (e.g. staff member, family member, volunteer, etc.). Start typing a contact type and select it from the drop list, or click the Link icon to display the Find data for the field box; search for the relevant term or create a record in the Thesaurus and link to it (if authorized to do so).
Surname, Forename(s), Prefix(es) to surname, Title and Salutation	Values in these fields are retrieved from the target record A link is made from one record (the primary) to another (the target). dynamically each time the current record is opened.
All other details	Other details, including telephone numbers and email address, are retrieved from the target record A link is made from one record (the primary) to another (the target). when it is added to the Name (contact (Cn)) field; but subsequently these details are NOT updated dynamically if they change in the target record. These fields are editable; if they change in the target record, be sure to update them here.

In the target (linked) record, the Contact for group of fields is automatically updated with details of the party they represent:

Additional panels

Amongst other panels added to a Persons and institutions record in Record details View, you will find Actions, Digital references, and Free fields.

Personally Identifiable Information (PII)

Persons and institutions records may contain Personally Identifiable Information (PII), including birth and death details, ethnicity, gender, nationality, occupation, address details, email addresses, contacts, etc. Under the European Union General Data Protection Regulation (GDPR) guidelines for information privacy in the EU, this data can be regarded as sensitive information; accordingly, access to fields that may contain such data is now protected by access rights by default.

The Standard Model introduces a user management model out-of-the-box with a base set of predefined roles and permissions governing access to advanced and administrator functionality, as well as access to fields containing sensitive data and Personally Identifiable Information (PII), such as personal address fields and email fields.

Full details about the permissions model introduced with the Standard Model can be found here. In brief, two roles have been introduced to control read and read-write fields identified as PII:

PII writer / pii_writer
PII writer / pii_writer

When the Standard Model is installed, staff are assigned a role that matches their access level, ensuring that only people with clearance are able to view and / or edit sensitive personal information.

Thesaurus

Changed

Additional method for documenting alternative and related terms.

Details

An important Authority data source, the Thesaurus contains records of terms referenced by many fields throughout Axiell Collections. In the Relations fields we document preferred terms (Use / Used for), and a range of other relations between terms. Each of these alternative and related terms (Broader, Narrower, Related, Equivalent) is documented as a separate record in the Thesaurus linked to the appropriate Relations field:

In the Standard Model, along with the Relations fields, you will also find the Term variations fields. These provide another way to document the relationships between terms:

The Term variations fields are used in a similar way to the Name variations fields in Persons and institutions (described here). Term / term (te) is the preferred form of a term, but rather than using the Relations fields to document any alternative and related terms, these can be registered in the repeatable A field that is repeatable can have multiple occurrences. A book, for instance, can have more than one author: the Author field can be repeated as many times as necessary to capture all of the book's authors. Use the Occurrences options in the Record details View toolbar to add occurrences of a field.Term variations fields, notably Variation (name_variation.name (vn). Variation is a Text field, not a Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref)., and alternative and related terms documented here are not linked Thesaurus records.

It is suggested that the Relations fields are used where a term has sufficient history and usage to warrant a Thesaurus record in its own right (notably Use / Used for for preferred / non-preferred terms); if not, the Term variations fields may provide sufficient documentation for a term and its variations. In most cases, it is recommended that you do not use both methods to document the same term.

Details coming soon

Information below is extracted, unpolished, from preliminary release notes:

Data source	New or changed	Details
Deliverables and Access request items	New	These two new data sources are associated with the pre-existing Use of collections data source. The latter data source describes the overarching request, while the Access request items and Deliverables records act as Item records for each individual object either being accessed or reproduced in support of this request.
Entry	New	Movement and Shipping Logistics is used to document planned object movement, but items received unexpectedly can be registered using the Entry data source. A lot more details can now be registered, including information about the depositor, return instructions, and the temporary object number(s) assigned. If more detailed cataloguing is required, Catalogue records can be created via a zoom screen from within the Entry record.
Events	New	The Model Application 5.2 Events data source was specific to film life cycle events (when was the film produced, when published, any award ceremonies): this data source has been renamed to Film lifecycle events. The new Events data source is intended to document historic events (e.g. "D-Day", "1994 Winter Olympics") and internal institutional events (e.g. "Donor tour of conservation lab", "Fall 2024 Collections Committee Meeting", "School visit").
Film lifecycle events	Repurposed	The Model Application 5.2 Events data source was specific to film life cycle events (when was the film produced, when published, any award ceremonies): this data source has been renamed to Film lifecycle events. The new Events data source is intended to document historic events (e.g. "D-Day", "1994 Winter Olympics") and internal institutional events (e.g. "Donor tour of conservation lab", "Fall 2024 Collections Committee Meeting", "School visit"). Beyond general harmonisation with other Standard Model features, such as the introduction of a Record summary field, the Film lifecycle events data source is essentially unchanged from earlier application versions.
Incidents	New	Used to describe damage and loss incidents associated with one or more objects, containers, and/or locations. Because it is not object-specific or object-dependent, it can be used to more effectively document large scale incidents (like floods) which can impact multiple objects / containers. It can also be used to document problems in collections spaces (like pest sightings) even when no harm has been found to objects (yet), so that users can identify and address any patterns of incidents in certain locations. For each included object, users can directly link a condition assessment as part of their incident response. Additionally, the reporter(s), incident type(s), associated people, actions, and other details can be registered. Multiple photos and other media or documents of the incident can be linked as well.
References and citations	New	References and citations holds records of instances where one or more items in your collection, or the collection itself are mentioned in a publication or other unpublished work (books, journals, catalogues, websites, etc.).
Rights and Licensing	New	The rights and licensing functionality in the Standard model application has been extended substantially, geared towards the rights specialists in your organisation. The previous Rights screen tab (or screen section) with its fairly limited set of fields for documenting (copy)rights and any licensing for their use, has been replaced by a (Linked records) – Rights and licensing tab allowing you to reference one or more rights records and/or license records in the now separate Rights and Licensing data sources. (There’s no direct link between Rights and Licensing records.) Not all objects may need rights or licensing links, but for those that do, you can scale their registration up as much as needed. While this tab is available for all records in object and archive catalogues, note that for the Moving image catalogue and the Library catalogue, the Rights and licensing tab is only available at WORK and VARIANT level. This is because these record levels represent the conceptual work which is protected by intellectual property rights and licensing.

Data sources for (Application Administrators) managing the Collections application

One objective of the Standard Model is to further reduce reliance on Axiell Designer A tool for designing, creating, customizing and managing Axiell Collections applications and databases, broadly speaking, the Axiell Collections Model Application. As well as managing databases, including user access and permissions, Designer is used for such tasks as translating field labels, tooltips, values in drop lists, etc. for the configuration and customization of Axiell Collections. To this end, the System admin - occurrence defaults data source is introduced, and the Thesaurus has been expanded and split into two parts, Thesaurus and System lists. Authorized users are able to define and set default values in System admin - occurrence defaults; and in System lists they are able to manage lists of controlled values such as condition terms, method types, action types, fee activities, acquisition reasons, units, etc.

Access to these data sources is restricted to users assigned the $ADMIN role (typically Application Administrators).

Details

All new implementations of Axiell Collections now include the standard permissions model with predefined groups such as the Data reader (able to view records in most data sources The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on. but not edit them), the Data writer (able to view and edit records in most data sources), and Data administrator (with super-user access). Where appropriate, the base set of groups / permissions has already been applied to application objects; for example, the source.email (se) field in acquisition.inf already has read access rights for the PII reader group, write access for the PII writer group, full access for the Data administrator and no access rights for everybody else.

This approach simplifies the permissions model, tightens security by requiring users to be a member of at least one predefined group in order to access Axiell Collections, and eliminates the need to build a permissions model from the ground up as has been the case in the past.

It is anticipated that most groups already defined in systems that upgrade to the Standard Model will map to an equivalent in the standard permissions model. And, if necessary, custom groups can of course be added.

Note: The method for assigning users to groups in Axiell Designer A tool for designing, creating, customizing and managing Axiell Collections applications and databases, broadly speaking, the Axiell Collections Model Application. As well as managing databases, including user access and permissions, Designer is used for such tasks as translating field labels, tooltips, values in drop lists, etc. is unchanged (and Application Administrators with access to this tool will continue to use it). It is anticipated however that a user access rights management tool will be made available in Axiell Collections itself in a future release, further decreasing reliance on Axiell Designer for user and permissions management.

The groups and permissions defined in the standard permissions model are:

Note: Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc.

As the bottom row in the image above makes clear, a user cannot access Axiell Collections unless they are assigned to a group. The following is a summary of permissions assigned to each group:

Active directory group / Collections role	Details
Data reader / `data_reader`	A Data reader: can view but not edit records in most data sources The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on. ; cannot see fields with PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc.. If a Data reader should have permission to view PII, the user must ALSO be assigned to the PII reader group.
PII reader / `pii_reader`	This group is assigned to users in the Data reader group who should ALSO be able to view PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc..
Data writer / `data_writer`	A Data writer: can view records in most data sources and can edit those records; cannot see fields with PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc.; cannot delete records. If a Data writer should have permission to view PII, the user must ALSO be assigned to the PII writer group. Note: A Data writer does not have the import or search and replace permissions.
PII writer / `pii_writer`	This group is assigned to users in the Data writer group who should ALSO be able to view and edit PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc..
Data administrator / data_manager	A Data administrator has super-user access and: can access all data sources (including Occurrence defaults), but not all administration data sources (such as System lists); can view, edit, and delete records; can view and edit all PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc. fields; can import data and perform search and replace.
App administrator / `$ADMIN`	The `$ADMIN` role is assigned to Application Administrators, providing full access rights and administration control. Application Administrators can access all data sources. Permissions include: view, edit, delete, import, search and replace; unlocking read-only records for editing. Also have access to tools such as Purging saved searches; restoring records using Journal Maintenance, editing record level security on records, etc.
api_svcc_account	This role is intended for the API (not users) and gives view access to relevant data sources (Catalogue, Persons and institutions, etc.), but not to PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc. fields.

Application directory

With the Standard Model, the installation directory for the Collection's application is now always named \main; previously the name reflected the particular configuration of the Model Application installed, for example \xplus, \archive, \archive+museum.

Date validation

Validation of dates now occurs automatically in the following circumstances:

Future dates
Most date fields should not contain a future date and it is no longer possible to add a future date in most, though not all, situations (an expected end of loan date, for example, assumes a future date and is permissible). A message will pop up if a future date is entered in a field where a future date is not permissible:
Date range order
Two date fields forming a date range can no longer be in reverse order (the later date prior to the earlier date): an exhibition cannot end before it begins, for instance. A message will pop up if the dates are not in chronological order:
Auto-population of date ranges
Where implemented, if one date field in a date range pair (start / end; late / early) is empty, it will auto populate with the value in the other date field to save retyping in the many instances where the two dates are the same (if necessary, simply edit the auto-populated date field to change it).

Editing in Result set View and saving in Record details View

For the moment, it is not possible to edit a record in Result set View and, by default, the Edit Edit button is no longer available in the Result set View toolbar in the Standard Model. This change was introduced to ensure the integrity of your data as data entry in Result set View cannot be validated as effectively as it can in Record details View. Editing of records must now be performed in Record details View.

A consequence of this change however is that the Save button does not display in the Record details View toolbar (the Result set View edit functionality and Record details View save functionality are linked). Editing and saving of records in Record details View are both enabled by selecting the Edit Edit button.

Field tag standardisation

To ensure greater consistency across databases, field tags have been standardised so that identical fields now use the same tag wherever possible. This improves the portability of ADAPL Both a general-purpose programming language and a program built in the ADAPL language. An ADAPL program can be executed as a standalone program or used during various database functions, e.g. to validate data input, or to carry out an additional check during record deletion. code between databases and enables reports to be shared across data sources, even when the name of fields, actions, free fields, and instructions vary.

Improvements to the Change locations task

The Change locations task has been improved in a number of ways, including:

When a location is selected in the LocationLinked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref)., its full hierarchy is displayed in Context, which helps confirm that the correct location has been selected:
The Executor field is no longer automatically completed with the name of the logged in user; it is now a Linked field to Persons and institutions records where Role = mover.
Job number has been added to the Movement group of fields: Job number is useful when a movement project involves many smaller moves; by assigning the same Job number to the smaller moves, it is a simple matter to search for and locate all moves involved in the one movement project.

Guidance with using the task can be found here.

Media and digital file storage location

Previously, media and digital files were all stored in a \media folder (or \images folder in even older versions of Collections); now there is a sub folder under \media for every Collections database table: for example, the database table for all of the Cataloguedata sources The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on. is called collect, and there is a \media\collect sub folder.

When an image file is uploaded to reference_number (FN) in a record in the Media data source, the image file is saved to \media\media; when an image file is uploaded to media.reference (FN) in an Object catalogue record, a record is created for the image in the Media data source and this is linked to the Object catalogue record; the image file itself is saved to \media\collect in this instance.

The same is true for digital document files uploaded to File (digital_reference (RF)) on the Digital references panel.

Thumbnail images are stored in \media\imageCache by default.

Record statuses

With the Standard Model, record statuses are uniform across activity and process records (those found in data sources The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on. such as Events, Assessments and treatments, Loans, Collections audit, and so on), and they all feature a Status (current_status (sS)) drop list with a common set of values:

pending
pending approval
approved
open
suspended
completed
rejected
cancelled

Managing the Status of a collections management activity as it progresses through an approval's process from pending to completed (or cancelled or rejected) is key to managing the workflow of that activity. Every change to a record's status is automatically documented on the Status history panel, ensuring that a complete history, including who authorized a status change and when, is available.

As collections management activities affect items in your collection (an object is on loan or scheduled to be moved for instance), activity records are invariably linked to one or more Catalogue records or records in an Items data sources. These linked records are listed in the activity record on an Object list panel or suitably named Items panel (Loan items, Audited objects, etc.), and each has its own status (object.status (TS), loan_item.status (LS), exhibit_item.status (OS), and so on). It is possible to manage the status of each of these items in the activity independently from the status of the activity itself: for example, a loan may be approved, but four of five items requested are approved and one is rejected.

Tip: If the status of the activity and items should be the same, the Cascade status (current_status.cascade (sC)) checkbox in the activity record can be selected to cascade its status to all affected items (except where an item has a more advanced status than the activity record).

Legal status and Activity status in the Standard Model

In Model Application 5.2 and earlier the Management status (management_status (ms)) field located on the Identification panel in Catalogue records covers two essentially different types of status, activity statuses (in loan, for instance) and legal / ownership statuses (internal, for instance). In the Standard Model Management status is replaced by two distinct fields: Legal status (legal_status (os)) and Activity status (activity_status (sa)).

Legal status is a mandatory field and it relates to an object's legal standing in a collection (such as permanent collection, deaccessioned, external, and so on). It does not change frequently, and any change is tracked on the Legal status history panel.
Activity status relates to activities that affect the object, and include loan candidate, loan approved, on loan, deaccession candidate, and so on.

Replacing a single status field with two fields with distinct purposes allows you to document your institution's legal relationship with an object as well as the key processes potentially impacting that object’s legal status and/or availability.

Anyone with the appropriate access rights to edit a record can set Legal status when a record is created, but once the record is saved, Legal status can only be changed by users with the data_manager or $ADMIN role. Activity status can also only be modified directly by users with either of these roles.

Statuses of items in Acquisition, Deaccessions and Disposals, Entry, and Loans processes interact seamlessly with the Legal status and Activity status fields in the Catalogue. For example, when an item is being considered for an incoming loan and the Loan item record has a status of pending, the linked Catalogue record’s Activity status will display as loan in candidate. If the loan request is cancelled, the Activity status is cleared; if it is approved, the value will update to loan in approved. As the Loan item statuses are updated, the Catalogue record’s Activity status will update to in on loan and finally, returned to lender.

In the case of Acquisition and Deaccession records, the functionality is similar, but when marked completed in the activity, the Catalogue record’s Legal status updates to permanent collection or deaccessioned as appropriate.

Read only

When a record is finalized and should no longer be changed, select the Read only (record.read_only (zz)) checkbox on the Management details panel: this will make the record uneditable by anyone other than an Application Administrator (users with the $ADMIN role) and will ensure that the last assigned status remains unchanged. More details here.

The Reset record summary task

The Record summary (record_summary (Z0)) field provides an auto-generated summary of a record's key data. It is defined in the System admin - occurrence defaults data source, and is built dynamically by pulling data from other fields in the current record The record currently displayed in Record details View or highlighted (with a solid background) in Result set View or Gallery View for instance..

If the default value definition of Record summary is changed in the System admin - occurrence defaults data source, it may be necessary to run the Reset record summary task to update the value displaying in Record summary in one or more selected records: this will empty the Record summary field in the selected record(s) and rebuild the value using the updated definition in the System admin - occurrence defaults data source.

Note: Before Record summary (record_summary (Z0)) is changed, the Read only (record.read_only (zz)) setting in each selected record is checked: if it is enabled and a record has been set to read only, that record's record summary is NOT updated.

Other reasons to run the Task

Record summaries are not automatically updated when data in a linked record is changed, which means that they can get out-of-date. In some circumstances, it might be desirable to run the Reset record summary task. For example, in exhibitions and loans, item records are created at the beginning of the planning process, with further cataloguing often taking place at a later stage. When the cataloguing is complete, it might be desirable to run the Reset record summary task on the affected Exhibition item or Loan item records to update their summaries. It is important to understand that Record summary is not updated automatically because there are situations in which it should not be changed: perhaps when an exhibition or loan has taken place, the summaries should remain unchanged to provide a historical record of the object’s information at that time.

Tip: In this situation, it is advisable to select the Read only (record.read_only (zz)) checkbox in a record to ensure that it is not altered inadvertently.

To run the Task:

Mark Marking a record means selecting it by adding a tick to the record's checkbox in Result set View or Gallery View, and in Record Details View from Collections 1.15 onwards. One or more records can be marked and then actioned in some way (e.g. printed). one or more records in Result set View.
If no records are marked, the Task will run on the current record The record currently displayed in Record details View or highlighted (with a solid background) in Result set View or Gallery View for instance. only.
Select the Reset record summary task in the Result set View toolbar.
A pop-up will require you to click OK to confirm the reset of record summary for the selected record(s) or to cancel the process.
When complete, a Task summary will display.

The Standard Model

Release Notes for the Standard Model

Fields, panels and read-only records

New and changed fields

Output formats (reports)

New and changed panels

Data sources

Creating an Assessments and treatments record in the Standard Model

Packed objects (objects located in a container)

Fixed (unchanging) context

Chronological order

How does this affect searching and linking?

Additional panels

Personally Identifiable Information (PII)

Standard permissions model

Other changes

Other reasons to run the Task