PIQNIC is designed to provide multiple modes of collaboration services to business users, inside and outside their organisation.

Business style collaboration often revolves around documents being consumed or produced, which is why we felt it was necessary to build a robust document management functionality. 

After all, business documents in their various forms fully describe not only the way business should be conducted, but to large extent business transactions themselves.

Separation between the two functional areas – Document Repository and Collaboration Platform – was required to operate efficiently, considering some of the key differences:

Lifecycle

Work management in general, and collaboration in particular are generally short lived. The focus is on the efficiency and productivity in making business decisions on various levels and by a potentially diverse audience. Once a decision is made and the transaction is complete, the collaboration session ends as well.

The management of business documents on the other hand follows a different pattern. Business documents have a well-defined and generally speaking, long lifecycles, much longer than a collaboration session. They are often re-used, especially for collaboration around recurring and repetitive tasks.

It is for this reason that management tools have to be well adjusted to provide efficient management of both, because the efficiency of business collaboration often greatly depends on how quickly a relevant business document can be presented in a collaboration session. 

Security

Business document repositories require, and generally implement, very regimented security around business documents. Long lifecycles and strict retention policies are complemented with an intricate security model that is based on multidimensional classification of documents and users accessing them. 

Document security is modelled upfront and does not change very often. Collaboration platforms do not operate in quite the same way. The ad-hoc nature of work means that it is not easy to predict what information is relevant to a particular task or transaction, so it requires a more flexible and dynamic security model. 

The security model built into collaboration is based on delegated access to task artefacts and functions. All users assigned to a task have the same security profile in relation to its artefacts and functions, largely determined by the task owner. 

The collaboration (task) owner and other users can delegate access only to artefacts they have access to, e.g. repository files are subject to Access Policies. However, once the file is added to the task, it is visible to all task users.  

This security model effectively inherits constraints of the Repository Access policies but allows access to be delegated in a context of a collaboration session (task) within the repository’s constraints. 

Through the auditing functions of a task, users delegating access (task owners and others) are accountable for providing access to whomever they have invited to the task.

Tasks

PIQNIC’s implementation of collaboration is built around a task. Tasks represents a single collaboration session. Task definition and management is ad-hoc in nature, and is fully vested with the task owner who creates a task. 

For this reason, there are two views to each task:

• one for the task owner where the emphasis is on overseeing work described in the task
• the other for users assigned to the task where the presentation is optimised for decision making and task completion. 

By allowing the task owner to set and tweak various properties of the task, we can cover a variety of different collaboration models and use cases: 

• To-Do list management – the simplest form of task assignment and control.
• File sharing – standalone task created to securely share documents and files.
• Document and work approval – a quick, secure and easy way to get your documents and work approved.
• Project management – controlling group execution of multiple independent or dependent tasks.
• Task workflow – by defining multiple steps within a task, we can enforce the way users work on a task and assure integrity of the collaboration outcome.  

PIQNIC tasks of different types and various degrees of complexity co-exist within the same platform and provide task owners and users a consolidated view of their collaboration workloads.  

Task properties

Each task has the following properties: 

• Title and description. 
• Payload – initially payload represents files associated with the task by the owner. Files can come from the PIQNIC documents or externally as task only files.  We can also have external (URL) references within the payload pointing to files or web pages held and managed outside PIQNIC(i.e. GDrive or OneDrive). Throughout the task’s lifecycle, more files and URLs  can be added using the file contribution tools (Profiles) chosen by the task owner.  Technically, all user messages saved within the task are part of the payload. User messages, combined with system captured task events, are presented within the task wall which is presented prominently within the task.
• Task users – users are managed by the task owner and they can be added from the list of the organisation users or as external users (users invited via email). Within the task we have two types of users:
  • watchers who are only monitoring activity within the task
  • normal users who are expected to complete work or make decisions as requested. 
• Decisions – task owner can associate a number of decisions with each task. To complete work on the task, a user has to choose one of the decisions offered.
• Save Profiles – by selecting some of the Save Profiles a user has access to, the task owner enables all users assigned to the task to permanently save files to PIQNIC, while they are attaching them to the task. Special Profile “Save To Task Only” is used to save files and URLs to the task only. Such files are not returned by PIQNIC document searches. Using Save Profiles, files and external URLs produced during collaboration session can be saved permanently to the repository and from that point be returned by its searches. This is a very important feature of the platform as it allows the collaboration output to be saved and managed as a corporate asset in the document repository.
• Steps – task owner can define a number of steps. Steps represent a workflow sequence that the task needs to follow through to completion. Each step has its own collection of users, decisions, and save profiles but the payload is shared – all files and messages, including system generated event log, are available at each step. Multi-step tasks are completed at the last step.
• Due date – provides a reference to when the work is expected to be completed. It also triggers notifications.
• Progress – progress is set by the user for each task as a feedback to the task owner.
• 2nd-in-Charge – 2nd-in-Charge is the user that has equal rights to the task owner. It can be added or removed by the task owner on the project or task level. It can also be updated through user delegation function in user settings.
• Priority – set by the task owner.
• Dependent tasks – within a project, each task can depend on one or more tasks from that project. What that means is that the task will become active (available to its users) only when all dependent tasks are completed.
• Status – this property is usually set by the system.
  • Inactive – waiting on dependent task to complete.
  • Active – default status.
  • Completed (Voting Rule has established the Task is complete)
  • Disabled by task owner.
  • Draft.
  • Deleted (can only be done by the task owner). 

Projects

Task owner can group tasks into projects. 

Projects have a name and description and the ability to perform some operations affecting all tasks – e.g. they can broadcast a message to all tasks. 

Tasks can be freely moved in and out of the task, taking care of any potential dependencies. 

Project status can be:

• Deleted – if all its tasks are deleted.
• Completed – if all its tasks are completed or deleted.
• Active – if there is at least one active task.
• Inactive – if there are no active tasks, there is at least one inactive task (this can only happen if the task owner introduces a task draft to the project).