Metadata

You can store metadata with a document that is stored in the content management system (CMS). By default, any CMS that supports Content Management Interoperability Service (CMIS) must save part of the cmis:document metadata for all files. Typically, the front end of a CMS highlights only the document title of the system metadata. However, the rest of the document is usually accessible.

Attachment metadata

When CMIS is enabled in Social Program Management, by default metadata is stored for all Social Program Management attachments. You can update custom attachment integration points to use the CMISAccess API functions to store and modify extra metadata properties with a file that is stored in a CMS. Attachments are stored as class type CuramAttachment. The class type CuramAttachment is a subclass of CuramDocument. The subclass CuramDocument is a subclass of cmis:document. Pro forma communication attachments are stored as CuramDocument. Pro forma communication attachments do not support metadata.

Metadata properties

Metadata is stored for all attachments, including attachments that are associated to recorded communications and to Microsoft Word communications. By default, you can store 10 metadata properties. The following class type tree lists the metadata properties:

cmis:document
- CuramDocument
  - CuramAttachment
    - caseReference
    - communicationDate
    - documentReceiptDate
    - documentType
    - documentTypeCode
    - participantDOB
    - participantFirstName
    - participantLastName
    - participantReference
    - applicationReference

Administrative users can enable or disable the storage of individual metadata properties. When administrative users enable or disable a metadata property, the change applies to all attachment integration points. The metadata that is stored depends on the attachment business flow. For example, where the case reference metadata property is enabled the following list outlines the effects:

The property is stored as metadata for a case attachment created within an integrated case.
The property is not stored for a participant attachment that is created for a person because it is not relevant.

Metadata descriptions

The following table describes each of the 10 default metadata properties. The table includes information about when and how the metadata is stored.

Table 1. CMIS metadata descriptions
Metadata element	Description
Case reference	Case reference is the case reference number of the case where the attachment, recorded communication, or Microsoft Word communication is created, if created within a case. For example, if an attachment is created within a service plan, the case reference of the service plan is stored. The case reference of the case where the service plan was created is not stored.
Participant reference	Participant reference is the participant reference number, which is stored as the primary alternate ID for the participant. The participant reference number is stored for all participant attachments and for attachments that are created in other contexts. For example, participant reference numbers that are created within a case where the attachment business flow permits the user to select a specific participant while the user creates the attachment.
Participant first name	Participant first name is the given name of a participant, which is stored as part of the primary alternate name for the participant. The metadata property is stored only for person and prospect person type participants.
Participant last name	Participant last name is the surname of a participant, which is stored as part of the primary alternate name for the participant. The metadata property is stored only for person and prospect person type participants.
Participant date of birth	Participant date of birth is the birth date of a participant. The metadata property is stored only for person and prospect person type participants.
Document type	Document type is the type of document, as captured in the Document Type field when the system is creating an attachment. The metadata property is stored for all attachments where the information is stored in the application database. The metadata property is not stored where a particular attachment business flow does not capture the information.
Document type code	The document type code is the code for the document type, as captured in the Document Type field when the system is creating an attachment. The metadata property is stored for all attachments where the information is stored in the application database. The metadata property is not stored where a particular attachment business flow does not capture the information.
Document receipt date	Document receipt date is the date that the document was received, as captured in the Receipt Date field when the system is creating an attachment. The metadata property is stored for all attachments where the information is stored in the application database. The metadata property is not stored where a particular attachment business flow does not capture the information.
Communication date	Communication date is the date of the communication to which the attachment is associated. The metadata property is stored only for attachments that are associated to recorded communications.
Application reference	Application reference is the reference number for the application case.

The metadata that is modified is determined by the attachment business flow and the data that is stored as metadata that can be modified in the application. For example, for integrated case attachments, the document type for the attachment can be modified in the application. Where the document type for the attachment is modified, it is modified in the CMS. However, the case reference of the attachment can't be modified. If an attachment record is initially created without an associated file, initially no file or metadata is stored in the CMS. However, if the attachment is then updated and a file is associated, then all metadata elements that are enabled and available are stored with the file in the CMS.

You can also set up a custom implementation by using the new APIs that includes extra metadata properties.

Note: The infrastructure updates the file content only if the content changed. The infrastructure updates the metadata properties only if the properties are supplied.