In this section, we will explain the underpinnings of PIQNIC functional model.

Organisation

On the platform’s functional map, Organisation sits at the very top. 

It is a container to which all administrative and user facing tools and resources are confined to. While residing on the same physical environment (an instance), organisations are logically completely isolated.

Roles

Within the organisation we can have a number of roles. 

These are collections of users organised typically to provide a certain level of security or functional access to the document repository. 

Repository functionality and security are managed exclusively through roles, not individual users.

Users

Users are assigned to one or more roles (they can have multiple role membership). They have properties assigned either directly or inherited from organisation or role.

Document classes

Document classes are templates for document organisation in the system. Their main property is an admin-defined collection of metadata fields associated with it. 

We call this collection Document indexes.  Each document class also has a number of system properties that are shared between document classes – an example could be unique identifiers for documents and files. 

Document classes can be associated with a default storage location (Storage volume) but they can also have a number of Storage policies that can spread their documents and files to a number of physical locations.

Repository

Each document created on the system belongs to a specific document class with its own collection of user defined and system metadata field values. 

All documents stored in the system constitute a repository.

Storage volumes

Storage volumes are physical locations where document are stored. They can be created on any supported infrastructure provider platform- default one being obviously AWS’ S3.  

A single volume can be used to store documents from different document classes.

Storage policies

Storage policies determine which storage volume a document and its files should be stored on. 

These rules are metadata based – they examine values of document’s metadata fields, typically at ingestion – to determine where the document and its files should be stored. 

Each document class has one default volume and (optionally) a number of storage policies.

Retention policies

Retention policies determine when documents are purged from the system. 

Similar to storage policies, they are metadata based and execute in the background at document ingestion to determine retention window. 

Actual purging of documents is done independently based on the retention window. 

Searches

Searches are collections of metadata-based conditions or user prompts created to allow retrieval of documents. 

The platform does not store or manage its documents in folders, so searches are the only tools available to users to locate documents in the repository. 

Scope of the search is limited to one document class. Each search is assigned to one or more roles – all users that are members have access to that search. 

Users can create Favourite searches from admin-defined searches they have access to.

Access policies

In PIQNIC we have three types of access policies: 

• View access
• Modify access
• Save access.

Access policies are metadata based and, similar to searches, can only be defined against one document class and be assigned to multiple roles.

View access policy

View access policy works as an extension of a search, invisible to the users. Before executing a search of a particular document class, all View access policies defined for that class and inherited by users through their role membership are established.

These View policies are then OR-ed between themselves and AND-ed to the search. Search is then executed, returning documents to the user, effectively restricting access to the repository. 

Initially, users have access to nothing, so each user needs to have at least one View access policy assigned to one of their roles to be able to see documents returned by a search. 

Save access policy

Save access policy is similar, except that it works at the point of document ingestion. User’s attempt to save a document will fail unless one of Save access policies assigned to any role they belong to evaluates true for the metadata set associated with the document being saved. 

Modify access policy

Modify access is checked in a similar way when the user tries to delete a document, any of its files or modify document metadata.  

Save Profiles

Documents are ingested to PIQNIC through a drag-and-drop zone we call a Save Profile. 

Similar to search definition, system administrator can pre-set values or prompts for some metadata fields thus expediting document ingestion, while assuring integrity of document classification and underlying searches and access policies. 

Similar to searches, Save Profiles are always associated with a single document class and can be assigned to multiple roles. Users can use the Profile if at least one of the roles they are a member of is assigned to the Profile. 

Their ability to actually save the document depends on the metadata used and is controlled by the Save access policy.

Documents

Documents are principal objects managed in the repository. They are always associated with a document class and have a set of values associated with class metadata fields collection (document indexes). These metadata fields make documents searchable and are also used to implement security, retention and the physical storage model through respective policies. 

Each document has at least one file associated with it. Documents can also have multiple files that are related – for example a version chain – but none of these files are directly searchable. They are part of the document envelope and its structure of related files is visible only when the document is retrieved. 

In all-important ways, the repository and its management tools are built to manage documents as entities, irrespective of how many files they may contain. Documents can’t be empty, so when the last (or the only) file is permanently deleted, a document containing it is also deleted. 

Files are physically saved in their native format to a storage volume – the only exception to that are, what we call, loosely managed files – effectively external URL reference which we can also store in PIQNIC documents. Loosely managed files represent a file or reference not physically stored in PIQNIC and as such is not subject to storage policies.

Task

On the collaboration side, the key object is a Task. 

Unlike documents repository where we have document classes, we have just one type of task that can be instantiated which makes a task the universal container for all types of collaboration. 

The key properties of a task are collections of users and files assigned to it, which together with conversations taking place within a task (aka Task wall) represents the task’s payload. 

Task files can come from the PIQNIC repository (managed files) or not – this is where we can attach any physical file to a task. We can also add URLs to a task to provide links to important information and documents residing on other platforms.

Users assigned to the task can be:

• internal (licensed, having access to all system functions subject to security restrictions), or 
• external (unlicensed, having access only to the task they are invited by the task owner). 

Each task has an owner who sets key task properties and assigns the initial payload to the task. This payload can be expanded by any other user assigned to the task. There are no restrictions to what files can be added to the task, short of the repository access policies as they apply to internal users including the task owner. 

Tasks can also have a due date and time and optional alternative owner (2IC).

Some other properties assigned to the task by its owner are:

Profiles collection

This is a selection of Save Profiles, made by the task owner that is available to task users to save files to the repository while they are being added to the task. Naturally, task owners can select only from the profiles they have access to. 

By using this functionality, task owner can force task files to be saved to PIQNIC repository.

Decisions collection

 This is a collection of decisions, created by the task owner that users have to choose from when completing work on a task.

Steps collection

Steps are introduced to tasks that have to go through several stages through to completion. 

Each task step has its own set of users and decisions. 

Tasks’ payload is moved and processed in pre-established sequence of steps. A good example of this would be the multi-level approval of a document.

Projects

Tasks can be grouped into projects. 

Tasks within the project are fully autonomous and are operated independently – they don’t share any part of task payload. 

Projects are convenience tools for task owners to allow them to more easily group and track progress of related tasks.

Task wall

One important element of task payload is task wall. 

Task wall contains all task events (log of user’s task activity), as well as all chat communication between users assigned to the task. 

The task wall is very similar to the concept of a group chat, except that it is confined to the task users are assigned to.