Admin Panel — Settings

The Settings tab of the Folio Admin app controls how Folio Docs behaves across the org. Documents work from the moment the package is installed — but choosing your Linkable Objects, selecting Linkable Fields, and turning on Background Jobs is what unlocks the real value: live Salesforce data in the page, search across every Document, and sharing that follows your records.

Who can change what

Settings are gated by Salesforce system permissions, not by the Folio Administrator permission set alone. Holding Folio Administrator gets you into the Admin Panel; it does not by itself let you change every setting on this tab.

The gating works like this:

Asynchronous Processing needs the extra permission because it reschedules and aborts scheduled jobs owned by other users — an operation Salesforce reserves for Modify All Data.

So the accurate summary is: a Folio Administrator without those system permissions can still use the Dashboard, manage Templates and Tags, and configure Linkable Objects and Linkable Fields. The remaining Settings are visible to them but read-only.

When that’s the case, the Admin Panel shows a banner reading:

Most of the settings below require Salesforce System Administrator permissions and are shown as read-only. Contact your Salesforce Administrator to change them.

Workspace Configuration

Linkable Field Write-Back

The org-wide master toggle — Disable or Enable — for whether Live Fields and the Salesforce components can write data back to Salesforce records at all.

When disabled, Live Fields and components still display record data everywhere, but nothing in Folio can push a change back to Salesforce. When enabled, write-back is then controlled field by field in Choose Linkable Fields below.

Choose Linkable Objects

Expand the section and drag objects from Available Objects on the left into Selected Objects on the right. Both panes have a search box, which matters in an org with hundreds of objects, and each row shows the object’s label above its API name so you can tell similarly named objects apart.

Enabling an object lets users:

• Create Record Links to records on that object inside Documents
• Link Documents to records on that object from the Related & Tags drawer
• Reference Live Fields from a record on that object
• Use the object in any of the five Salesforce components — Status Bar, Record Preview, Related List, Workbench, and Kanban. For a component that spans two objects, such as a Related List of Cases under an Account, both the parent and the child object must be linkable

Each selected row carries an Auto-Share Level control — None, Read, or Edit. Whenever a Document is linked to a record of that object, the record’s Owner automatically gets that level of access to the Document.

Auto-share is also re-applied when a linked record’s owner changes — see Set up Real-Time Updates.

Special case: the User object

For the User object, Auto-Share Level governs something different — @-mentions of people. When a user is mentioned directly in a Document body, the Document is shared with them at the configured level.

If User is not among your Selected Objects, users cannot be @-mentioned in Document bodies at all. They can still be mentioned in comment threads; only body mentions are affected. Enabling User is what makes ”@ someone in the doc and they get access” work.

Queue-owned records

For linkable objects that use Queues as record owners, the queue must list Folio Document among its supported objects, in addition to the functional object it already supports. Otherwise auto-share based on the linked record’s ownership cannot reach the queue.

The share targets the queue itself, and members inherit access through standard Salesforce group semantics — which is why membership changes are picked up automatically with no additional configuration. Add or remove someone from the queue and their access to every Document linked to that queue’s records follows.

Choose Linkable Fields

For each object selected above, choose which of its fields Folio is allowed to use.

Linkable Field is the setting; Live Field is the node. A Linkable Field is what you enable here — permission for Folio to reference that Salesforce field at all. A Live Field is one of the things that permission unlocks: an inline chip in a Document showing that field’s value. The same Linkable Field also feeds the five Salesforce components. Enabling a field here doesn’t put it anywhere; it makes it available to be put somewhere.

1. Select an object in the left-most Selected Objects column.
2. Drag fields from Available Fields on Selected Object into Selected Fields.

Both field panes have a search box, and every row shows the field label above its API name — useful when several fields share a label.

This is also where the fields available to Templates come from.

The fields you select here become available everywhere Folio surfaces Salesforce data:

• Live Fields — inline chips inserted in a Document body via the @ menu
• Record Preview display fields
• Status Bar status fields — picklists, numbers, currencies, and percents only
• Related List columns — only fields enabled on the child object are available
• Workbench columns
• Kanban tile fields

Each selected field carries its own Enable Write-Back control, set to Disable or Enable independently of every other field.

The two-gate rule

Write-back requires both gates to be open: the org-wide Linkable Field Write-Back toggle and the per-field Enable Write-Back control.

With the field-level gate off, the field still displays everywhere it’s configured — but it is read-only everywhere:

• No Status Bar updates
• No Record Preview inline edits
• No Related List or Workbench inline edits
• No Kanban status drag-and-drop
• No Live Field edits in the Document body

This is what gives you precise control. You might want reps editing an Opportunity’s Amount from a Document but never its Stage — enable write-back on one and not the other.

Live Field write-back always respects Salesforce object-, record-, and field-level access. Folio will never give a user access they do not already have in Salesforce. These settings can only ever restrict what a user could otherwise do, never expand it.

