Due to the business flavor of most of the projects made with Nuxeo Platform it is not possible to draw a general approach that would be the good one in 100% cases. We try to give a few hints here.
Once you have your Nuxeo Platform instance running, it's not time to customize the look'n feel: change the logo, the colors, customize the login page to start making the Platform your own.
Organize the hierarchy of the repository so that it seems like a good base for some use cases. Folderish documents such as workspaces and folders can hold metadata like any other document. You should start thinking about your folders typology and if there is a hierarchy frequent pattern, it can be addressed with structure templates.
By default you have domains that contain workspaces, sections, etc... this behavior can be completely redefined and is for most of the deployments. For example Nuxeo repository can be used with just a hierarchy of "Folder" document types, from the root of the repository.
At this stage, you don't need to be extensive, just the initial folders and how the hierarchy will be evolving in the normal use of the product.
The Nuxeo Platform can be plugged to a wide range of directories and authentication systems natively (SAML, LDAP, AD, CAS) or through connectors (Shibboleth, Kerberos, etc.). You can then define what groups you'll be needing in your application and from which source.
Think of how you want to set up the security on your documents. The most standard way is to base it on ACLs (either on folders, or also on documents itself), but you can also go further using Security policies.
Standard ways are based on forms and drag and drop, but you may also have some third-party feeding, for instance by a digitization platform, or from an ERP. You need to clearly identify what will be the most frequent way for your use cases and pay specific attention to it. We provide tools like Bulk Document Importer, REST APIs, standard APIs (CMIS). If it comes from a third-party system, one of the questions will be "which metadata" are given right at the creation time.
The Nuxeo Platform and Nuxeo Studio provide great facilities for defining your data model, with all sorts of data types, including complex ones, and various edition components. Don't worry about thinking of everything from the start. This is clearly not a blocker issue as the repository allows to add new metadata for existing document types.
For that reason, we strongly advise you to keep only the strict minimum when starting your project. You have to be tough on stepping back and refusing all that looks like not vital. That's the best way to guarantee you'll go live quick, and quickly get the precious feedback from your users. And you won't frighten them with an over engineered system.
Implement different document types if you have different sets of metadata to handle, and different lifecycle states.
For metadata, we can split them among the following categories:
- Search metadata: The metadata that enable to search for the document in the repository. Focus on the taxonomies linked to the global business of your company/department and gather them in a common schema that you will use in the future when implementing other document management processes on your application. Don't focus too much on the specificities of the first process you choose to implement. You should not have more than two/three of those kind of metadata, usually edited via drop-down lists components.
- Lifecycle management metadata: Those metadata help you control the lifecycle of your document: when it was created, validated, by who, the nature of the document. This may have a direct impact on how the DMS (via rules and workflow engine) should process it, the review dates, etc.
- Informational metadata: This can be for instance all the authoring related metadata (who is the "real author" of the document, what are the constraints in the diffusion). As human nature is not metadata-filling friendly you need to be smart and try to leverage at best the context during the whole lifecycle of your document so as to fill metadata automatically. For instance you can use attributes of users who work on it, attributes of parent folders where the document was elaborated, etc.
Note that it is possible to extract some of the metadata automatically from a file using the binary-metadata module.
How will the user access documents? In the Nuxeo Platform you can configure some search screens (as many as you want) and also have some "presets" of searches.
You should definitely try to avoid letting the user have to configure himself the system. Think of how to use the dashboard, the faceted search capabilities, as well as the natural hierarchy, and the quick suggestion search.
You can go even deeper in tuning the search requests behavior, using Elasticsearch hints.
You have now defined and chosen the document management mandatory elements. To make the application your own, you now need to implement your own business logic to take into account your processes by adding buttons, workflows, transitions in the documents lifecycle, etc. Automation enables you to create complex business rules and logic from small operations and have them triggered by events and user actions, and workflows are built using a visual graph.
At some point in your project you need to decide about the architecture. Do you want to use a relational database (PostgreSQL, MySQL, etc.), a NoSQL database such as MongoDB, how are data persisted, do you need a cluster?