Each document saved to PIQNIC has to be associated with a document class. Definition of at least one document class is therefore required to enable the system to store documents.

This is why configuration of all aspects of the document repository starts with selection of a document class (drop down list at the top of the screen).

Class definition 

Document classes in PIQNIC have the following configuration details:

Name

This is a unique reference used across the platform to link higher level objects like Save Profiles and Searches to appropriate document class definition.

This is complemented with description. 

Primary storage volume

 All documents stored in a selected document class are physically stored in the selected storage volume, unless determined otherwise by storage policies. 

Storage volumes are locations used for physical storage of documents. They are covered in more details in the Storage section. 

Automatically purge deleted files

The system has two-stage delete capability – delete and purge. 

This setting automatically purges all deleted files after X days. 

User can enter number of days or select “Immediately” or “Never”.

Document fields

Defined by name, type, size, and default value they provide placeholders for metadata stored with documents saved against this class.

Document metadata

The main feature of a document class is a collection of properties (called metadata fields or document indexes) that will be populated when a document is ingested into the system and changed throughout the document lifecycle. 

Their main purpose is to provide a meaningful and comprehensive classification of a document within the repository. 

Document metadata is used for a number of activities in the system: 

• In searches to provide access to documents.
• In access policies to implement security. 

Our strategic intention is to use document metadata whenever possible to introduce necessary granularity in the system functions where the scope of the function will be controlled very precisely by examining metadata values of saved documents. 

In addition to user-defined metadata fields, each document class contains a set of common system metadata fields that are populated and managed by the system. These fields are available to all tools using document metadata (Search, Save Profiles, Access policies, etc.) and are generally read-only unless specified differently. 

Flexibility of Save Profiles and Searches, as the entry/exit points for documents in PIQNIC, allows document classes and their fields to be defined in a generic and broad way. That minimises the number of document classes typically required in PIQNIC, without sacrificing any flexibility and efficiency.

To assure integrity of the repository, not all document class properties can be edited once the class is created:

• Name cannot be changed.
• Description can be changed.
• Primary storage can be changed. When saved, files saved to the document class will be written to a different volume. This does not affect files saved up to that point (no files are migrated). 
• Keep deleted files can be changed. As with the previous setting it only applies a day forward. 

When a new document class is saved, the system automatically creates the following objects: 

• Search that includes free user prompts for all class fields.
• Save Profile that includes free user prompts for all class fields. 
• View, modify and create access policies allowing unrestricted access.<

This is so that the administrator can immediately test document storage and retrieval of documents to the new class and start creation of user facing searches and save profiles. 

Usage of default tools for user work is not recommended and they can be restricted or removed from the system if required.

---

Access policies

The traditional approach to managing document security has been to control access on per object basis. This means that each object stored in a document management repository had to have an access list established, either directly or through inheritance from the parent folder. 

While this type of access control is sufficiently granular, it is very difficult to implement as the number of documents in the repository grows. 

System administrators end up needing to manage a large number of access lists which control an increasing number of security relationships. This creates significant administration overheads when even simple security models need to be implemented, due to a potentially large number of documents stored and users interacting with the system. 

In PIQNIC, the only way users can access documents is through search. It seemed logical to control user access to documents by restricting the scope of a search which is done by silently appending (AND-ing) Access policies and their underlying conditions to searches user initiates. 

Access policies (view policies, modify policies and create policies) are used to give or restrict access to documents in PIQNIC. Policies, irrespective of the type, can only be defined against a single document class.

There are three types of policies to control all three main aspects of user interaction with documents:  

• Access and view document. 
• Modify or delete document. 
• Introduce new documents to the PIQNIC repository. 

Organisations can configure access policies to implement the restrictions and grants they want to impose on their document repository. 

Access type

Access policies can have more than one type selected. 

In these cases, metadata based conditions contained in the policy are shared and applied to each selected policy type. Net effect is the same as if we had two or three individual single type policies with identical metadata conditions 

Conditions

