Repository Administrators have the option to create custom "Profile Attributes" or metadata fields. These fields are used to "profile" or "tag" documents as they are imported into the system. The main purpose for Profile Attributes is to simplify searching, but you can also use them to organize documents within Workspaces.
To create new Profile Attributes or to modify existing attributes you can go to Admin > Define Profile Attributes. Click Add to add a new Profile Attribute. Click Edit to edit an existing profile attribute.
There are a few different types of attributes that you can create, but once a Profile Attribute has been created and used, we recommend that you do not change the Type.
You can create attributes with the same name, but all attributes that share a name must also be the same Type. All other settings can be different between the attributes (e.g. one may use a lookup table, while the other does not).
Here is a description of the different Types of fields:
A Text type field is a simple free-form field that you can type any number or word in. You can set a maximum character length up to 50 characters in a Text field.
A Text type field can be linked to another field or can "Default from" another field (you can read more about Defaulting below).
Using Lookup Tables (profile validation)
You can set a Text type field to use a Lookup Table. With this enabled, the field will become a "pick list" (rather than a free form field) where users will be given a drop-down menu or a "Lookup" that will allow them to select a specified value. The values in the Lookup are defined by the Repository Administrator. When you set the field to use a Lookup table there are additional options to Hide the lookup table from External Members and to Base security on this attribute. Learn more about profile-based security.
With a Text type field you can make the field Required by checking the "Prompt if Empty" checkbox. With this checked, when users import documents they will be prompted to fill out the field.
"Force Uppercase" will force users to enter values in upper case. This is typically used when the text-type attribute does not have a lookup table.
The "Extend table values to" option lets you pad the values with leading zeros. For example, if you are creating an "Account Number" field and all of your account numbers are 5 digits, you can enter a number 5 in this field and it will automatically add leading zeros to the numbers if they are under 5 digits long.
The "Read-Only" option will make it so that the field cannot be changed once it has been filled out.
A Numeric type field is very similar to a Text type field, the difference being that it will only allow numbers to be entered as values.
A Date type field will only allow a date to be entered in m/d/yyyy format.
With a Date field, you have the option to default the value to the Current Date. Also, when users are entering values in a Date field, they will be shown a calender that they can pick dates from:
A Notes type field is a longer free-form text field (like a comments field) that you can use to enter entire sentences or paragraphs.
Linking Profile Attributes
You can link two attributes together in a parent-child relationship. For example, a Client may be associated with several Matters. The Matter attribute can then be linked as a child of the Client attribute.
This means that a matter must belong to one and only one parent value, but a parent value (client) may have several child values (matters).
There are two types of dependencies you can enable for a given attribute:
You can chose to default a profile value from another profile. To do this, you must define a type column in another table to use as a default. So if you wanted to have an Office field associated with an Author field, you could upload Office values into the Type column in the Author lookup table. Set Office to default from the Author type field. When an Author is selected while profiling a document, the default Office value would be entered automatically.
Similar to 'default from', this forces a value into the dependent field, rather than setting a default value that the user can change. For this reason, 'Determined by' attributes do not have lookup tables.
There may be scenarios where you want different degrees of dependency for different sets of attributes.
The ‘default from’ option does not force the user to select a certain value, and the defaulted value is not updated when the determining value is changed. For example, if Practice Area defaults from Matter, and a document’s Matter is changed, the Practice Area value is not automatically updated. Or, the user can change the Practice Area at any time without having to change the Matter.
‘Determined by’ goes a step further and forces a link between two values. For example, Office may be determined by Author (because an author/user only belongs to one office/location at a time). When the Author is changed, the Office is also changed automatically. Conversely, the Office cannot be changed unless the Author is also changed. Thus, the two values are inseparably connected.
So, you could create a template for each practice area, then have the practice area determined by Matter. The value in the Matter Type column (which is both the template name and the practice area value) would be automatically assigned to the documents as usual, only the user would not be able to change it after the fact, unless the Matter was also changed.
‘Determined by’ attributes are supported in ndOffice.
One potential drawback is that the determined attribute (Office in the first example) cannot use a lookup table, so in some cases someone searching by that attribute may have to know the exact value beforehand in order to get an accurate result. For example, a firm may have offices for Portland, ME and Portland, OR and so a search for just portland would return items assigned to either. Or, a search for New* would return items assigned to either New Orleans or New York.
Because of this, it also does not have a ‘lookup’ function to allow you to browse the lookup table to see all existing values. You’d have to go directly to the determining attribute’s table and visually browse the Type column, or download the table and filter on the Type column.
‘Determined by’ attributes also cannot be a parent or child to another attribute. If Practice Area is determined by Matter, then Document Type cannot be linked as a child to Practice Area.
Profile-based security also cannot be used on the ‘determined by’ attribute, although it can on the determining attribute. All other attribute-level settings are irrelevant for ‘determined by’ attributes.
If the determining attribute is enabled for multi-value profiling, the 'determined by' attribute will be determined by the primary value (the first value in the list).
ndImport does not respect the ‘determined by’ setting. It will take whatever value you supply.