# Library settings Source: https://govform.com/resources/documentation/article/20-library-settings Topic: Library Settings 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: | Area | What it controls | | --- | --- | | **General settings** | Library name, library ID and description. | | **Style settings** | Shared branding, typography, colours, header, footer and style customisation. | | **Security settings** | Library-wide controls that protect Builder use. | | **Authentication** and **Session settings** | How people access services and how their sessions behave. | | **Integrations & data** | Storage connections, data feeds and external API settings. | | **Developer** | Programmatic access and library-managed email configuration. | | **Danger zone** | High-impact operations that need careful confirmation. | ``` 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]() - [Govform 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. It is read-only in General settings; use the displayed ID when configuring integrations or contacting Support. ## 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. ## Configure the User portal Use **User portal** in the Builder sidebar to select signed-in services and Collection programmes, customise cards and organise them into categories. Portal publication is separate from service deployment. See [Set up a User portal and service categories](). ## Change-management checklist 1. Confirm the library and affected environments, including Production. 2. Record the purpose, owner and dependent services. 3. Read the page's publication controls: some shared settings update all available environments after one Save/Apply; style, authentication, storage and feed pages retain their own environment workflow. 4. Where separate environment controls exist, apply/test in QA before Production. For all-environment settings, prepare and review the live impact before confirming. 5. Check delivery/deployment status and test a representative service, including access and error paths. 6. Record the outcome and recovery approach for a significant operational change. See [Shared settings publication]() for the control-by-control reference. ## Regional defaults and shared publication **Library design → Region settings** sets country, regional format, Service time zone and currency. Saving distributes these defaults automatically; it can change formatting and day-boundary calculations in live services. See the [regional settings reference](). Properties, Secrets, Session settings and the mapping/notification/email defaults have their own all-environment Save/Apply behaviour. The separate-environment style workflow above does not apply to every settings page. Read [Save, apply and deploy shared library settings]() before making a change. ## 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]() ## Investigate service and library operations Open **Library administration → Actions Log** to find recorded outcomes and retained diagnostics. Administrators can also ask Darcy or an authorised MCP client to inspect relevant events, including after a user-performed QA test. See [Actions Log guidance](). From a service, page, Service settings, Environments or service-response screen, use the **Library** link in the **Location** trail to reach **Library administration**. Those sidebars focus on the service. Library-level product screens retain administration links for permitted users. The Location trail includes Response Hub, Documents or Data Rooms where relevant. **My profile** and **Approvals** also link to each other under **Your account**.