Configuration of Access Policies is mainly about defining metadata based conditions that implement certain type of restriction or grant. 

Policies can contain multiple conditions. 

Each policy condition has following properties: 

• Operator (and/or) – This controls how is the current condition line appended to the previous one. Condition can be indented to indicate precedence.  
• Name – List of metadata and system fields associated with the selected document class. 
• Condition – One of the following:
  • IN, =,<,>,<>,>=,<=,Between for INTEGERS, DOUBLE and DATES;
  • =, IN, Starts With, Ends With, Contains, Does not contain, Like, Not Like for CHAR and TEXT;
  • = For BOOLEANs
• Value – Free entry (validated to match the datatype of selected field) or selection of one of user metadata fields that are defined on organisation level to apply to all users. It also includes metadata fields that are assigned to the same roles as the policy being created. At runtime selected metadata field is replaced with value assigned to the logged in user. 

Assigned to

Each access policy can be assigned to any number of roles. 

The opposite is also true so when users inherit policies from one or more roles they belong to, individual policies coming from different roles are combined (OR-ed) to determine cumulative access of that user for the given document class.  

Whenever we create a document class, the system also creates three unrestricted access policies and assigns them to the Admin role. We can use these policies to start and test initial configuration of the class and remove them once the configuration is ready to be used in production. 

In summary, access policy definitions are based on document metadata and are built similarly to document searches. The only difference is that users cannot view search clauses built into the access policy and that a policy assigned to the role applies to every search a member of that role executes. 

Let us consider an example: 

We could have a search with the following prompts:

• employee name
• department
• document type. 

If we establish a view access policy: “Document type<> Legal” and assign it to user role accounts, that means that whatever search criteria is supplied when running the search, members of the “Accounts” role will never be able to see legal documents. 

Members of other roles that don’t have this policy assigned will be able to see legal documents. 

Users who are members of several roles will inherit policies assigned to each role. 

Modify access policies and Create access policies use the same approach to define the scope of documents users can modify or create in PIQNIC. 

Modify access policies establish metadata based rules for documents that can be modified or deleted by a user the access policy is assigned to. 

Create policies represent rules that allow creation of documents in PIQNIC by users the access policy is assigned to. 

It is important to emphasise that Create policies are tested when users index documents which is  when document metadata is first known.

Access Policies Tab has functions to create a new access policy, edit an existing policy or delete policy. These are implemented as buttons at the top of the screen. 

Access policies are applied as soon as they are saved to all documents matching conditions of the policy. 

Policy can be tested by using “Test” button. This will return the first 100 documents the policy applies to.

---

Document searches

Documents stored in a folder system are restricted to two basic properties: 

• their file name, and
• the name of the folder they are filed to. 

All document management systems that use folder based document classification inherit that same constraint. 

Unlike traditional file systems, PIQNIC does not have folders. Searches are the only way to locate and retrieve documents.  

In PIQNIC, documents are classified with an unlimited number of properties (metadata fields) specific to the document class the document is filed to. 

Searches use some or all of these fields to offer users flexible and efficient document search function.  

In PIQNIC, we have implemented a pluggable search architecture. This means the system searches can be configured to query third party repositories through additional search providers. 

For the current release, apart from the native search functionality we have also implemented Google® search.

Auto Run Flag

Searches with this flag set will automatically execute without prompting users for search parameters.

Google searches

Google searches do not have any constraints or restrictions placed on them. 
They can be pre-filled by the Administrator or entered by the user – in any case users need to adhere to Google search syntax. 
Google searches are not subject to access policies.

Native searches

Native searches are the main tool available to users to find documents in the repository. 

Each search is a collection of prompts, defined by the Administrator that users can use to control the scope of the search. 

The Administrator can also implement some restrictions, some visible, some hidden, where certain fields could be locked to a specific value, list of values, or where the user input is validated. These restrictions are in a way similar to restrictions we can place into a View access policy- there are two key differences:

