FolioIntent help
Destinations
A destination is a place you authorize FolioIntent to write a finished output.
Files
Save locally or choose a folder through the system file picker. FolioIntent can confirm its write, but not a later third-party cloud sync.
Photos
Add an image output after you grant Photos permission. This is add-only and does not manage your library.
Paperless-ngx
Upload to a server you configure. FolioIntent records acceptance first and confirms only after task reconciliation supports it.
WebDAV
Write to a configured HTTPS WebDAV endpoint with explicit path and collision behavior.
S3-compatible storage
Sign requests on-device for a configured bucket, region, endpoint, and object path.
Configure safely
- Open FolioIntent Settings, choose Destinations, and add the destination type.
- Use a dedicated, least-privilege account or token where your provider supports one.
- Enter an HTTPS endpoint. Plain HTTP requires an explicit warning opt-in and is restricted to loopback or an unambiguously private local-network host.
- Save, test the connection, then run a non-sensitive sample before sending real documents.
- Confirm the result in both FolioIntent and the destination. Do not retry an ambiguous upload until reconciliation or a destination-side check rules out a duplicate.
What FolioIntent stores
Destination secrets are stored in the device keychain. Workflow and result records store references, not the secret itself. Removing or changing a destination does not make an uncertain prior upload safe to repeat.
Recover an action safely in Runs
- Ready to retry: use Retry action. FolioIntent does not automatically resubmit that state on relaunch.
- Accepted, verifying, or ambiguous: use Check Provider. This observes the existing provider-bound work and cannot create a new submission.
- Authentication required: reconnect the same destination, then use Credentials are updated. That check does not submit anything; use the separately offered Retry action or Check Provider control afterward.
An on-device completion alert is part of a Workflow, not a user destination configuration. If an alert action paused because permission was denied, enabling notification permission only prepares it; scheduling still requires the separate Retry action shown in Runs.