Multi-collection lists

One merged, searchable, filterable list across several collections - blog posts, news, events, docs - driven by a collection group you define in the dashboard. Everything a single-collection list can do works on the merged result.

Shared setup - the script tag, keys, and data binding - is in the getting started guide. For one relevance-ranked search box across the whole site, see global site search; a group is the right tool when you want to choose the collections and keep full filtering.

1. Create a group in the dashboard

In your site's dashboard, open Data → Groups and create a group: a name, a slug, and the member collections. The slug is the group's stable handle - it appears in the endpoint URL /{siteId}/group/{slug} and is what the embed references. Each group row has a copyable endpoint URL and starter embed snippet.

Requires the site's Data plan, like every list endpoint. Members whose collection endpoint is disabled (Data → Settings) stay in the group but are skipped until re-enabled - the dashboard flags them.

2. Minimal setup

<div data-slater-list="resources" data-slater-group="resources">
  <div data-slater-results="resources">
    <div data-slater-template>
      <h3 data-slater-bind-text="name"></h3>
    </div>
  </div>
</div>
<div data-slater-empty="resources">No results.</div>

Attribute	On	Value	Required
`data-slater-list`	a wrapper (plain div)	the block's key	yes
`data-slater-group`	the same wrapper	the group's slug from the dashboard	yes - it replaces `data-slater-collection`, which is ignored when both are set
`data-slater-results`	the items container	the key	recommended (see the callout below)

A group list's results container is fully re-rendered on every load - unlike a global search block. Keep the search input, data-slater-empty, data-slater-count and other state elements outside data-slater-results, or the first render wipes them.

Your authored template cards stay visible until the first successful response (they're the page's fallback if the API is unreachable), so design them as real-looking cards. Config-block equivalent: SlaterSearchConfig.lists = { resources: { group: "resources" } }.

Different cards per collection

Items from different collections rarely share a layout. Exactly like global search, a valued template renders only that collection's items (the value is the member collection's slug) and the valueless one is the default:

<div data-slater-results="resources">
  <!-- default card for any collection without its own template -->
  <a class="card" data-slater-template data-slater-item-href>
    <h3 data-slater-bind-text="name"></h3>
    <span data-slater-bind-text="collection"></span>
  </a>
  <!-- blog gets its own layout; link = the item's server-resolved url -->
  <a class="card card--blog" data-slater-template="blog" data-slater-item-href>
    <img data-slater-bind-src="main-image" data-slater-bind-alt="name" />
    <h3 data-slater-bind-text="name"></h3>
  </a>
  <!-- news overrides the link pattern -->
  <a class="card card--news" data-slater-template="news" data-slater-href="/newsroom/{slug}">
    <h3 data-slater-bind-text="name"></h3>
  </a>
</div>

Every item carries a derived collection field - its collection's slug - bindable like any other field. In the default card, bind fields the members share (name, slug, createdOn…); a bound field an item lacks renders empty, and data-slater-hide-empty hides its node.

Letting visitors narrow by collection

collection is a reserved filter field on group lists - it matches member collection slugs. The standard filtering markup just works, and data-slater-facets="collection" auto-fills an empty select with the member collections:

<!-- auto-fills from the facet: collection NAMES shown, slugs sent -->
<select data-slater-filter="collection" data-slater-for="resources">
  <option value="">All types</option>
</select>
<input type="text" data-slater-search="resources" placeholder="Search…" />
<span data-slater-count="resources"></span> results

<div data-slater-list="resources" data-slater-group="resources"
     data-slater-facets="collection">
  …
</div>

Checkboxes and radios work too - set data-slater-value to the member collection's slug:

<label><input type="checkbox" data-slater-filter="collection"
  data-slater-value="blog" data-slater-for="resources" /> Blog</label>
<label><input type="checkbox" data-slater-filter="collection"
  data-slater-value="news" data-slater-for="resources" /> News</label>

The reserved key wins over a real CMS field that happens to be slugged collection - filter that field under another name. A page-scoped subset needs no controls at all: SlaterSearchConfig.lists.resources.filter = { collection: ["blog", "news"] }.

Everything else works unchanged

Feature	On a group list
Keyword search	searches across every member collection
Filters, sorting & facets	work on the union of member fields; facet zero-counts merge every member's options
Load more	unchanged
`data-slater-expand`	each item expands against its own collection's reference fields
`data-slater-search-fields`	resolved against the union of member fields; unknown ones warn
count / empty / clear / `data-slater-for` / JS hooks	unchanged

Limits

Sorting on a field only some members have puts the items without it last.
A 404 in the console (Group "…" was not found) means the slug doesn't match a group in Data → Groups - or the group has no enabled member collections.
Deleting a group (or renaming its slug) breaks embeds that reference the old slug - published pages keep whatever Webflow rendered, but stop loading fresh data.