• A View access policy limits the overall scope of the search by effectively granting access to certain parts of the document repository. Whatever search criteria search contains, it can only return documents within the document set described by View access policies allocated to the roles of which a user is a member.
• A View access policy applies to all searches defined against the same document class and executed by a user that the access policy applies to through their role membership. 

The Administrator creates document searches from metadata fields available for the selected document class and assigns them to user roles.  

Searches can be assigned to many roles, but they are always related to a single document class. 

Each search has a unique name and, optionally, a description. 

Native searches can contain multiple conditions. 

Each search condition has following properties:

• Operator (and/or) – This controls how is the current condition line appended to the previous one. 
• Name – List of metadata and system fields associated with the selected document class. 
• Alias – Free entry providing the label for the field in search form at runtime. If empty, field name from document class is used.
• Clause – One of the following:
  • N, =,<,>,<>,>=,<=,Between for INTEGERS, DOUBLE and DATES;
  • =, IN, Starts With, Ends With, Contains, Does not contain, Like, Not Like for CHAR and TEXT;
  • = For BOOLEANs
• Value – Free entry (validated to match the datatype of selected field or regex validation) or selection of one of user metadata fields that are defined on the organisation level to apply to all users). That includes system fields like loginId, user name and userroles (collection of names of all roles a user belongs to – can be used only if clause selected is IN). It also includes metadata fields that are assigned to the same roles as the search being built. At runtime selected metadata field is replaced with value assigned to the logged in user. If Value List is defined for the field, only list values can be selected to provide field value.
• Field type – Rewritable (user can change value at runtime), Read only (user can view but not change the value at runtime), Hidden (user cannot view or change value at runtime). If value list is provided for the field Rewritable flag will mean that the user can freely enter value not provided in the list, while Read Only will force selection one of the list items.
• Regex validation. If provided, the field will be validated after a value is entered either by the user or the Administrator. Values not passing validation mask will not be allowed. If field value is a metadata field, Regex validation will not run. Regex syntax is described here
• Value list – If provided for the field, the user will be able to choose one of the values provided in the list at runtime. At runtime, the list’s content will narrow down as the user types. If the list starts with an empty line, the user will be able to use it to signal no value provided. If the search clause is IN, user will be allowed to select multiple values from the list. Each list can be set to depend on another field that belongs to the same search, has a list defined , its clause is set to “=”. For dependent lists, the Administrator provides value pairs where each item from the parent list (key value) has a list of values in the dependent list. At runtime, the dependent list will be adjusted, based on the selected value from the parent list.
• Mandatory – If this flag is set, search will not execute if the field is empty. Works only on Rewritable fields. If search has mandatory fields with no default value, auto-run flag cannot be set in.

Conditions can be nested up to one level deep. Indent commands effectively adds brackets to the current and all following conditions until it reaches one that is Unindented. This is a toggle function so the indented conditions can be unindented.

Result layout is created for each search and allows adding of any document class fields (system or user defined) to the Search result layout using the following functions: 

• Field alias can be freely entered. If not provided, field name from the class definition will be used at runtime. 
• Fields can be re-ordered within the list to match the desired order of fields within the search result list.
• Fields can be added or removed. Only selected fields will appear in the search result list.
• A field can be selected to provide initial sorting order for the search result list.

Administrator-defined searches could be further refined by users and saved as their personal favourite searches. This is a non-admin function built to help users expedite access to documents they frequently need to access.

It is very important that admin created document searches are user friendly and promote efficient interaction with document repository in the context of daily work.

---

Save Profiles

Save Profiles are used to save documents to PIQNIC repository.  

As we saw with Search definitions, having metadata associated with each document is very handy.  

To be able to create document metadata, it is not sufficient just to “save” a document to PIQNIC the way it works for files managed by a Windows or Mac operating system. Documents need to be classified – this is the process that associates documents with the relevant information that describes them (document metadata). In PIQNIC we call this process of document classification “Indexing”. 

