FilePreserveFor FilePreserve, the publisher cannot see your records, your archived files or your AWS credentials in normal operation: the package runs inside your Salesforce org and talks only to your own S3 bucket.
Where the data flows
File bytes go directly between your Salesforce org and an S3 bucket in your own AWS account. The only outside network call the package makes is to that bucket, through a Named Credential your admin configures. The one other outbound item is a one-time welcome email to the installing admin, sent by Salesforce itself. There is no telemetry, analytics callback or support back-channel in the shipped code that sends customer data to FilePreserve's publisher.
Access control inside Salesforce
Every Apex class that reads or writes customer data runs with sharing and enforces field-level and object-level security at the running user's access. Access to the package's screens and objects is controlled by a permission set that is not granted by default.
Encryption
Transfers to S3 use HTTPS, signed with AWS Signature Version 4 by Salesforce's Named Credential layer, so no raw AWS key is stored in code. Encryption at rest is governed by your own bucket settings, and you hold any keys. FilePreserve has no visibility into them.
What is not claimed
FilePreserve is not itself SOC 2, HIPAA or otherwise compliance-certified. Its design choice is that your compliance posture stays governed by your own AWS account and controls. Like any managed package, the publisher may see standard installation and license metadata through Salesforce's partner tooling once it is distributed that way, but not customer record or file data. Read the full security page and privacy policy, and have your own security team review them.
Related
This guide describes how FilePreserve works and is not legal or compliance advice. Reviewed against the FilePreserve product documentation. Have a question? hello@filepreserve.com.