Library integrations and data
Library integrations are reusable connections and credentials shared by services. The Integrations & data and Developer sections of Library settings include SharePoint, three cloud-storage providers, data feeds, supported third-party APIs, Govforms API keys and email configuration.
Use this guide to choose the right settings page and understand the common environment workflow.
Find the right connection
| Need | Settings page | Detailed guide |
|---|---|---|
| Upload to or read from a SharePoint site | SharePoint sites | SharePoint site link settings |
| Store service files in an organisation-controlled bucket or container | AWS S3, Google Cloud Storage or Azure Blob Storage | Cloud storage connections |
| Look up rows from a managed spreadsheet | Data feeds | Feed settings |
| Supply a default credential for a supported external API | Third party APIs | Third-party API settings |
| Let an external application call approved Govforms APIs | Govforms API keys | Govforms API key settings |
| Configure sender addresses or verify a sending domain | Govforms emails | Email configuration |
| Store reusable values for Liquid templates and actions | Properties & secrets | Properties and secrets |
Follow the common environment pattern
Most connections use a stable library-level name or ID with different QA and Production values.
flowchart TD
A[Create stable library connection] --> B[Configure QA values]
B --> C[Save, validate or test]
C --> D[Apply to QA]
D --> E[Test the real service behaviour]
E --> F[Configure Production values]
F --> G[Validate and approve]
G --> H[Apply to Production]
H --> I[Deploy or test dependent service as required]The verbs matter:
- Save records the Builder configuration.
- Test checks a connection or credential.
- Validate checks the structure of a data feed.
- Apply sends library configuration to one environment.
- Deploy releases a selected service version to one environment.
One operation does not imply the others. Read the “last applied” record and the service environment status rather than assuming the latest edit is active.
Name connections for builders
Use a friendly name that states purpose and destination class, such as “Licensing evidence – object storage”. Avoid a person’s name or a name that becomes false after a provider migration. Keep the stable identifier unchanged after services begin to reference it.
Maintain an integration register containing:
- business purpose and owner;
- technical and credential owner;
- QA and Production destinations;
- dependent services and actions;
- permissions and data classification;
- expiry, rotation and failure contacts.
Keep test and live data separate
QA should use non-live accounts, sites, buckets, containers, spreadsheets and recipients. A different credential pointing to the same live destination is not meaningful isolation. Use conspicuous QA names and retention rules so test files cannot be mistaken for operational records.
Never use live personal or sensitive records merely to prove a test connection.
Design for least privilege and failure
Grant each credential only the operations and destination it needs. Test the real service action after the connection test, including denied access, unavailable provider, duplicate file or row, no match and retry behaviour.
Do not expose provider error details or credentials to the end user. Give the user a clear next step and place diagnostic detail in an approved operational log.
Change a shared connection
Before rotating a credential or changing a destination:
- Find every dependent service, action and feed.
- Update and test QA.
- Confirm whether a service-level override takes precedence.
- Apply the library configuration to QA.
- Test the dependent journeys.
- Repeat for Production under change control.
- Revoke the old external credential after successful cutover.
Deleting a library connection does not necessarily delete external data or revoke provider credentials.