Sitecore Connect: Foreach Loop not letting you select the Item Datapill? Here’s the Fix

While building a Sitecore Connect recipe that loops over a set of records returned by a Search/Retrieve step, I ran into an issue that stopped me cold in the middle of an otherwise simple loop. The Search/Retrieve step returned a list of records, the built-in Foreach happily iterated over them, but when I got to the next step inside the loop, I couldn’t select the current item or any of its fields. None of the record’s properties showed up. The datapill picker only offered the loop’s housekeeping pills, and there was no obvious way to reach the actual data I was looping over.

Worth calling out up front: Sitecore Connect is built on Workato, so this is really a Workato Foreach behavior surfacing inside Sitecore’s integration layer. I went looking for a fix online and came up empty — no clear guidance, no documented pattern, just a few unanswered threads describing the same symptom. After a few hours of multiple attempts, I found a workaround that worked. If you’ve hit this wall in either platform, here’s what’s actually happening and the workaround that gets you moving again.

The setup

The recipe is straightforward:

1. A scheduled trigger.
2. A Search step that runs a query against a source system and returns a list/array of records. For this post the source system doesn’t matter — what matters is that the step outputs a collection (I’ll call it Objects) where each element is a record.
3. A Foreach over Objects from the Search step.
4. Inside the loop, a Retrieve an item from Sitecore by its path step, where I need to build the item path dynamically from a field on each record (in my case, an ID field).

Conceptually, each element the loop hands me looks like this:

{
  "index": 9,
  "is_first": false,
  "is_last": true,
  "item": {
    "id": "10010",
    "title": "Sample Record",
    "city": "Hanover",
    "status": "Open"
  }
}

The record data I actually want lives under the item key.

The issue

When I opened the step inside the loop and looked at the Foreach output in the RECIPE DATA panel, the only pills available were the structural ones:

• Index
• Size
• Is first
• Is last

There was no item pill, and no way to expand it to reach the record’s fields. The payload I was looping over simply wasn’t there to pick.

Naturally, I switched the field to Formula mode and tried to reference it by hand. Every variation failed:

• Item.id
• item.id
• item['id']

Each one threw “Formula has errors.” Dragging in a sibling pill I could select — Is first, for example — and then typing .item after it didn’t work either. That just appends .item to the index value, producing something meaningless like Index.item, because the datapills render as opaque tokens and you can’t edit the path inside the token.

Why this happens

The root cause is schema, not syntax — and it’s a Workato Foreach characteristic that Sitecore Connect inherits directly.

When a Search action returns each element of its list as an untyped (dynamic) object, Workato (and therefore Sitecore Connect) has no schema describing what’s inside each element, so the Foreach has nothing to introspect. Without that element schema, it can’t generate draggable pills for item or its sub-properties — which is exactly why the picker only shows the generic loop fields and never the payload.

This is worth internalizing, because it explains why the obvious fixes don’t work:

• You can’t select item because Connect never generated a pill for it.
• You can’t hand-type the path because the pills are opaque tokens, and a bare word like item in Formula mode resolves to nothing.
• Parse JSON should help by imposing a schema, but it needs the raw object as input — and reaching that raw object runs straight back into the same “can’t select the item” problem.

The workaround

After hours of trial and error, I thought to reach the current item via the parent object specifically via Formula mode, and surprisingly it worked! Instead of trying to reach the loop’s current item (which Connect won’t expose), go back to the source list and index into it using the loop counter.

The Objects list from the Search step is selectable — but only in Formula mode, not Text mode. That’s the detail that makes this work, and it’s easy to miss.

Here’s the approach:

1. On the field inside the loop (in my case, the Sitecore Item Path), switch it to Formula mode.
2. Type the literal portion of your value first, e.g. the folder path.
3. From the RECIPE DATA panel, drag the Objects node (the Search step output) into the formula — remember, it only appears as selectable here in Formula mode.
4. Immediately after the dragged Objects pill, type the index accessor using the Foreach Index pill, then the property in bracket notation.

The result for my Item Path field:

"/sitecore/content/YourTenant/YourSite/Data/Records Folder/" + Objects[Index]['id']

Objects[Index] returns the element at the current loop position, and ['id'] drills into the property I need. Because both Objects (the Search step output) and Index (Foreach) are things Connect actually exposes, this sidesteps the untyped-item problem entirely.

A couple of things worth knowing so you don’t second-guess yourself:

The Index is zero-based. In my run the records came through as Index: 0 through Index: 9, with Is last: true landing on 9 across 10 records. That lines up directly with array positions, so Objects[Index] needs no offset.

“Contains 20 items” is not an error. When I set the field to Objects[0], the preview showed “Contains 20 items.” That threw me for a second, but it’s just Workato summarizing the shape of what the pill resolved to — the first record object and its fields. Append the property accessor (Objects[0]['id']) and the preview resolves to the actual value.

After wiring this in, the test ran clean: the Sitecore item was retrieved with the path correctly ending in the record’s ID, straight from the current iteration.

The cleaner fix

The indexing workaround is reliable, but it’s worth being clear about where it sits. Reaching the current element by position is the foundation — but if you want the record’s individual fields as clean, native pills instead of writing Objects[Index]['fieldName'] by hand every time, you can layer a schema on top. A defined schema is preferable for real reasons, not just tidiness: the pills are self-documenting, values keep their proper types instead of being treated as loose strings, and the recipe is easier for someone else to maintain.

When I first looked at this, the schema route seemed closed: the Search action didn’t expose an editable output schema (if the Search/Retrieve action ever exposes an editable output schema, that’s where to define the shape of each record), and a Parse JSON step looked circular because it needs the raw item as input — the very thing the loop wouldn’t hand me. But that circularity is breakable using this same workaround: you feed Parse JSON the current element via Objects[Index], and from there it generates typed pills for every field.

Here’s the approach, with the gotchas that cost me time — none of which are documented anywhere I could find:

1. Inside the loop, add a Parse JSON action before your target step.
2. In Sample document, paste a plain-JSON example of a single record (just the inner object’s fields) you got by following previous steps. This is design-time only — Workato reads it once to build the field pills, so the values are throwaway; only the keys and their types matter. Include every field you’ll need, or no pill is generated for it.
3. In Document, switch to Formula mode and provide the live element. Document input must be a JSON string, which it then parses back into structure. If you pass the resolved object directly, it fails with “Document value is not a string.” Serialize it with .to_json

Objects[Index]['item'].to_json

Once that resolves, Parse JSON’s output exposes native, typed pills — jobReqId, jobTitle, and the rest — that you can drag straight into your downstream steps, no more formulas.

It’s an odd little gotcha, but once you know the item itself won’t surface, reaching back to the parent list is a quick and dependable pattern to keep in your back pocket — in Sitecore Connect and in Workato alike.