Admin FAQ

About as long as a cup of coffee. Folio Docs was designed from the ground up to be quick and easy to administer, and every setting ships with a default already configured to our recommendation — so the end-to-end time to install the package and have it set up and ready for people to use is a single sitting, not a project. See Install the Package and Follow the Setup Checklist.

What takes longer is the tailoring: building sophisticated automations with Invocable Apex actions, or building out a library of Templates. How long depends on your organization’s needs.

One thing: Lightning Web Security must be enabled. It’s on by default in most orgs. This is a hard dependency — with LWS off, Folio Docs will not work. See Check the Prerequisites.

Folio Docs User for everyone who uses Folio. Folio Administrator additionally for anyone managing it. See Assign Permissions.

No. The Folio Administrator permission set gets you into the Admin Panel, but several org-level settings also require Salesforce system permissions — Customize Application, and Modify All Data for Asynchronous Processing. A Folio Administrator without those system permissions sees the affected settings as read-only. See Who can change what.

Choose your Linkable Objects, select Linkable Fields, and turn on Background Jobs. See Admin Panel Settings.

Yes. It schedules search indexing, Team member sharing, the Dashboard’s usage data, version history consolidation, and log and notification cleanup. With it off, search results go stale and retention never runs. See Asynchronous Processing.

Less than most people expect. Salesforce charges ~2 KB per record regardless of content, so a long Document costs the same as a short one. See Data Storage in Folio for the full arithmetic and the retention settings that control growth.

No. A one-line note and a 20-page account plan are both ~2 KB.

Notification, export, log, and version retention are all in the Data Retention section of the Admin Panel’s Settings tab. Versions are roughly two-thirds of all records Folio creates, so halving version retention roughly halves the footprint. See Which objects grow fastest.

No. It removes older change-history snapshots only. Every Document and its current content is untouched.

In your Salesforce org, in custom objects from the managed package. There is no external service and no separate data store.

Only if you want them to. Importing .docx or Markdown files stores each upload as a Salesforce ContentDocument, which is then converted into a Folio Document. Select the After import: Delete the uploaded files checkbox on the import screen and successfully converted uploads are removed, so you aren’t holding a copy of every document in file storage as well as data storage.

Files that fail to convert are kept rather than purged, so you can investigate and retry. See Import and export files.

No — they’re purged on a schedule. Exports are compressed into zip files and stored as ContentDocuments, and Document Export Retention in the Admin Panel’s Data Retention settings purges them automatically. The default is 6 months, and it’s admin-configurable.

See Data Retention.

Yes. Folio never grants a user access they don’t already have in Salesforce. Live Field write-back respects object-, record-, and field-level security, and Get actions run in the running user’s context unless the calling flow is set to system context.

A Queue yes, but not through the Share Document action — it happens automatically when a linked record is owned by a Queue and the object’s Auto-Share Level is Read or Edit. A Role cannot receive a Document share by any route; use a Public Group. See Queue-owned records.

By default it’s archived, not destroyed — the record stays and admins can recover it. Hard delete is disabled by default and configurable. See Delete Permissions.

Query folio__Document__c where folio__Is_Archived__c = true and set the field back to false. See Understand the Folio Data Model.

Yes, in both cases, but the access differs.

When a user is @-mentioned in a Document body, they get access at the level set for the User object under Choose Linkable Objects — None, Read, or Edit. If User isn’t among your Selected Objects, people can’t be @-mentioned in Document bodies at all.

When a user is @-mentioned in a comment, they get read-only access, so the link in their notification opens the Document for them.

See Special case: the User object.

Account, Contact, Opportunity, and Case. For any other object, add an after-save record-triggered Flow calling Folio: Refresh Document from Record Changes. See Set up Real-Time Updates.

Documents linked to that object still show current data on page load. The Flow is only needed for changes to appear live in Documents users are actively viewing at that moment.

Eleven packaged invocable actions covering querying, creating, cloning, sharing, tagging, linking, transferring, and deleting Documents. See Automate with Invocable Apex.

Add a Fault Path and read {!$Flow.FaultMessage}. No action has an errorMessage output, and the success output is only ever true. See Handle Invocable Apex Errors.

Bulk batches don’t partially succeed — one bad request rolls back the entire invocation. Filter inputs upstream.

Yes, on three objects: Document Shares, Junctions, and Tags. Never bulk-delete Documents directly — use the Folio: Delete Document action. See Update Data in Bulk.

No. Only users with Folio Administrator can create, edit, or delete Templates. Users create Documents from them.

It’s almost certainly still in Draft. Only Active Templates can be used, from the UI or from automation. See Template Status.

A Linkable Field is the admin setting permitting Folio to reference a Salesforce field. A Live Field is one of the things that permission unlocks — an inline chip showing that field’s value. The same setting also feeds the Salesforce components. See Choose Linkable Fields.

No. Tags and related records inherited from a Template are locked on the resulting Document. Choose them deliberately.