Getting data: fetching structured records

1. Getting data: fetching structured records

Chapter one got the flow to start at the right moment. Chapter two is about doing something useful with it, starting with the most common first action in any back-office flow: reading structured records out of a data store.

2. Every connector has a list action

List action names differ. There's List rows on Dataverse, Get items on SharePoint, List rows present in a table on Excel, and Get records on Salesforce. But the shape is the same. Point at a table or list, the action talks to the source, and you get back an array of records the rest of the flow iterates over. In this course the data is on SharePoint, so we'll use Get items as the worked example. Everything you learn transfers to whatever data store your real organisation runs.

3. Anatomy of a Get items action

Open the action and you'll find a Site Address, a List Name, and four advanced settings worth knowing by name. Filter Query takes an OData expression and runs it at the source, so only matching records come back. Order By sorts the result. Top Count caps how many rows you get. Limit Columns by View lets you select a view with a limited number of columns. Without it, every column on every row comes back, which is wasteful. The same four levers exist on the Dataverse, Excel, and Salesforce equivalents under slightly different names. Use Filter Query on every read. Reach for Order By and Top Count when the scenario calls for them.

4. Filtering at the source

Filter Query uses OData, the same syntax that powered trigger conditions in chapter one. The basic shape is field, operator, value. Equality, comparisons, `and` and `or`. The values are where source-specific quirks show up. SharePoint Choice columns expect the display label as a quoted string. Date columns expect a quoted ISO string, which you usually compose with `addDays(utcNow(), N)` wrapped in single quotes and an `@{...}` expression. Dataverse, by contrast, expects an integer code for choice fields. The takeaway: learn the pattern once, look up the quirks per connector.

5. Source-side vs in-flow filtering

Imagine a table with five thousand records where five match the filter. Push the filter to the source and five records come back over the wire. Skip the source filter, fetch everything, and use a Filter Array action later, and the flow drags five thousand rows across the network, then drops most of them on the floor. Same downstream result, but more expensive and way slower. The rule of thumb: if the filter can be expressed in the source's query language, run it at the source. Reach for Filter Array only when the filter logic can't be expressed there, for example when you're filtering on a value that only exists after a lookup or a Compose later in the flow.

6. Trimming the payload

The other free win is trimming the payload. Without a Limit Columns by View, every column on every matching row comes back, including system metadata and audit fields the flow never touches. Listing only the columns the flow references shrinks the payload, speeds up every iteration of the loop downstream, and keeps the dynamic content panel readable. Top Count is the same idea applied to row count: cap how many records the flow processes per run. A small number during development, a sensible production cap when you ship.

7. Let's practice!

Time to add a Get items action and filter the Contracts list.

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.