Asynchronous Processing

A single Background Jobs toggle — Disable or Enable.

This should be on for Folio to work properly. Enable it once during initial setup and leave it on.

Enabling it schedules six jobs. You don’t need to manage these individually, but it helps to know what stops when the toggle is off.

The daily usage snapshots can never be reconstructed after the fact. If Background Jobs is off for a stretch, the Dashboard has a permanent gap for those days — the data isn’t recoverable later.

Disabling the toggle cancels all six. That makes it genuinely useful for pausing or resetting jobs — turn it off and back on to reschedule everything cleanly — but an org running with it off will have stale search results, team shares that never apply, and a Dashboard that stops advancing.

Automatic Team Sharing

Three controls — Auto-share level with Account Team, with Opportunity Team, and with Case Team — each set to None, Read, or Edit. Each governs the default access granted to that record’s Team Members when a Document is linked to it.

When a Document is linked to an Account, Opportunity, or Case, the Document is automatically shared with the Team Members on that record at the configured level. Choosing None disables team-based sharing for that object.

Keeping sharing in sync over time. A batch job keeps Document sharing aligned with team membership as it changes. This sync is additive only:

• Team Members removed from a record do not lose Document access they already have.
• A user with higher access is never demoted — someone with Edit stays at Edit even if the team setting is Read.
• A user who previously had no access is upgraded to Read or Edit as the setting dictates.

New Team Members may take up to 5 minutes before linked Documents are shared with them, because this runs as a batch job rather than instantly.

This depends on Background Jobs being enabled. With Background Jobs off, the initial share still happens at link time, but ongoing membership changes are never picked up.

Automatic Record Linking

Two Disable / Enable toggles:

• Auto-link from Opportunity to Account — a Document linked to an Opportunity is also linked to that Opportunity’s parent Account.
• Auto-link from Contact to Account — a Document linked to a Contact is also linked to that Contact’s parent Account.

Important behavior:

• Auto-linking is additive only — the link to the Account is never automatically removed.
• It runs only at the moment the Document is linked to the source record, and is not maintained afterward. Moving an Opportunity to a different Account does not move the Document’s Account link.

If you need links to follow records as they move, build it with invocable Apex in Flow — the Re-link Documents when an Opportunity moves Accounts recipe covers exactly this.

Delete Permissions

A single Users can hard delete Docs toggle. Two states:

• Disabled (recommended, and the default) — deleting removes the Document from the user’s view but only sets an Archived flag on the record. Admins can still access archived Documents and un-archive them.
• Enabled — deleting permanently removes the record from Salesforce.

(In Apex and on the Folio Configuration Custom Setting, this setting is named Allow Document Hard Delete.)

Leaving hard delete disabled is the safer default for the same reason a Recycle Bin exists: users delete things they didn’t mean to, and a document layer that can’t recover them becomes a liability. The cost is that archived Documents accumulate — visible in the Total Documents tile on the Dashboard.

To find and restore archived Documents:

SELECT Id, folio__Title__c FROM folio__Document__c WHERE folio__Is_Archived__c = TRUE

Set folio__Is_Archived__c back to false on the records you want to restore.

This setting is also honored by automation: the Folio: Delete Document invocable archives instead of deleting when hard delete is disabled. A raw Flow Delete Records element does not — see Updating and deleting Folio data.

Advanced Settings

Advanced Settings is the last section on the Settings tab, collapsed by default. It holds the two things most admins never need to touch: how long Folio keeps records that accumulate, and which objects are eligible to be made linkable.

Data Retention

How long Folio keeps each kind of record before its nightly job removes it. Set any value to 0 to keep that kind forever.

Record Retention

Folio Logs Retention

Only Folio Administrators can access Folio Log records — see Handle Invocable Apex Errors for using them to debug automation.

Shortening Document Version Retention does not delete Documents. It removes older change-history snapshots only. Every Document and its current content is untouched; users lose the ability to compare against or restore from versions older than the window, and nothing else.

Version records are roughly two-thirds of all records Folio creates, which makes Document Version Retention the highest-leverage storage setting on the page — halving the window roughly halves Folio’s total storage footprint. See Data Storage in Folio.

Retention only runs when Background Jobs is enabled. The cleanup is handled by a nightly job, so with Background Jobs disabled these values have no effect and notifications, exports, versions, and logs grow without limit.

Object Linking Allowlist

A single Allowed Objects field.

Folio hides a list of backend objects from the Choose Linkable Objects picker by default. If you need to add one back in, enter it here as a comma-separated list of API names.

Rarely used — reach for it when an object you expect doesn’t appear in the Linkable Objects picker.

Related: Use the Admin Panel · Dashboard · Templates · Tags · Set up Real-Time Updates · Update Data in Bulk · Automate with Invocable Apex