List lookup actions
Use a list lookup action to retrieve one or more items from a configured SharePoint list. It can support a search page, find an existing item before an add-or-update operation, or bring a controlled list value into the journey.
Keep lookup rules narrow and explainable. A list search that returns unexpected matches can make a person see the wrong information or cause a later action to update the wrong record.
Set up the connection and result shape
Select the configured SharePoint site and the matching QA and production lists. Then decide whether the action should return one result, multiple results, or a single value from one column.
flowchart LR
A[Search value or earlier result] --> B[List lookup rules]
B --> C{Results}
C -- One intended item --> D[Use or update item]
C -- Several items --> E[Present or process the result set]
C -- No items --> F[Show the designed no-match route]Choose Single result only where the rules identify one record. Choose Multiple results when the service is designed to handle a set of records, for example a search result table. Use Limit results to column when a later action requires only a single column value rather than the full record.
Add matching rules
Data feed elements define the comparisons used to filter the list. Match a field, earlier action result or controlled value to the relevant list column. Use exact matching for identifiers; use partial or fuzzy matching only for a deliberate search experience with clear user guidance.
When there are several rules, use all of them when each must pass—such as matching both a reference and a status. Use any of them only when either rule is intentionally enough. Test changed letter case, leading spaces, blank values and duplicate records, as these are common causes of misleading results.
Use a custom OData filter expression only when the standard rule configuration cannot express the required query. It overrides the configured rules, so record why it is needed, have it reviewed by the list owner, and test it with realistic values. A custom query is powerful but harder for a future service author to maintain.
Control large result sets
For a rich or large list, configure paging deliberately. A fresh lookup starts a new result set; next, previous and current modes are used with the action’s paging information to navigate it. The page size can be from 1 to 1000 items.
Start with the smallest page size that supports the user task. Smaller pages reduce the amount of data processed at once and make a results screen easier to understand. Test first, next, previous and final pages, plus a search that returns no records.
Do not request a large result set simply because the list has many items. Improve filtering before increasing the page size.
Use lookup results safely
An action result can be used by a component, condition, template or a following list add action. Give the action an ID that describes its purpose, such as find_existing_case, and ensure consumers run after it.
For an add-or-update flow, configure the list lookup first and reference its Action ID from the list add action. The lookup needs a dependable business key; broad lookup rules should never decide which record to update.
Design an explicit no-match outcome. It might offer another search, direct the person to enter a new record, or route the case to a team. Do not silently continue with empty data.
Test checklist
- QA and production point to the intended, separate lists.
- Rules match the correct columns using the appropriate comparison type.
- The selected result mode reflects the business expectation.
- The no-match, duplicate and unexpectedly broad-result paths are designed and tested.
- Custom OData is justified, reviewed and tested independently.
- Paging works across first, next, previous and final result pages.
- An add-or-update action uses this lookup only with a reliable unique key.