Library-level integrations let several services use the same controlled connection. Set up the connection once in the library, select it from the relevant service or action, and keep QA and production configuration separate. Test the person’s journey as well as the technical result: a connection can work but still leave somebody without a useful next step.

Choose the right integration pattern

Use an API action only where the supported actions do not meet the need. It requires more technical configuration and more detailed failure testing.

Understand the configuration layers

flowchart TD
    A["Library connection"] --> B["Separate QA and production settings"]
    B --> C["Service selects the connection"]
    C --> D["Page action uses the connection"]
    D --> E["Person receives a clear outcome"]

In the library’s Integrations & data section, manage SharePoint sites and data feeds. A service then selects the connection in its own configuration. This separation lets a library owner maintain credentials and environment-specific targets without placing sensitive details in page content, templates or action inputs.

Name each connection for what it supports, for example QA supplier reference data or Production application documents. Avoid generic names such as Site 1; they make it much easier to choose the wrong connection during service configuration.

Set up a data feed

Open Data feeds in the library and add a feed. In QA, the source can be an uploaded CSV or Excel file, or a file linked through a configured SharePoint site. When using a spreadsheet, select the intended sheet and starting row. The Builder validates the selected source before it can be applied to QA.

Design the feed as a stable, understandable source of reference data:

• Use a clear header row and stable column names.
• Keep a unique matching value where the service must return one record.
• Confirm that dates, codes, numbers and blank values have the format the service expects.
• Document who owns the source and how often it is updated.
• Use representative, non-sensitive data while testing.

The feed settings support up to 60 columns and 5,000,000 row-column cells. A smaller, purpose-built source is usually easier to validate and quicker for someone else to maintain.

Use Feed Lookup on a page

Add a Feed Lookup action where the service has the value it needs to search for. Map a component answer, context value or fixed value to the chosen feed column. Decide whether the result should be one match, multiple matches, or a single selected column; then store or display the result only after the lookup has run.

Always design the no-match route. A missing record may mean the person mistyped a reference, the data is out of date, or their situation is not supported by the service. Tell them what to do next instead of showing an empty page or a technical error.

Test at least these cases in QA:

1. An exact match.
2. No match.
3. More than one matching record, if duplicates are possible.
4. A matching row with a blank optional value.
5. A changed source file followed by feed validation.

Connect a SharePoint site

In SharePoint sites, create a site link with a friendly name. Configure QA and production separately. Each environment can have its own domain, optional site address, tenant and application identifiers, protected client secret, scope and optional folder. Save and test the settings in the relevant environment before applying them.

The visible site link is a reusable reference, not a place to copy credentials into a service. Keep application secrets protected and give the connection only the permissions it needs. Do not place credentials, tokens, sensitive identifiers or live URLs in documentation examples, templates or test submissions.

Work with lists and files

Use List Lookup to read a list item, then use the result in content, a condition or a later action. Use List Add to insert a new item or update an existing one. For an update (upsert), carry out a lookup first so the service can identify the existing item; otherwise, an update can create duplicates or affect the wrong record.

The visual lookup rules are the clearest option for most services. Use a custom OData filter only when those rules cannot express the query, and record what it is intended to match. Test list permissions, column data types, paging and rows with richer content in QA.

Use Site Upload for documents and generated files. Make the destination and outcome clear to the person where it affects their submission. Confirm which uploaded files or generated outputs should be transferred, and test names, file types, size limits and permission failures.

Protect environments and release safely

QA and production must use their own destinations, list identifiers and credentials. Never test against a live destination unless the test is explicitly authorised and the data is appropriate. After changing a library connection, test every service that uses it in QA before deploying an updated service configuration.

Related guides

• Add actions and workflows
• Write Liquid templates
• Test, deploy and maintain a service
• Library settings

Bulk Data evidence and integrations

The validated CSV includes respondent corrections; the untouched upload is retained separately. Use Upload files to send a selected Bulk Data evidence version to a configured file store. API actions can send up to 25 MiB of combined raw files as Base64; larger files can be streamed through the Bulk Data download API. Submitted revision selection requires retained Response history.

Bulk Data files, submitted revisions and integration examples