To make the process of document indexing as quick and efficient as possible, in PIQNIC we have introduced Save Profiles. They are implemented as drag-and-drop targets within the Store panel of the PIQNIC UI. 

Defined by the Administrator, each Save Profile contains a number of metadata rules used to either prompt (and sometimes require) indexing information from user or automatically populate document indexing fields without user’s intervention.  

What makes document ingestion through Save Profiles efficient is that the users are not necessarily prompted for each and every piece of metadata we want to associate with a document. Save Profiles can have some field values pre-set and prompt users only for minimal amount of information to assure the integrity of searches, security and other rules. We could also have data entry assisted through a values list associated with individual fields.  

Save Profiles defined by the Administrator are assigned to user roles. Similar to Searches, users get to see the Save Profiles associated with all roles they belong to. 

There are many similarities between Profile and Search definition tools which is natural as they are inverse functions of each other. 

Users can additionally customise Administrator-defined Save Profiles. This is a non-admin function that allows users to create “Favourite Profiles” where some Save Profile prompts can be pre-filled to match frequently ingested documents. It is important to note that favourite Profiles cannot override any restrictions or rules embedded into Save Profiles by the Administrator. They just work on top of the Save Profiles definition in more or less identical way to favourite searches.

At runtime, each attempt to save a document will evaluate supplied document indexes against Create access policies assigned to the user through their role memberships. At least one needs to evaluate true for the document to be successfully saved to the repository. 

Each Profile has the following properties: 

• Name (unique, mandatory) 
• Description 
• Use for document properties – If this flag is set, a profile form will be used to show document metadata in the document metadata panel of the Document details screen. Each Document class can have only one profile with this flag. This way the Administrator can control what document metadata will be shown and can be changed by the user. 
• Deferred indexing – Profiles with this flag will not prompt users for indexing information at the point of ingestion. Instead, they will save a file for deferred indexing. Files on this list will be considered not fully ingested and will not be returned by any search or evaluated by storage or retention policies. 

The list of unindexed files is available through “Unindexed Files” tab of the user interface. Users having access to it can index documents and complete their ingestion to the system: 

• Add to task (task selection) – This will be offered as a pre-set option at indexing. If set, at the end of each file ingestion user will be prompted to create a new Task or add file to an existing task he either owns or is assigned to.  
• Save Internet documents as references – Instead of saving a file, profiles with this flag will save a URL reference to the location of the file. Users are expected to enter a valid URL at ingestion. 

Profiles can contain multiple prompts. Each profile prompt has following properties: 

• Name – List of metadata fields associated with the selected document class. Document title is also available for selection.
• Alias – Free entry providing the label for the field in profile form. If empty, Field name from document class is used. 
• Value – Optional free entry (validated to match the datatype of selected field or Regex validation) or selection of one of user metadata fields that are defined on the organisation level to apply to all users. This includes system fields like:
  • login Id
  • user name
  • user email.  

It also includes metadata fields that are assigned to the same roles as the profile. At runtime a selected metadata field is replaced with a value assigned to the logged in user. 

If Value list is defined for the field, only list values can be selected:

• Field type: 
  • Rewritable (user can change value at runtime). If a value list is provided for the field Rewritable, the flag will mean that at runtime the user can freely enter a value not provided in the list.
  • Read only (user can view but not change the value at runtime). If a value list is provided for the field Read Only, it will force selection one of the list items.
  • Hidden (user cannot view or change value at runtime).
• Regex validation  – If provided, the field will be validated after a value is entered either by the user or the Administrator. Values not passing validation mask will not be allowed. If a field value is a metadata field, Regex validation will not run. Regex syntax is described here
• Value list – If provided for the field, at runtime the user will be able to choose one of the values provided in the list from a drop down menu. If the list starts with an empty line, the user will be able to use it to signal no value provided. Each list can be set to depend on another list associated with a prompt that belongs to the same profile. For dependent lists, the Administrator provides value pairs where each item from the parent list has a list of values in the dependent list. At runtime the dependent list will be adjusted, based on the selected value from the parent list. 
• Mandatory – If this flag is set, a document cannot be saved if the field is empty. 

