Choosing a storage provider
Use this page to pick a provider before you start a setup guide. It compares what you create on the provider side, what Sliick sets up for you, and where the file bytes travel.
If you are happy to keep files in Salesforce Files, you do not need any of this. Storage only needs configuring when you want files kept somewhere else.
The three modes
Section titled “The three modes”| Mode | Where files are stored | Setup effort |
|---|---|---|
| Salesforce Files (default) | Inside Salesforce, against your Salesforce file storage | None |
| Sliick Cloud Storage | Storage Sliick operates, kept separate per org | Low: designate an Integration User, then one click |
| Your own storage | Your own S3 bucket, Google Cloud bucket, Azure container, SharePoint site, or an S3-compatible provider | Moderate: create the storage, configure a cross-origin rule, enter credentials |
Start on Salesforce Files to confirm the package works, then connect storage if you need it.
Bringing your own storage, at a glance
Section titled “Bringing your own storage, at a glance”| Provider | You create on the provider side | You paste into Sliick Settings |
|---|---|---|
| Amazon S3 (and S3-compatible) | A bucket, CORS rules, an access key scoped to that bucket | Integration User, Access Key ID, Secret Access Key, Bucket Name, Region, and Endpoint for non-AWS providers |
| Azure Blob Storage | A storage account, a container, CORS rules on the account | Integration User, Account Name, Account Key, Container Name |
| Google Cloud Storage | A project, a bucket, CORS rules, a service account with an HMAC key | Integration User, HMAC Access Key, HMAC Secret, Bucket Name, Region |
| SharePoint | An Entra ID app registration, a client secret, a per-site access grant | Integration User, Authentication Mode, Site URL |
Every provider, Sliick Cloud Storage included, needs the same dedicated Integration User, set up once per org before you connect: see Set up the Integration User.
S3-compatible providers (Backblaze B2, Wasabi, Cloudflare R2, MinIO) use the same Sliick Settings form as Amazon S3, and the Salesforce side is identical. See S3-compatible providers and the worked Wasabi guide.
Where CORS is configured
Section titled “Where CORS is configured”Every provider except SharePoint and Sliick Cloud Storage needs a cross-origin rule so that browser uploads reach the storage. This is the step people most often skip, and each provider puts it somewhere different.
| Provider | Where you set it |
|---|---|
| Amazon S3 | On the bucket, Permissions → Cross-origin resource sharing (CORS) |
| S3-compatible providers | On the bucket, in that provider’s own console |
| Azure Blob Storage | On the storage account, Resource sharing (CORS), not on the container |
| Google Cloud Storage | Not available in the console. Applied with the gcloud command line |
What is automatic and what you do
Section titled “What is automatic and what you do”| Component | Who configures it |
|---|---|
| The storage credential for S3, Azure and Google Cloud | Automatic. Set up for you when you click Connect, with no Setup edits |
| The storage credential for SharePoint | You start it: click Create SharePoint Credentials in Sliick Settings, then finish the details in Setup |
| Everything for Sliick Cloud Storage | Automatic. There are no credentials to enter at all |
| Your provider settings (keys, bucket, container, site) | You enter them once in Sliick Settings |
| Permission-set grant for the storage principal | You add External Credential Principal Access and assign it to your storage users. Not needed for Sliick Cloud Storage |
The keys you get from your provider are only ever entered in Sliick Settings, never in Salesforce Setup. The permission-set grant simply authorises your users to use the credential Sliick created.
What each provider supports
Section titled “What each provider supports”| Amazon S3 | S3-compatible | Google Cloud | Azure | SharePoint | Sliick Cloud | |
|---|---|---|---|---|---|---|
| Media processing for images | Yes | Yes | Yes | Yes | No | Yes |
| Restore a deleted file | With bucket versioning | With bucket versioning | With Object Versioning | With soft delete | In SharePoint’s recycle bin | No |
| Two-way sync | Yes | No | Yes, except deletes | Yes, except deletes | Yes, except in per-user mode | No |
| Share links | Yes | Yes | Yes | Yes | Yes | Yes |
Two-way sync and share links are premium features Sliick switches on for your org. See Two-way sync.
Data residency
Section titled “Data residency”For Amazon S3, Azure Blob Storage and Google Cloud Storage, file bytes travel from the browser straight to your own storage. Salesforce is the access-control gatekeeper, but the bytes themselves never pass through Sliick-operated infrastructure.
| Provider | Default path for file bytes | Details |
|---|---|---|
| Amazon S3 | Browser to your S3 bucket directly, over presigned URLs | Data residency |
| Azure Blob Storage | Browser to your Azure Blob container directly, over SAS URLs | Data residency |
| Google Cloud Storage | Browser to your GCS bucket directly, over signed URLs | Data residency |
There is one opt-in exception. Media processing routes newly uploaded image files through Sliick’s processing service. It is off by default. Read your provider’s data residency page before you turn it on, and see Media processing for images.
SharePoint has two authentication modes
Section titled “SharePoint has two authentication modes”SharePoint is the only provider where you also pick how Sliick authenticates: Service Principal (the app signs in as itself) or Delegated (each Salesforce user signs in to Microsoft once). See Choosing an authentication mode.