What is Profile Validation?
By using validation tables (lookup tables) for profile fields, cabinet members are able to select only the values predetermined by a firm, such as a list of clients for the Client field, authors for the Author field, etc. This makes it impossible for a user to profile a client document with 'ABC' as the client name and another user to profile a document with 'ABC Corp' as the client name. By using custom profile values, tagging and searching for documents using a "pick list" of names becomes a simple, yet powerful option.
Important Considerations for Administrators
- Administrators can create custom profile attributes that use lookup tables for validation. In addition, profile attributes can be linked in a parent/child relationship. For example, suppose the administrator created two custom fields – Client Name and Matter with Matter being linked as a the child to Client Name. The administrator has also created a lookup table that defines matters related to each client name. Hence, if a user selects ABC Corporation from the Client Name lookup table, because the user selected ABC Corporation, the Matter field lookup table will show only matters related to ABC Corporation.
- Each profile attribute that has been defined to use a lookup table requires a unique, uploaded file. One exception is where an attribute is linked to another. For example, if you have two profile attributes, Client Name and Matter, you will need to upload a data file for Client Name and another file for Matter. However, if you defined Matter to be linked to Client Name, you will use a single data file with two lookup tables in different columns.
- Data files often will have more than 100 records. If the file contains fewer than 100, the profile field uses a dropdown box listing all these entries. If the table contains more than 100 values, the lookup button will display as a "…" button and will require the user to enter a lookup criteria; no entries will appear. So the user will need to enter a number or letter for a list of entries to be displayed. Entering an "L" will display all table entries, up to 100, that begin with "L" but no others. All entries will appear without a search only if there are 20 or fewer entries. This is done for performance reasons where some firms have tens of thousands of entries to select from.
- Lookup table values can have descriptions. Description column values are NOT indexed for searching. However, NetDocuments will include the description following the actual field entry. So if an entry is ABC Corporation and the description for this entry is XYZ Parent Company, the field will display ABC Corporation – XYZ Parent Company for the Client Name field. This may mislead one to think that entire string is searchable, but only the ABC Corporation portion is indexed and can be searched.
- Lookup tables can be initially uploaded from data files in a comma-delimited ASCII format. Tab-delimited files are not accepted. Commas may be used in row values. If you use a text file and you have commas in your values, you will need to use quotes. For example, if your lookup value will be Doe, John, your text file will need quotes around it, otherwise, John will be considered part of a second column. Use "Doe, John" to include a comma in the value.
- Under Sample Tables are several sample files to help you prepare the Profile tables to upload to NetDocuments. These files are already defined as CSV files. Just use them to add your own data. FYI, for smaller tables, you could use NotePad, but for consistency, we recommend that they all be CSV files created using Excel.
- A profile attribute can be designated such that only Internal Users can see all of the values in its lookup table. When editing the attribute select the "Hide lookup table from external users" check box.
- We do not support using the operators 'AND' 'OR' and 'NOT' in lookup tables.
Administration of Custom Profile Fields with Validation Tables
- Define custom field names and select the lookup table option for those that require validation.
- Create a comma-delimited data file containing lookup values.
- Upload the document through the Define Profile Attributes page. After starting this process, the user will be sent an email when the upload has completed.
Creating Upload Files
A data file for a profile attribute can have several columns of information, each used for different purposes. Only one column is required. Values in the first column of the table are unique "keys" that identify the value. The key and description are what users see when looking up a Client when editing a document's profile. The Key is the only column that is indexed for searching. Values in the second column, if used, provide a description for the indexed values in the first column. This is optional and the values are not indexed for searching. A third column option is to flag inactive or 'Closed' records (explained below).
Example Data File of a Profile Attribute Named "Client":
Note the description column header must use the Custom Attribute name followed by either "2", " Desc", as shown above, or “Description”.
Creating Upload Files with Linked Profile Attributes
Here is the upload file format for uploading “linked" Profile Attributes. Prior to uploading this file you will need to go into Repository Administration > Define Profile Attributes and link the child to the parent, like Matter to Client. Your upload file will have between 2 – 5 columns, see examples below. The “Closed” column is optional. If descriptions are included and the file is created in Excel, it would look like this:
Example Data File for Linked Profile Attributes
The file can be created in Notepad with no descriptions. If so, remember there has to be a comma after the first heading and also after each value in the first column and also the column headings have to be spelled exactly the same as you spelled your Profile attributes. Your Notepad file can be named anything.
Example Data File for Linked Attributes Without Descriptions
Creating Upload file with Profile-Based Security
Learn more about Profile-based Security (PBS)
The ACL always needs to be in all upper-case. Make sure the profile attribute has been configured for profile-based security on the specific profile field. The more common Profile attributes on which security is based is Matter or Author. Prior to implementing Profile-Based Security you will need to map out your scenario to make sure what you want to implement will work in your environment.
Example Data for Profile Based Security:
See our Sample Lookup Tables for more information.
Things to remember when using Profile-based security:
Rights inheritance from folders – If you use Profile-based security, we do not recommend that you check the Cabinet Administration box for "documents to inherit rights from folders". If you do this, whenever a document is moved to a folder, the rights will change to that folder, even after the Profile-based security rights have been applied.
Cabinet No Default Access – We suggest that when using Profile-based security, that you make the cabinet default for the groups who have access to the cabinet, have either "No default access" or perhaps "View" access. When a Profile-based value is entered for a document, the cabinet default is not removed. If you have set all of the default groups to have "no default access" then any rights they are given using a Profile-based security value will take precedence.
"No Access" Rights - When you give a user or group "No Access" rights for a document or a folder, using the Profile-based security, the No Access will trump any other rights they may have been given.
Absolute Rights - When using Profile-based security as described above, it is "additive" to the cabinet default or whatever the security is currently set to. You can also use an absolute security model, which will change what is there and replace it with the new absolute security. For each row in your table where you want to use absolute security, precede it with an exclamation mark as follows: !Finance|VES*Legal|V*U:email@example.com|VES.
NOTE: Profile-based security will not apply to existing documents, workspaces, or folders. It will only affect items that are profiled after the security is set.
Inactive (Closed) Records in Lookup Tables
Suppose your firm closed a matter for a client. The client's documents related to that matter will still exist in NetDocuments, and are profiled with that matter name, but no new documents will be added to the matter. To keep documents profiled for inactive matter names and to search on those matters again for future reference, administrators should leave all closed matters in the lookup table. Inactive values remain available for searching but are no longer listed in lookup tables when editing a document's profile or creating a new document. Do this by flagging the matter line as inactive using the syntax shown in the table below.
This can be done through the online table editor, or by uploading a date file, such as through ndLink.
In the online editor, the Closed field takes a date value:
The value will be closed (inactive) as of the date that is specified.
To flag inactive records through an upload file, add another column heading to the data file using the configurable attribute name with [Closed] appended to it. For example [Matter, Matter Closed]. NetDocuments stores the closed column as a date. If the column data begins with a date in either M/D/YYYY or YYYY-M-D format, that specific date is used. If the column data does not begin with a recognized date, the current date is recorded (at the time of import) if the column contains “true”, “y”, or “yes” and record an empty value otherwise. (This supports source data systems that only record a Boolean open/closed value rather than a closing date.)
To Upload your Data File:
- From the Repository Administration page, click on Customize profile fields
- Click on Upload lookup tables
- Select whether the data file is an Update, Delete, or Replace type file. If uploading a file for the first time to an empty lookup table, choose Replace.
- Locate the data file by clicking on Browse…
- Choose OK. When the upload has completed, the user will be sent an email confirming that the upload completed.
Incremental Lookup Table Updates
Once the original table has been loaded only the changes are required to be uploaded going forward. In that case, you would use the Update option to incrementally update the table information. The process is the same as when initially uploading the file except you would select "Update". Selecting Update will only add new Profile data and modify any existing profile data as outlined in the upload file.
Delete Lookup Table Data
The process is the same as updating the lookup table except you would select “Delete.” Selecting delete will delete all the profile data for the profile fields in the upload file.
Rules for Validation Table Files
Data files must begin with a header row containing the column names. The column name for the primary column is the name of the custom attribute. A secondary column name is the same as primary column names with either “2”, or “ Desc” appended to it. These are mandatory options. No other heading is acceptable.
NOTE: Description text is NOT indexed, therefore not searchable from the Advanced Search page.
NOTE: After an administrator has enabled the lookup table for profile fields and uploaded the validation tables for the first time, users will need to log off and log back in to see the changes. Subsequent lookup table uploads are real-time and do not require this. However, if the administrator turns off the use of a lookup table for the custom field, and then turns it on again later, users will need to log off and then on again to see the validation tables.
Upload Time Benchmarks
Upload time will always vary based on your connection speed and the reliability of the bandwidth provided by your service provider. Our tests over a T1 line consistently show that a 50,000 line text file will take between 10-15 minutes from start to finish.