In addition to profile editing functions described above, Save Profiles tab contains profile management functions (Delete, New, Edit and Copy) implemented as buttons at the top of the screen.

---

Storage policies 

One of the unique features of PIQNIC is the ability to create a number of storage volumes across different providers and in different geographies. This is covered in more detail in the Storage section.  

That feature is further enhanced by the ability to define metadata based policies for distributed storage of documents within a single document class across a number of storage volumes. 

Policy based storage of documents in PIQNIC is a significant departure from the traditional approach where document class documents are only stored in a single physical location. 

Metadata based policies allow segmentation of physical storage of documents according to business, legal, compliance and other information management requirements without the need to increase the complexity of the repository by defining additional storage classes.  

Minimising the number of storage classes has, in turn, positive impact on user efficiency and the complexity of the system administration as the user requirements are met with fewer searches and Save Profiles. 

Each document class can have a number of storage policies. Each storage policy implements a metadata based test that all documents ingested to PIQNIC undergo whenever their document indexes are created or modified. If the policy evaluates true, that document will be physically stored at the selected document volume. 

For example, a document class could have Index Field “Department”. We could establish a storage policy that will store all documents where Department=”Legal” to a special storage volume “Legal Documents 1”. That means that all legal documents will be stored on a non-default volume for the document class that matches different compliance and data sovereignty storage requirements legal documents may have.

Each storage policy has following properties:  

• Policy name (mandatory, unique)
• Description
• Destination volume (one of the non-backup volumes on the system), mandatory 
• Enabled flag (used to suspend policy)
• Detailed logging flag (used to send evaluation logic for each object evaluated to the organisation’s log).

Policy conditions

Policies can contain multiple conditions. 

Each policy condition has following properties: 

