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.

Two things: your org must be on a supported Salesforce edition — Enterprise, Unlimited, Performance, or Developer — and Lightning Web Security must be enabled. LWS is on by default in most orgs, and it’s a hard dependency — with it off, Folio Docs will not work. Professional and Group/Team Editions aren’t currently supported, as they don’t include Apex by default. See Check the Prerequisites.

The Folio Docs License permission set license for everyone, plus one permission set each: Folio Docs User for end users, Folio Docs Administrator for anyone managing it. Admins do not need Folio Docs User as well — Folio Docs Administrator already contains it. See Assign Permissions.

No. The Folio Docs 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 admin 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. Send Email Digests under Notification Email Digest is its own switch. Set it to Disable and leave Background Jobs enabled — every other scheduled job keeps running and no digest email is ever sent. It’s the only background job with an individual off switch.

An Organization-Wide Email Address you choose under Notification Email Digest. Only verified, unrestricted addresses are offered — the address must have Allow All Profiles to Use this From Address enabled, or it won’t appear and digests can’t send from it. A dedicated address such as folio-alerts@yourcompany.com is the recommendation, though a shared systems@ or operations@ works. Give it the display name Folio Notifications either way — that name is what recipients see in their inbox. Without a valid sender, digests don’t send and the Admin Panel shows a failure banner.

Most likely the user who enabled Background Jobs was deactivated. Salesforce runs scheduled jobs as the user who scheduled them, so deactivating that user stops all nine of Folio’s. Any system administrator can fix it by setting Background Jobs to Disable and then Enable again, which reschedules everything under them. A lost Folio license or a frozen account does not cause this — only deactivation. See Asynchronous Processing.

Yes. It schedules search indexing, Team member sharing, the Dashboard’s usage data, version history consolidation, email digests, the Recycle Bin purge, and log, export, 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.

A Salesforce Administrator with View All Data and View All Fields. Both jobs run in the context of the user who starts them, so an export returns only the Documents and related records that user can see — and still reports success — while an import can only resolve record references against records and fields they have access to.

The Folio Docs Administrator permission set opens the Migration tab. It does not grant org-wide visibility, and those are separate things. See Who should run migration jobs.

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 — directly in the Sharing panel, through the Share Document action, or automatically when a linked record it owns has an Auto-Share Level of Read or Edit. A Queue can also own a Document outright. Either way the Queue must list Folio Document among its supported objects first.

A Role, no. Roles cannot receive a Document share by any route; use a Public Group. See Queues.

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.

From the Recycle Bin tab of the Folio Admin app:

1. Open Folio Admin and go to the Recycle Bin tab. It lists every archived Document in the org, whoever owned it, newest first.
2. Find theirs — search by title, owner, or whoever deleted it. The Archived Date and Archived By columns tell you when it went and who did it.
3. Click the row to read it first, if two titles look alike. It opens read-only.
4. Click Restore.

It’s back immediately, with content, comments, Tags, related records, sharing, and version history intact, and the owner is notified that you restored it.

For a bulk restore, set folio__Is_Archived__c back to false on the records directly — see Update Data in Bulk.

6 months by default, then a nightly job purges it permanently — along with its comments, versions, and links. The window is Archived Document Retention in the Data Retention section of the Settings tab; set it to 0 to keep archived Documents indefinitely. Nothing is purged at all while Background Jobs is disabled.

Yes. The Recycle Bin records Archived By and Archived Date on every row, stamped at the moment of deletion. Documents archived before those stamps existed fall back to their last-modified user and date.

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 Docs 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.