Loading

File Stores Overview

"File storage" covers two different things on this platform, and most confusion about files comes from mixing them up. One is the storage backend: where every uploaded file's bytes physically live. The other is a File Store: a shared library of folders and files with its own permissions, which people browse and pick files from.

Where to find it

Architect Panel → Data:

  • File Stores — the shared file libraries and their folder trees
  • Large Uploads — upload sessions in progress and recently finished

Architect Panel → Integration & Connections:

  • Deployments — the File Storage card, which shows the storage backend in use

Architect Panel → Security:

  • Security Check-up — the File storage and Stored file links rows

The storage backend: one per installation

Every file the platform stores (attachments on records, File Store contents and image thumbnails) goes to the same backend. There are three:

  • Local Web Server: files are written to folders on the server itself.
  • Amazon S3: files are written to one S3 bucket.
  • Azure Blob Storage: files are written to one container in an Azure storage account.

The backend is chosen by your hosting administrator in the server configuration, along with the bucket or container and its credentials. Nothing about it is set on a screen, and a File Store cannot have a backend of its own. Each tenant's files are kept under their own prefix within the one bucket or container. See Local, S3 or Azure Storage for how to choose.

Where a record's attachments go

A File Upload field on a datastore does not point at a File Store. Each field has its own storage mode (public, private or external, or a combination), which decides whether the file can be reached by a plain link or only through the platform's permission check. See Public & Private Paths.

File Stores: shared libraries

A File Store is a named library with a folder tree inside it. It is the right home for files that belong to nobody's record in particular: policies, templates, shared reference material, a team's working folders.

  • Folders nest, and each file keeps its earlier versions when it is replaced.
  • Permissions are per store, per security group: Read, Create Folders, Upload Files, Edit Existing Files/Folders and Delete Files/Folders.
  • People reach a store by browsing it, or through a File Store Selection field on a form or record, which lets them pick files out of a chosen store.
  • Files in a store can be adopted as documents, gaining document control features. See Bringing Documents In.

Checking what you have

  1. Open Deployments and read the File Storage card. Storage Mode shows Local Web Server, Amazon S3 or Azure Blob Storage, with the S3 bucket or the storage account and container.
  2. Open Security Check-up and read the File storage and Stored file links rows in the Data protection section.
  3. Open File Stores to see which libraries exist, then check each one's permissions.

What goes wrong

  • Somebody asks to "put this File Store on S3". That cannot be done per store. Moving to a different backend moves every file on the installation and is a job for your hosting administrator.
  • Uploads fail across the whole site at once. Suspect the backend: credentials, bucket or container. Check the Error Log for storage errors.
  • A user can see a store's files but cannot add any. Their groups have Read on that store but not Upload Files.

Worked example

A charity runs on Amazon S3. Case attachments are private File Upload fields on the case datastore, so they are only served after a permission check. Separately, a "Policies" File Store holds the current policy set: all staff have Read, and the governance team also has Upload Files and Edit Existing Files/Folders. When an auditor asks where documents are kept, the administrator shows the Deployments card for the backend and the store's permissions for who can reach what.

Recommendations

  • Keep the two ideas separate when you plan: the backend is infrastructure, a File Store is a library.
  • Use private storage modes for attachments that hold personal data.
  • Use File Stores for shared material, not for records' attachments.
  • Grant store permissions to groups and review them like any other access.