Library settings provide shared configuration for the services in a library. Use them for library identity, visual styling, security, authentication, integrations, developer access and operational controls. Because a setting can affect more than one service, agree the owner, intended outcome and target environment before you change it.

Find the setting you need

Open the library and select Library settings. The settings navigation is organised into these areas:

flowchart TD
  L[Library] --> S[Library settings]
  L --> U[User management]
  L --> P[Patterns]
  L --> V[Properties and secrets]
  S --> G[General, style and security]
  S --> A[Authentication and sessions]
  S --> I[Integrations and data]
  S --> D[Developer and email]
  S --> Z[Danger zone]

Use the dedicated guide for the screen you are changing:

• General settings
• Style settings
• Security settings
• Authentication settings
• Session settings
• Cloud storage connections
• Third-party API settings
• Email configuration
• Danger zone
• Integrations and data overview
• Patterns
• Properties and secrets
• SharePoint site links
• Data feeds
• User management
• Govforms API keys

Set the library identity

In General settings, use a library name that makes its purpose clear to the people who build and maintain services. The name should distinguish a production service area from a sandbox or team workspace. The optional description is internal: use it to say which services belong in the library, who owns it and any important operating conventions.

The library ID is shown in the Builder and used in URLs and programmatic operations. Treat it as a stable identifier. Changing an established ID can affect service links, integrations, scripts and documentation, so plan and test any change before relying on it.

Style settings affect every service

The live Style settings screen explains that the selected style applies to every service in the library. It includes a preview and supports brand mode, font, scaling, colours, header layout, logo, favicon, footer links, focus treatment and advanced CSS or Sass. It also lets you apply a tested style configuration to QA and production separately.

flowchart TD
    A["Agree the shared brand and accessibility needs"] --> B["Configure and preview style settings"]
    B --> C["Check representative services in Prototype"]
    C --> D["Apply to QA"]
    D --> E["Test key journeys and component states"]
    E --> F["Apply to Production when approved"]

Start with the standard options and use custom CSS or Sass only for a documented need. A style override can alter validation, focus, error and interactive states across all services. Check contrast, keyboard focus, error states, visited links, header and footer content, narrow screens and 200% zoom. Keep logo alternative text accurate, and make the brand link destination meaningful.

Do not use a style setting that relies on a particular audience, organisation or region unless it is appropriate for every service in that library. A library that contains different products is usually better split than forced into a single brand.

Apply changes to the intended environment

Style configuration is managed separately for Prototype, QA and Production. Prototype changes are useful for safe exploration; QA is the place to review the effect on realistic services; Production should only receive an approved configuration. Use the environment-specific Apply and Revert controls deliberately.

Before applying a shared style, identify a representative sample of services with long forms, errors, uploaded files, task lists, review pages and mobile use. A clean preview of one simple page is not enough evidence that every service still works well.

Authentication, sessions and security

The library settings navigation separates authentication, session and security decisions from page content. Configure authentication for the intended people and service type, then test sign-in, sign-out, session expiry, return navigation and access-denied paths. Keep identity-provider client secrets and other credentials in protected configuration; never place them in content, templates, URLs or test answers.

Session settings influence the balance between convenience and protection. A short timeout can be appropriate for sensitive work but can make a long task difficult to complete; a long timeout may be unsuitable for shared devices. Test with the actual user journey and clear guidance about saving or returning.

Manage integrations at library level

The Integrations & data links cover SharePoint sites, cloud storage destinations, data feeds and third-party APIs. These are library resources that services and actions can select. Keep QA and production connections separate, use purpose-led names and restrict each connection to the permissions it needs.

After changing a library integration, identify every service that uses it. Connection tests alone do not prove a journey is correct: test the lookup, upload, no-match, failure and repeat-submission routes in QA.

Use developer settings carefully

Developer settings include programmatic access and library-managed email configuration. Create only the keys and settings needed for a defined owner and purpose. Store secret values securely, rotate them according to your organisation’s process, and remove access that is no longer needed. Do not share credentials in documentation, screenshots, change descriptions or support requests.

Change-management checklist

1. Confirm the correct library and environment.
2. Record what is changing, why, who owns it and which services are affected.
3. Make the smallest safe change in Prototype or QA.
4. Test a representative journey, including access, errors and responsive presentation where relevant.
5. Apply to QA, obtain the required review, then apply to Production.
6. Record the outcome and rollback approach for high-impact changes.

Related guides

• Connect data files and SharePoint
• Design accessible services
• Service identity, lifecycle and administration
• Test, deploy and maintain a service
• Service change management
• Service environments and deployments