• Operator (and/or) – This controls how the current condition line is appended to the previous one. 
• Name – List of metadata and system fields associated with the selected document class. 
• Condition – One of the following:
  • (IN, =,<,>,<>,>=,<=,Between for INTEGERS, DOUBLE and DATES;
  • =, IN, Starts With, Ends With, Contains, Does not contain, Like, Not Like for CHAR and TEXT;
  • = For BOOLEANs.
• Value – Free entry (validated to match the datatype of selected field) or selection of one of user metadata fields that are defined on organisation level to apply to all users. That includes system fields like user name and user roles (collection of names of all roles user belongs to – can be used only if condition selected is IN). At runtime selected metadata field is replaced with value assigned to the user who is the author of the document.

Conditions can be nested up to one level deep. Indent commands effectively adds brackets to the current and all following conditions until it reaches one that is un-indented. This is a toggle function so indented conditions can be un-indented.

In addition to conditions, storage policy management screen contains management functions implemented as buttons at the top of the screen: New, Delete, Edit.  

It is important to note that any changes to the storage policies will not apply retroactively to files already stored on the system. 

Order of policies can also be modified to achieve specific evaluation order.

---

Retention policies 

Retention rules control automated disposal of documents in PIQNIC.  

Each retention policy is defined in relation to a specific storage class but we can have any number of retention policies governing the lifecycle of documents associated with a document class. 

The principal objective of retention policies is to govern the automatic destruction of documents. 

Similar to storage policies, retention policies evaluate document metadata in relation to defined retention policies to establish a date of disposal. Retention policy is not a mandatory part of a repository configuration – in absence of any retention policies, classes could be configured to keep their documents forever.  

Retention policies do not leverage “soft delete” functionality – all the documents matching a policy will be queued for permanent destruction, subject to the approval of an authorised user. Authorised user is a user who belongs to one of the roles having “can purge documents” grant. These users will be able to authorise permanent removal of a document in the special menu of their UI. 

Actual document destruction occurs in the time window reserved for bulk operations on the system, as defined in Other organisation settings. 

 Each retention policy has following properties:  

• Policy name (mandatory, unique)
• Description,  
• Enabled flag – used to suspend the policy. 
• Detailed logging flag – sends policy evaluation for each evaluated document to the organisation log file.

Policy conditions

Policies can contain multiple conditions. 

Each policy condition has following properties: 

• Operator (and/or) – This controls how the current condition line is appended to the previous one. 
• Name – List of metadata and system fields associated with the selected document class. 
• Condition – One of the following:
  • (IN, =,<,>,<>,>=,<=,Between for INTEGERS, DOUBLE and DATES;
  • =, IN, Starts With, Ends With, Contains, Does not contain, Like, Not Like for CHAR and TEXT;
  • = For BOOLEANs.
• Value – Free entry (validated to match the datatype of selected field) or selection of one of user metadata fields that are defined on organisation level to apply to all users. That includes system fields like user name and user roles (collection of names of all roles user belongs to – can be used only if condition selected is IN). We can also put calculations relative to current date into the value field when selected field is a date field. For example, “Date created” < Today-5 years so the document age retention can be implemented. At runtime selected metadata field is replaced with value assigned to the user who is the author of the document. 

The following are commands we can run against retention policies – they are implemented as buttons at the top of the screen: 

• Delete, New, Edit 
• Save and Cancel for Policy that is edited.
• Test – Each policy can be tested. This button runs selected retention policy and returns how many documents are affected by the policy as well as metadata details of first 100 documents that are picked up by the policy conditions.
• Execute – Selected policy can be manually executed. 

---

Batch upload 

Batch upload is a document ingestion tool built to facilitate the processing of a large numbers of documents. 

Typical use cases that leverage batch upload functionality are: 

• Document migration – Movement of large number of documents from legacy repositories to PIQNIC.
• Distributed document capture – Where documents are acquired/produced by multi function devices and networked scanners.
• Ingestion of computer generated documents – Where we have print or report runs that need to be archived.
• Outsourced production of documents – Customer bound communication printed and mailed outside the organisation that needs to be archived. 

Batch upload engine is built to process batches of documents. These batches are zip files incorporating a named flat file that contains document metadata and corresponding file names of document files that are placed in that same zip file.  

Zip files can be submitted manually through batch profiles, which is visible to roles that have been assigned access to batch upload privilege through.  

Processing rules are controlled through batch upload admin tool described below:

The left panel displays lists of batch upload definitions defined on the system. Each definition contains a distinct set of processing rules and is associated with its own batch upload profile in the user’s batch profiles tab. Selected definition shows its parameters in the read only RP. Parameters can be edited using “Edit” button. 

Copy function allows definitions to be copied. Users are prompted for the new unique name. New definition is initially disabled. 

Each definition is created with following parameters: 

• Name – (mandatory, unique) 
• Description
• Enable processing – When this flag is set batch upload engine is ready to accept new jobs.
• Enable Profile – When this flag is set, upload profile will appear on the batch profiles tab.
• Polling interval – This is how often engine checks for newly uploaded zip files.
• Schedule – Gives us the ability to schedule execution of the selected batch upload definitions to specific weekday or time window. Files could upload but actual processing will not start before the time specified here. 

Document Parameters Group 

When an input file is processed, each line should point to one of the document files from the zip file. 

Engine will create a document (or file within a document) using the document file and associated metadata using parameters specified in this section: 

• Document author – We can select one of the system users or username metadata field. If the latter is used, document author will be the user who filed documents for all documents in the batch. This is default setting. 
• Convert TIFF to PDF – Often documents are scanned in TIFF format. This setting converts TIFFS to PDFs on the fly. 
• Flag as unindexed – If this flag is set, documents will be created with whatever metadata is available but will be queued for manual QC/additional indexing in the “unindexed documents” tab.  If the flag is set, one of the profiles associated with the document class needs to be selected in the Save Profile field to provide UI for additional indexing . 
• Don’t create duplicate documents – If this flag is set, and the system already contains a document whose metadata fields have values identical to the line currently processed (including document title but excluding file title), batch import will add file referenced in that line as another related file to the existing document instead of creating a new document. The File title system field value will be determined from the mapping to the File title in the Field mappings. If such mapping does not exist, the actual filename will be used for the File title.  If the flag is not set, each line will create a new document and duplicates will be allowed. 
• Scope of duplicate detection – System wide, Input file, Input file – Contiguous lines – If input file is selected, the system will detect duplicates only within the batch currently being filed. Contiguous lines option prevents duplicate creation only for lines that follow each other in the input file. 

Input File Parameters Group 

Each zip file needs to contain a metadata file – we call it the Input file. The layout of the Input file is defined below: 

• Name (mandatory) – Could contain ? and * wildcards, for example input0??.txt. If there are several files matching name definition, they will be combined and processed as a single batch, so they must have the same structure.
• Number of lines to skip -If empty or zero, input file will be processed from the first line.
• Type:

Delimited

Metadata fields on the line are separated with a delimiter.

Field delimiter (comma, pipe, semicolon, tab)

Delimited sample format

documentFileName | fileTitle | documentTitle | fieldX | fieldY  value_a1 | value_a2 | value_a3 | value_a4 | value_a5  ;  value_b1 | value_b2 | value_b3 | value_b4 | value_b5  ;

Line delimiter (CR, LF, CR+LF, semicolon) 

Fixed length. Metadata fields are padded with spaces, so they have same length on each line. Delimiters are not necessary. 

Fixed length sample format

/*Column position   0          10          20         30    */     value_a1   value_a2    value_a3   value_a4      value_b1   value_b2    value_b3   value_b4

XML

Fields are separated with XML tags 

The XML is supported in a fixed format. The root tag () indicates start and end of the input parameter file. 

The child tag () of root tag indicates a single document metadata collection. 

The inner tags of child tags (metadata tags) indicate document metadata. 

The metadata tags are auto generated according to the batch definition. The order of the tags can be changed.  

Tags 

• Root tag  
• Child tag  

XML sample format 

 The following point should be taken care of while creating input parameter file for successful parsing: 

• Field values should not contain special characters (!@#$%^&()_++=[]{};’,). 
• Date format should be dd-mm-yyyy. 
• Trim flag should be ON for respective field to avoid white spaces in data type validation.
• Boolean type field value must be supplied. 

Field Mappings Group 

This is a mapping list that describes how the information from the input file is parsed and populated into metadata fields of a selected document class. 

• Input Field number (delimited type) – Sequential number of the column in the input file. Each definition needs to start with “Document File Name”- that is the name of the physical file from the batch that line metadata is associated with which should be placed at the start of each line in the input file 
• Input Field Label (delimited, fixed length type) – Unique label assigned to the field from the input file.
• Field – Selection of fields from the selected document class. This is the field that will receive value from the input fields. Two system fields are always available: Document title and File title. If file title is not mapped it will be populated with the actual file name of the physical file. If the document title is not mapped and line results in creation of a new document (using logic described in “Don’t create duplicate documents”), document title will be the same as file title. 
• XML tag (XML only) – XML tag enclosing the field in the input file.
• Start and end location (fixed length) – Column where the field starts and ends for each line of the input file.
• Transformations – Regex expression if the transformation of the field value is required.
• Required flag – If input field is empty, no documents will be created which will be registered in Batch log file.
• Trim – Trailing and leading spaces will be trimmed before metadata field is updated.

Other commands

• Delete – Deletes batch upload definition (not the filed documents).
• Information button – Shows the filing history for selected batch import definition. History panel shows: File name, Date Processed, Number of input lines, number of documents created, number of related files saved, status, progress. It also provides access to the filing log file. 
• Test button – Each definition can be tested. Pop up screen prompts user to select a sample file that will be parsed using field mapping rules from the selected batch upload definition.  No documents are uploaded during testing- this is used only to validate definition.