|You are here: For Users Upgrading from Version 4.x or Earlier >Introduction to New Features in Globodox|
This topic is only intended for users upgrading from Globodox version 4.x or earlier
Globodox addresses several limitations that existed in the earlier version making this version a far more flexible document management solution. This article will help users of earlier versions understand the reasons for the changes and new features added in Globodox.
Limitations with Version 4.x
Earlier versions of Globodox, allowed you to define a single set of indexing fields in a database. You would then create a new record which could hold one or more documents and enter indexing information into the fields defined earlier. The indexing information would apply to all the documents in that record. Let us look at this using an example...
If you had to manage two types of documents (Checks and Photographs), and wanted to store Photographer Name and Place Taken with each photograph and Check Date and Check Number with each Check, you could take two approaches...
Approach 1: Single document per record
In this approach, you could choose from 2 options:
Option 1: Single Database
You could store a single document (either a photo or a check) in every record of the database. You could create all four fields (Photographer Name, Place Taken, Check Date and Check Number) in the same DB and leave irrelevant indexing fields blank when entering indexing data for a specific type of document. This option would enable you to manage documents of different types in a single database. Having a single database for all documents is important because the user does not have to open and close different databases in order to look for a document.
Limitation: If you wanted to store specific information for each type of document, there was no easy way to do it in version 4.x.
Option 2: Multiple Databases
You could create different databases for Photographs and Checks, with each DB containing indexing fields specific to the type of document it was intended to hold. This option would enable you to manage documents of a single type using dedicated databases for each type.
Limitation: If you wanted to look for documents of different types, you would have to open and close different databases.
Approach 2: Multiple documents per record
In this approach, you had to manage groups of documents (Checks and Photographs), where each record could contain multiple related documents (Checks or Photographs or both) and the indexing information entered was for the entire group of documents.
Limitation: There was no way to specify additional indexing information for specific documents which were already part of a record. This made it harder to search for and locate a particular document.
New features in Globodox
Globodox significantly increases the number of ways you can index/classify a document. Let us look at the 3 major approaches to index/classify documents:
Approach 1: Folders and Tags
The simplest method offered is of arranging documents in a folder hierarchy. Users can create as many folders and sub folders as they want and they can also hide/share folders from/with other users. The second easy method offered is of attaching simple text tags to documents (think of it as attaching one or more labels to your documents). You can apply as many tags as required to a document. You can then search for documents to which a specific tag has been attached.
Approach 2: Document Types and Stack Types
For a more structured indexing approach, you can use the concept of Document Types and Stack Types. Document Types solve the Check and Photo problem described above. You can create two different Document Types one for Photos (with the fields Photographer Name, Place Taken) and one for Checks (with the fields Check Date and Check Number) in the same DB.
Now suppose these checks are from your customers. You want to be able to find a particular customer by their name, email id etc. and then be able to view checks received from them. For this you would use Stack Types. Simply create a Stack Type called Customer with indexing fields such as Customer Name, Email, Telephone etc. Now create a stack for each customer and add all their checks to their stack.
The big difference from the earlier version is that the documents (e.g. Checks) you add to the Stack, retain their indexing information. These documents can still be in a folder, still have text tags attached and still be of a particular Document Type. You can have as many Stack Types as you want.
A document can at anytime be part of only one stack. When a stack is deleted then all documents in the stack will also be deleted. If you do not want this, remove the documents from the stack before deleting the stack.
As you can see, the functionality of records in the earlier version has now been split between Document Types and Stack Types.
Approach 3: Links
Another powerful feature is the ability to link any document to another document or stack. You can have any number of links between documents and stacks.
The combination of all these features enable you to build an extremely flexible and useful document repository.