Metadata
Introduction
Metadata is a general term referring to all information about an object (such as a workspace, folder, or document). The individual pieces of information are called properties. In iManage Work, the collective set of all properties is called metadata. The iManage Work system provides a large number of properties, so that by attaching enough properties to an object, your company can create a comprehensive picture about it. Properties help working with objects for the following reasons.
Trait |
Description |
Categorize |
You can precisely categorize an item. Each item can have one or more properties that specify associations. For example, you can set properties that indicate a document belongs to specific client, matter, jurisdiction, lead attorney, and billing code. This set of properties will allow you to precisely place and to file a document, for example. |
Search |
You can precisely search for an item. You can use any number of properties to craft a search that finds an item, or items, quickly and accurately. For example, a search can be broad, looking only for items with a specified Client tag, or all items with a specified lead attorney, regardless of client. The search can be more precise and include the Client, Matter, Jurisdiction, document owner, and/or modified after a certain date. For example, the Client property of one item might be Microsoft, and other one for Coca-Cola. This allows you to do searches using Clients equaling Microsoft. |
Security |
You can assign security privileges to individual items (like a document) based on specified properties. Also, properties can be automatically assign security privileges to entire folders, groups of folders, and workspaces. |
The following topics are available:
Properties
A property is an individual piece, or field, of information that is attached to an object. For example, metadata about a Microsoft Word document is the set of properties that include the file name, the date the document was created, who last modified it, its location on the computer or iManage Work system, and who has access to it, the client and matter the document is assigned to, the billing code, and the responsible lawyer, among other properties. Some properties may be less obvious like its document number, and some may never be intended for users to see, but are required internally for the iManage Work system. Properties have the following characteristics: Value, type, and captions.
Value
The value is the data assigned to the property. Each property can only contain one value. The value assignment method (how the value is assigned to the property), and type of value (string, date, or boolean, for example) that may be assigned to the property is defined individually for each property. The following are the value assignment methods.
Method |
Description |
User assigned, validated value |
The user selects a value from a list of predefined values. Each list item has been previously validated as an acceptable value. For instance, the property custom1, perhaps captioned as Client, must have a list of choices previously defined for a user to assign a value to this property. The user can change the client, but it has to appear in that drop down list. See Validated list choices. The following example shows the validated list of possible client values.
Selected users, mostly iManage Work system administrators, can add, delete, or modify items to a validated list. Items might also be added when creating a workspace. |
User assigned, non-validated value |
The user assigns a non-validated value directly to a property. An example of string type user assigned, non-validated property is a document's file name. When saving a document, the user enters a name, and that name is stored as a property. |
System assigned |
The iManage Work system automatically assigns a value a property. System assigned properties are those required by the iManage for maintaining the history and nature of the object. For example, documents have a create date and a last edit date. Those are automatically assigned to their properties, and cannot be changed. Automatically assigned properties cannot be edited, either by users or iManage Work system administrators. |
Type
Each property has a data type that dictates the content of the value that can be stored for that property. The following is a list of property types:
Type |
Description |
Non-validated string |
This is a free-form character string. The length may vary based on the the specific property. Users can enter any valid characters within the supported language character set. Special characters, such as periods or asterisks, may be restricted. For example, strings are limited in length, perhaps as short as a single character or up to 8000 characters. They may also restrict the use of spaces, or special characters. See the documentation provided with the field for more information. |
Validated string |
This is a string field where the user must choose from a lookup list of previously provided valid values. The actual type of each value is dependent on the property and validating the entered value is done at the time that value is entered. |
boolean |
This has one of two possible values. Typically, these values are true/false or yes/no. The value pairings may display with different labels such as enabled/disabled, or as a check box option, either checked or unchecked. The documentation may point out that the omission of a field could have a meaning. See the documentation provided with the field for more information. |
datetime |
This is date and time information. Dates are usually system assigned, such as the send date for an email. It can also be used for a search, such as a document search, although if using a client interface, a calendar pick list may be displayed. The iManage Work system uses the ISO 8601 date format such as2017-09-18T00:00:00Z. This is a valid format within ISO 8601 but may not be familiar to all users. |
int |
A numeric value for whole numbers. Any restrictions and data ranges will be displayed for each property. |
double |
A numeric value for whole numbers and decimal numbers. Any restrictions and data ranges will be displayed for each property. |
Captions
The caption (also called a label or name) provides a mechanism to apply a meaningful name to properties. All properties have a default caption. Some are descriptive (like last_user, or checkedout) and others are intended to be changed by the organization after installation (like for custom1, or custom2). Any of these names can be changed to more meaningful or appropriate ones. Take for example cu stom1. Its internal name is of course custom1 but many iManage Work deployments change it so it is captioned as Client . This caption would then always be associated with that property, and displays in iManage Work clients, and search panels, as Client.
The following table shows examples of custom fields for two industries.
Table: Common Examples for Custom Tables
Property |
Non-law firm/non-legal uses |
Law firm/legal uses |
Notes |
Custom1 |
Client or Business Unit |
Client |
These are common examples for custom1. |
Custom2 |
Project or Engagement |
Matter |
These are common examples for custom2. |
Custom3 - Custom12 |
Billing Attorney. Corp Department, Industry, Jurisdiction, Legal Department, Matter Type, Office, Outside Counsel, Party, Retention Code, Retention Policy, Status |
Because each company has different ways of organizing their data, there are few typical cases for custom3 through custom12. The examples included here are common captions but their assignment to a property is decided by each company individually. |
|
Custom29 |
Practice |
Practice |
These are common examples for custom29. |
Custom30 |
Sub-Practice |
Area of Law |
These are common examples for custom30. |
The most important captions are for properties custom1 through custom30, and follow these guidelines.
Property |
Data type |
Length |
Description/notes |
custom1 |
Validated string |
32. Alphanumeric: a-z, A-Z, 0-9. Standard special characters allowed: *().&-_[]`~|@$%^?:{}!',\#+<>;"= Spaces allowed: No. Unicode allowed: Yes. |
Custom1 and custom2 have a parent/child relationship; see Parent child relationship. |
custom2 |
Validated string |
32. Alphanumeric: a-z, A-Z, 0-9. Standard special characters allowed: *().&-_[]`~|@$%^?:{}!',\#+<>;"= Spaces allowed: No. Unicode allowed: Yes. |
Custom1 and custom2 have a parent/child relationship; see Parent child relationship. |
custom3 |
Validated string |
32. Alphanumeric: a-z, A-Z, 0-9. Standard special characters allowed: *().&-_[]`~|@$%^?:{}!',\#+<>;"= Spaces allowed: No. Unicode allowed: Yes. |
|
custom4 |
Validated string |
32. Alphanumeric: a-z, A-Z, 0-9. Standard special characters allowed: *().&-_[]`~|@$%^?:{}!',\#+<>;"= Spaces allowed: No. Unicode allowed: Yes. |
|
custom5 |
Validated string |
32. Alphanumeric: a-z, A-Z, 0-9. Standard special characters allowed: *().&-_[]`~|@$%^?:{}!',\#+<>;"= Spaces allowed: No. Unicode allowed: Yes. |
|
custom6 |
Validated string |
32. Alphanumeric: a-z, A-Z, 0-9. Standard special characters allowed: *().&-_[]`~|@$%^?:{}!',\#+<>;"= Spaces allowed: No. Unicode allowed: Yes. |
|
custom7 |
Validated string |
32. Alphanumeric: a-z, A-Z, 0-9. Standard special characters allowed: *().&-_[]`~|@$%^?:{}!',\#+<>;"= Spaces allowed: No. Unicode allowed: Yes. |
|
custom8 |
Validated string |
32. Alphanumeric: a-z, A-Z, 0-9. Standard special characters allowed: *().&-_[]`~|@$%^?:{}!',\#+<>;"= Spaces allowed: No. Unicode allowed: Yes. |
|
custom9 |
Validated string |
32. Alphanumeric: a-z, A-Z, 0-9. Standard special characters allowed: *().&-_[]`~|@$%^?:{}!',\#+<>;"= Spaces allowed: No. Unicode allowed: Yes. |
|
custom10 |
Validated string |
32. Alphanumeric: a-z, A-Z, 0-9. Standard special characters allowed: *().&-_[]`~|@$%^?:{}!',\#+<>;"= Spaces allowed: No. Unicode allowed: Yes. |
|
custom11 |
Validated string |
32. Alphanumeric: a-z, A-Z, 0-9. Standard special characters allowed: *().&-_[]`~|@$%^?:{}!',\#+<>;"= Spaces allowed: No. Unicode allowed: Yes. |
|
custom12 |
Validated string |
32. Alphanumeric: a-z, A-Z, 0-9. Standard special characters allowed: *().&-_[]`~|@$%^?:{}!',\#+<>;"= Spaces allowed: No. Unicode allowed: Yes. |
|
custom13 |
string |
96. Alphanumeric. Standard special characters. Spaces allowed. Unicode allowed. |
If email, this is the From sender's name. If a document or folder, this can be used for your custom requirements. |
custom14 |
string |
96. Alphanumeric. Standard special characters. Spaces allowed. Unicode allowed. |
If email, this is the To recipient's name. If a document or folder, this can be used for your custom requirements. |
custom15 |
string |
96. Alphanumeric. Standard special characters. Spaces allowed. Unicode allowed. |
If email, this is the CC recipient's name. If a document or folder, this can be used for your custom requirements. |
custom16 |
string |
96. Alphanumeric. Standard special characters. Spaces allowed. Unicode allowed. |
If email, this is the BCC recipient's name. If a document or folder, this can be used for your custom requirements. |
custom17 |
double |
0 - 1059 |
This field can be used for your custom requirements. |
custom18 |
double |
0 - 1059 |
This field can be used for your custom requirements. |
custom19 |
double |
0 - 1059 |
This field can be used for your custom requirements. |
custom20 |
double |
0 - 1059 |
This field can be used for your custom requirements. |
custom21 |
datetime |
ISO 8601 format. It must be in one of these two formats: 2020-09-18T00:00:00Z 2020-09-18T00:00:00+6:00 |
If email, this is the Sent date. If a document or folder, this can be used for your custom requirements. |
custom22 |
datetime |
ISO 8601 format. It must be in one of these two formats: 2020-09-18T00:00:00Z 2020-09-18T00:00:00+6:00 |
If email, this is the Received date. If a document or folder, this can be used for your custom requirements. |
custom23 |
datetime |
ISO 8601 format. It must be in one of these two formats: 2020-09-18T00:00:00Z 2020-09-18T00:00:00+6:00 |
This can be used for your custom requirements. |
custom24 |
datetime |
ISO 8601 format. It must be in one of these two formats: 2020-09-18T00:00:00Z 2020-09-18T00:00:00+6:00 |
This can be used for your custom requirements. |
custom25 |
boolean |
true|false |
This field can be used for your custom requirements. |
custom26 |
boolean |
true|false |
This field can be used for your custom requirements. |
custom27 |
boolean |
true|false |
This field can be used for your custom requirements. |
custom28 |
boolean |
true|false |
This field can be used for your custom requirements. |
custom29 |
Validated string |
32. Alphanumeric: a-z, A-Z, 0-9. Standard special characters allowed: *().&-_[]`~|@$%^?:{}!',\#+<>;"= Spaces allowed: No. Unicode allowed: Yes. |
|
custom30 |
Validated string |
32. Alphanumeric: a-z, A-Z, 0-9. Standard special characters allowed: *().&-_[]`~|@$%^?:{}!',\#+<>;"= Spaces allowed: No. Unicode allowed: Yes. |
Profiles
A profile is a defined subset of properties associated for an object. Each organization can decide the set of properties they need for their profiles.
Class and subclass
Class and subclass are two related properties that define types of documents and folders (but not workspaces and matters). Neither property can be renamed. All documents and folders are required to have a class property although a subclass is optional.
The class defines the type or the use of the object. For example, a class might be named Agreements. To further differentiate an kinds of agreements, that class may have two subclasses, Memorandum of Understanding and Master Service Agreement.
Validated custom fields
The term validated custom fields, or commonly as custom fields, refers to any property that requires a predefined list of choices from which to make a value selection. Commonly, this references specifically to 14 properties named by default as: Custom1, custom2, custom3, cus tom4, cus tom5, cus tom 6, custom 7, custom 8, custom 9, custom 10, custom 11, custom 12, custom 29, and cus tom30. Two of property pairs, custom1/custom2 and custom29/custom30, have parent-child relationships; see Parent-child relationship.
Parent-child relationshipValidated list choices
The value assigned to a custom field is chosen from a predefined list of values. The user selects from a drop-down list to pick the value, and iManage system administrators can add and delete choices. By restricting this to a list, it ensures that the value is properly formatted, spelled correctly, and is an approved, or validated, choice.
Two pairs of custom fields have a parent-child relationship: Custom1/custom2 and custom29/custom30. All four custom fields are validated list choices properties. That is, the user selects from a drop-down list from the client to pick the value, and iManage system administrators can add and delete choices. However, the child value is itself a validated list choice property, which is related to the parent value, and is used in association with its parent property. For example, if custom1 is Client and is assigned a value of eDiscovery, then custom2, perhaps called Matter, may have several choices such as Purchase Agreement, and Mining Rights. This relation is similar to other custom fields and class/subclass, just that custom2 and custom30 are properties. You may assign an object a custom1 value but not necessarily a custom2. You may never assign an object a custom2 value without also a custom1 value.
iManage Control Center does not directly show custom2 or custom30 entries. To see those, select from among the entries for custom1 or custom29.
Property attributes
Properties have attributes. These are additional information that define the behavior of the property. For example, all properties have a name-related attribute, such as a name or alias. Other properties may have additional attributes. For example, a custom1 property also has a Enabled status (Yes/No), and a HIPAA Compliant status (Yes/No). It has a Description (a friendly explanation of what the property is used for) but that description is itself a property.
Figure: Custom1's attributes.
Attributes cannot be used in searches. For example, you cannot search for HIPAA Compliant objects. However, some attributes may be used to filter a search result. In a search results page, one option may be to filter the list based on an attribute. For example, in iManage Control Center, you can filter the results based on the HIPAA Compliant status.
Comprehensive Example
The following comprehensive example shows a property's use from first being initialized through to a client using it.
Initially, all the property fields will have default names. The iManage Work system administrator can change the property names, called captions, to meet the organization's requirements. In the example below, the property custom1 has been changed to Client, and property custom2, to Project/Matter. In iManage client applications these properties automatically display as Client and Project/Matter.
Figure: Captions panel in iManage Control Center
The Client property list has been populated with values. In the case of Client, each value is itself another property, as Project/Matter.
Figure: Custom1 properties list in iManage Control Center
Selecting a Client, for example Enron Corporation, alias 1000, from the previous sample, shows the values available.
Figure: Custom2 from custom1 (Enron) properties list in iManage Control Center
These values display in the iManage Work clients, here with Work for Web.
Figure: Properties selection from a search form in iManage Work Web client
For example, during a document search, the user can select the Client, and Project/Matter as search criteria. Item 1 shows that Enron Corporation has been selected for the Client value, and item 2 shows the available list of values (as listed in Figure Properties selection from a search form in iManage Work Web client). The user may select from that list.