Cloud storage connections let services upload, retrieve or delete files in storage controlled by your organisation. A library can connect to AWS S3, Google Cloud Storage and Azure Blob Storage. Each named connection has separate QA and Production details so test files and credentials do not have to touch the live destination.

Open Library settings and choose the required storage provider under Integrations & data.

Choose the right provider and credential

Use the provider already approved for the service and choose the narrowest credential that can perform the required operations. Create dedicated service credentials rather than reusing a person’s account.

Understand the connection model

The bucket link name or container link name is the friendly name builders select in an upload action. It is defined from the QA side and reused for the corresponding Production configuration.

flowchart LR
  A[Named library storage link] --> B[QA connection details]
  A --> C[Production connection details]
  B --> D[Save and test QA]
  C --> E[Save and test Production]
  D --> F[Apply to QA]
  E --> G[Apply to Production]
  F --> H[QA service upload actions]
  G --> I[Production service upload actions]

Saving and testing does not make a connection active in an environment. After a successful test, an administrator must select Apply to QA environment or Apply to Production environment. The screen records the last application user and time.

Configure an AWS S3 bucket

Provide the bucket name and region, then an IAM access key. The credential needs only the object operations used by the service:

• s3:PutObject to upload;
• s3:GetObject to retrieve;
• s3:DeleteObject if the service deletes files;
• s3:ListBucket where listing or the connection test requires it.

Scope the policy to the intended bucket and, where practical, the configured folder prefix. Avoid an account-wide storage policy. The optional prefix places every object under a predictable path without changing each action.

Configure a Google Cloud Storage bucket

Provide the bucket name, project ID and region, then paste the service-account JSON key into the protected credential control. The account needs the equivalent object create, get and delete permissions used by the service. A predefined object-administration role covers those operations, but a custom role can be narrower.

Grant the service account access only to the intended bucket. Rotate the JSON key through an approved process and remove old keys after the Builder connection has been retested and applied.

Configure an Azure Blob Storage container

Provide the storage-account name, container name and region. The protected connection-string field can hold a full account connection string, but a scoped SAS connection string is preferable where it meets the need. Include only required permissions: read, write, delete and list as applicable.

Limit the credential to the intended container and lifetime. A full account key can reach more than the selected container, even though the Builder configuration names one destination.

Use folder prefixes well

A folder prefix is prepended to every object path. Use a stable, readable structure such as applications/evidence. Do not include a user-supplied filename or personal identifier in the library prefix; construct per-submission paths in the action where supported.

Changing a prefix changes where new files are written. It does not move files already stored under the previous prefix. Plan retrieval and retention before switching an active connection.

Test, apply and prove the journey

1. Configure QA with a non-live destination and test credential.
2. Select Save and test settings and review the provider error if it fails.
3. After a successful test, apply the connection to QA.
4. Run the real upload action from a QA service.
5. Confirm the file name, content, metadata and folder at the destination.
6. Test retrieval and deletion if the journey uses them.
7. Repeat configuration and validation for Production, then apply it only after approval.

A connection test proves basic access; it does not prove that the service uses the correct link, builds a safe object path or handles an unavailable provider. Test duplicate filenames, large files, disallowed file types and provider failure.

Change or remove a connection

Before changing credentials, region, bucket, container or prefix, identify every action that uses the friendly link. Rotate credentials by updating and testing one environment at a time. Deleting the library link can break dependent actions and does not delete objects from the cloud provider.

Related guides

• Library integrations and data
• Site upload actions
• Service files, email and integrations
• Properties and secrets