Domain Objects

Bipsync's data model is made up of many types of object, including the following key objects:

• Team
• Usergroup
• User
• Content Type
• Field
• Classification
• Category
• Contact
• Pipeline
• Stage
• Project
• Research

Let's discuss them, and how they relate to each other.

Teams, User Groups and Users

A user represents an end-user in Bipsync. It provides their account, and allows them to access Bipsync. The object contains many properties relating to the user, from their personal details (name, email address and so forth) to their settings.

A team represents a section of users that are related to one another.

Generally speaking most content in Bipsync is segregated by team, so it provides a way to establish a "Chinese wall" between data.

In typical scenarios a client will have a single team, with all users being members of that team. If there a need to ensure that some users can never see research created by others, then additional teams can be established and the users split between them as appropriate. Users can only belong to one team, and they are not expected to leave that team.

A more flexible way to share content between users can be achieved with user groups.

In contrast to teams, users can belong to multiple user groups and can join and leave these groups as necessary. Content such as research can be shared with one or more user groups, which achieves the same restriction of access as with teams, but in a more powerful way.

Content Types and Fields

Content within Bipsync is grouped by content type. These objects aren't exposed outside of Bipsync, but they serve to provide a way to relate a more important type of object – field – with other objects in the system. So a note content type could map to research objects, for example.

Fields are used in Bipsync to define ad-hoc data sets which relate to a particular content type. Taking our note example, we could associate several fields with the note content type, such as "note type", "date of publication", and "tags".

Each field has a given type – free text, date, list and so on – and can store either one, or many values. Depending on the field type, there may be additional options.

If an object has been related to a content type, and that content type has fields, then Bipsync users will be able to fill in those fields to store data against the objects, according to the field definitions. The data is stored within a fields property within each object.

Classifications and Categories

Bipsync uses classification objects to group category objects together by type, establishing a taxonomy of structured data.

Examples of classifications include companies/tickers, industries and geographies. All Bipsync installations tend to have these three standard classifications, which are identifiable by their type property.

Depending on requirements, sometimes additional classifications will be created which map to the client's proprietary business logic. For example, a classification named 'Vendors' could contain a set of third party vendors whose services the client has procured.

Contacts

The contact object relates to a person in the real world who is often related to an item of research – someone a user has met with, received insight from, or has a position within an invested company.

Pipelines, Stages and Projects

A pipeline represents a workflow in Bipsync. A good example is an "investment idea" pipeline – through which a user might take an investment idea through various stages, from conception to research, and finally investment. Each idea would be represented in Bipsync as a project object.

Stages and projects are constrained to a single pipeline, and a project will be in one stage at any one time.

Research

A research object stores a long-form research document. Regardless of whether the object originated as a note in Bipsync's editor, or from an email forwarded into Bipsync, or from an archived webpage, the body of the document will be stored as a content property on the object.

As with categories, contacts, and projects, research objects can contain field data, and are shareable amongst multiple users and/or user groups.