Skip to content

Multitenancy

The Content Lake is scoped to individual tenants in the same way Microsoft 365 or Google Workspaces are shared by multiple customers on one shared set of infrastructure.

Your business can create an account and only users that you invite into your Tenant can ever view, edit or otherwise manipulate Content.

All requests to the Content Lake require a Tenant ID in the Request Header.

GET /content/b2959f04-319d-45ad-b2fc-a5f74a30c94a HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6...
X-Tenant-Id: 7af44d0eb211

Each authentication token is scoped to a specific Tenant. Tenancy is included in every part of the architecture of the Content Lake, it's not possible for a user to cross tenants.

In general, businesses should have one tenant for all of their documents. Using Tagging and Search you can serve any kind of application on a shared Content Lake. The power of an organisations implementation of their Content Lake is the knowledge graph that can be built to dynamically fit any kind of Content, the more distributed or disperate you make your Content, the less effective any Content Lake would be.

Customers frequently realise that Tagging and Contracts can cater to many common use cases, for example:

  • Contracts on document Ingestion can prevent Docments from being used in situations where the licensing terms either do, or don't, support intended use cases such as Translation or channel Distribution.
  • Tagging can be used to control visibility: for example a publishing/review-status tag could track whether it's In Draft, In Review or Published. Internal tools could allow any Content stage, whereas the company Blog may only allow Content with a Published value on the tag.

Isolated Environments

For clients who want their data in an environment with even stronger data guarantees then it is possible to have an isolated operating environment. These are only available to clients with more than $1m in annual committed spend.