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, Govform 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 Govform APIs | Govform API keys | Govform API key settings |
| Configure sender addresses or verify a sending domain | Govform emails | Email configuration |
| Store reusable values for Liquid templates and actions | Properties & secrets | Properties and secrets |
Follow the common environment pattern
Storage links and data feeds use stable library names/IDs with environment-specific configuration. For those pages, configure/test QA, apply it to QA, verify the deployed service, then prepare/apply Production using the page's separate controls.
Do not apply that sequence to every library setting. Properties and Secrets Apply saves edits across environments and publishes both groups; Session, mapping/notification and default email Save controls publish to all available environments after confirmation. Region settings save and distribute automatically. See Shared settings publication.
Test/Validate checks have only their stated scope; they do not imply publication or successful service delivery. Deploy releases a service version separately. Read the relevant environment acknowledgement and deployed service version before concluding that a change 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
For storage links and data feeds with separate environment controls, 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.
Named connections and shared publication
Connections authorise supported external accounts separately per environment for compatible Connector/API actions. Consent, action save and service deployment are separate.
Properties/Secrets and default mapping, notification and email settings now use their documented all-environment Save/Apply controls. Storage links and data feeds retain their own environment workflow. See Shared settings publication before applying a live dependency.