Understand the Folio Data Model

Folio is built from a small number of custom objects. This page gives you a high-level map of those objects and how they relate, without going into individual fields. Once you have this mental model, building flows, reports, and SOQL queries against Folio data becomes much more straightforward.

The objects

Five Folio objects do most of the work:

folio__Document__c — the parent record for a Folio Document. One record per Document.
folio__Jot__c — the parent record for a Folio Jot. One record per Jot.
folio__Tag__c — a single Tag definition. One record per unique Tag in the org.
folio__Junction__c — the central relationship object. Every link between a Document/Jot and a Salesforce record, and every Tag applied to a Document/Jot, is one row in this object.
folio__Document__Share — the standard Salesforce share table for folio__Document__c. This is what controls user/group access to Documents.

How they relate

The dashed line indicates a pseudo-polymorphic relationship — the Junction’s Linked Record field can technically point to a record on any Salesforce object. The lookup field itself does not enforce a Linkable Object restriction. The Linkable Object guard is applied only in the UI: when end users create record links from the editor, they can only choose objects that have been configured as Linkable Objects in the Configure the Admin Panel page.

What Junction represents

The Junction object is the heart of the model. Every relationship that involves a Document or Jot is one row in this object. Although the Junction is technically capable of representing any combination of Document/Jot/Tag/Record, in practice there are only four types of Junction connections in play:

Document → Tag — applies a Tag to a Document.
Document → Record — links a Document to a Salesforce record (Account, Opportunity, Case, custom object, etc.).
Jot → Tag — applies a Tag to a Jot.
Jot → Record — links a Jot to a Salesforce record.

Every Tag application and every record link, for both Documents and Jots, is one row in folio__Junction__c. A single Junction row references exactly one Parent (Document or Jot) and exactly one Target (Tag or Salesforce record). This unified design is what makes Folio’s many-to-many relationships work — and it’s why Folio’s invocable Apex actions like Link Documents to Records and Apply Tag to Document all create or query Junction rows under the hood.

folio__Document__Share is the standard Salesforce share table that ships automatically with any custom object that has private sharing. Every share row on a Document — whether granted by Folio’s auto-share rules, by a manual user share from the editor, or by an invocable Apex action — is one row in this table. The Get Document Shares and Share Document invocables read and write this table directly.

Documents also open access up the role hierarchy, so a user’s managers can always view their reports’ Documents. This is intentional for collaborative, shared, contextual documentation. Jots do not open up the role hierarchy — they are designed to be private for individual note-taking and context. If your users need collaborative, shared, contextual documents that follow the role hierarchy, they need to upgrade to Folio Docs.

How the editor UI maps to the data model

The actions users take inside the Folio editor map directly onto the objects above:

Sharing UI on a Document. When a user adjusts a Document’s sharing from the editor, what the UI is actually modifying is folio__Document__Share in the backend, using Salesforce’s standard sharing model to control access.
Record linking and Tag linking. When a user links a Document or Jot to a Salesforce record, or applies/removes a Tag, the UI is inserting or deleting folio__Junction__c records. There is no other mechanism — every link is a Junction row.

Why this matters

Once you internalize the diagram above, several things become obvious:

To find every Document linked to an Account, you query folio__Junction__c filtered by the Account’s record ID.
To find every Tag on a Document, you query folio__Junction__c joined to folio__Tag__c.
To audit who has access to a Document, you query folio__Document__Share.
To extend Folio’s auto-share or auto-link behavior to a new object, you create or update Junction rows from Flow.

That said, admins don’t usually need to write SOQL or insert Junction rows by hand to build automation around Folio. Folio ships a set of invocable Apex actions that wrap all of this behavior — querying Documents and shares, linking, sharing, tagging, transferring ownership, and instantiating Templates — so admins can build production-grade automation declaratively in Flow Builder. Understand the data model when you need to debug, report, or extend; reach for the invocable actions when you need to actually automate a business process. See Automate with Invocable Apex and Review Invocable Apex Use Cases for the full reference.

Key fields admins should know

A handful of fields come up often when admins write flows, reports, or SOQL against Folio data. These are the ones to keep top of mind.

Jot

folio__Is_Archived__c (checkbox) — the archive flag. Only used when Hard delete Jots is disabled in the Folio Admin Panel.
folio__Title__c — the Jot’s title.

Document

folio__Is_Archived__c (checkbox) — the archive flag. Only used when Hard delete Documents is disabled in the Folio Admin Panel.
folio__Is_Template__c (checkbox) — indicates the Document is a Template. This is only set from the Folio Admin Template Builder; all other Documents default to false.
folio__Document_Deep_Link__c — a URL that links a user directly to the Document inside Folio Home. Use it in emails, Chatter posts, or anywhere a clickable shortcut is helpful. The recipient must already have access to the Document for the link to load.
folio__Template__c (lookup) — set automatically when a Document is instantiated from a Template. Points back to the originating Template Document, effectively the “template source” reference.
folio__Title__c — the Document’s title.

Folio Log

The Folio Log object stores system-generated log records whenever errors or notable events occur in package code. Only users with the Folio Administrator permission set can access Folio Log records.

Key fields:

folio__Context__c — the context in which the log was created (e.g. invocable action name, trigger context).
folio__Detail__c — full detail of the log entry, often including stack traces or input payloads.
folio__Duration_ms__c — how long the operation took, in milliseconds.
folio__Log_Level__c — DEBUG, INFO, WARN, or ERROR. Retention per level is configured in Configure Advanced Settings.
folio__Message__c — short human-readable summary of what happened.
folio__Object_API_Name__c — the Salesforce object the log relates to (when applicable).
folio__Record_ID__c — the specific record the log relates to (when applicable).
folio__User__c — the user under whose context the log was written.

Configure the Admin Panel