The team, the references, the spring courses, the dishes on the seasonal menu: on many small business websites, the same structure repeats entry after entry. Name, photo, role. Project, image, location, completion. Course, date, sign-up. If you build such content as individual pages and copy the last page for every new case, the cost usually shows later: the details soon appear in a different order, spellings drift apart, and any change to the layout has to be repeated on every copy. A collection reverses this. You define once which fields an entry has and then only fill in entries; the display on the website follows from the fields. This article covers the questions before and after: which content needs a collection of its own, when is the price list block the better tool, how do you plan fields that still fit years later, and which upkeep mistakes creep in during daily work? How list and detail page work together technically is shown in the article on the architecture firm website with project pages using one example; this one is about the principle for every trade.
When content needs a collection of its own
According to the product documentation, a collection is a set of similar data records. You define once which fields a record has and then fill in as many entries as you like.
The documentation on content, media and blog names references, team profiles and a menu as typical examples, meaning content that repeats in the same shape. So the deciding feature is not the amount but the uniformity. Even a small team with photo, role and a short text meets this criterion. A long text about the history of the business is not, even if it runs to many paragraphs: there is no second entry built the same way. Five questions help with the decision. The first has to be answered with yes, and every further yes strengthens the case:
- Does the structure repeat? If every entry carries the same details, such as name, photo and role, a collection fits. If every case has to be told differently, a page of its own or a blog post is the better choice.
- Does the content change independently of the page layout? New staff, a finished project, an extra course date: whoever records this should create an entry, not rebuild a page.
- Does the same content appear in several places? Some references on the home page and all of them on the references page can come from one source instead of being maintained twice.
- Does each entry need its own address? A project you link in a quote, or a course a partner is meant to point to, benefits from a detail page of its own.
- Do several people help maintain it? Fixed fields set a form that even a stand-in who did not build the website will follow.
If the first answer is already no, the content is better off as a block on a page. That applies to the steps of a job, whose order tells a story and which belong together on one page; the article on showing your work process shows what that looks like. It also applies to opening hours, directions or a single notice. A course schedule with dates, venue and sign-up route, on the other hand, has every feature of a collection; what matters in terms of content for prevention courses is covered in the article on the course schedule and subsidy. For some of this content, XICflow also has blocks of its own that are maintained directly on the page: “Team” for people with photo, role and short bio, “Job openings” for vacancies and “Events” for single dates. As with the menu in the next section, such a block is the shorter route as long as the content stays on one page; a collection pays off once one of the reasons from the list above comes into play. The overview below sorts common content:
Scroll table sideways
| Content | Collection of its own? | Detail page per entry? |
|---|---|---|
| Team | Yes, if it appears in several places or needs fixed roles; otherwise the “Team” block is enough | Rarely needed, the card with photo, role and short text does the job |
| References and projects | included | Often useful, because projects get linked and searched for |
| Courses and dates | Yes, for a changing course schedule; single events can also go in the “Events” block | When content, schedule and sign-up fill more than a card |
| Job openings | Yes, if you advertise regularly; for a few openings there is the “Job openings” block | Yes, so every opening has its own address |
| Menu or treatment list with prices | Usually not, the price list block covers it | not included |
| Steps of a job | No, a block on the page | not included |
| Opening hours and directions | not included | not included |
Menu: price list or collection?
The menu is in the title of this article because it shows the difference between two tools. The documentation does show an example “Menu” collection with the fields dish, description and course.
For the classic menu with prices, however, there is a block of its own, the price list. Its description in the block overview reads:
List of individual services with prices, in the style of a menu or treatment card.
Scroll table sideways
| Feature | Price list | Collection |
|---|---|---|
| Where it is maintained | In the editor, directly on the page | In the content area (CMS), separate from the pages |
| Structure of a row | Fixed: section, name, description, price, note, marks | Free: exactly the fields you create |
| Marks and legend | Built in, the legend appears once below the list | Not provided |
| Display | Lines, leader dots or cards | Grid or list |
| Several pages | One block per page | One source, as many CMS lists as you like |
| Page of its own per entry | not included | Optional, title and description from the fields |
| Preparing without showing | Hide the block | Save the entry as “Draft” |
For most menus, the price list is therefore the right tool. The menu sits on one page, sections divide it into starters, mains and drinks, and marks appear in superscript next to the name. The block documentation points out that in Germany the legend is mandatory for menus as soon as additives or allergens are marked; a collection has no mechanism of its own for this labeling. Putting dishes into a collection only pays off when one of the reasons from the first section comes into play: a lunch special that should appear on both the home page and the menu page, or set menus for celebrations that are each meant to get a page of their own with schedule and notes. What makes a good menu in terms of content, from allergens to the price list at the entrance, is covered in the article on the restaurant website with menu and reservations. Practices, salons and studios face the same choice: a treatment list with prices belongs in the price list, a course schedule with dates in a collection.
Plan the fields before the first entry
Fields can be added later, and existing entries keep their values.
Planning before the first entry still pays off, because every field shows up in every entry, and once something is inconsistent across many entries, nobody enjoys cleaning it up. The documentation therefore explicitly recommends few, clear fields: start with the details you reliably have for each record. Technically, far more would be possible. A collection holds up to 100 fields (XICflow documentation), and a single entry may carry at most roughly 256 kilobytes of field content (XICflow documentation); above that, XICflow refuses to save it and reports that the record is too large. A team or reference collection hardly comes near these limits. The real limit is the time someone has to fill in the fields: a field that stays empty in many entries is a sign that it is not needed.
Plan from the output. On the website, entries appear through the “CMS list” block, as cards in a grid or as a list. The card shows the first image field as its thumbnail, the first text field as its title and the remaining fields below (XICflow documentation), each preceded by its label. With the card in mind, you decide three things differently:
- The heading is the first text field. Every new collection comes with the required “Title” field of type text for this purpose. If someone moves another text field such as “Position” above it, the position becomes the heading of the card.
- Whatever goes into a field is public. The field settings have no option that keeps a field internal. A note such as “Approval received by email” would appear on the card. Internal notes belong in your own records; whether an entry may go on the website yet is decided by its status.
- Recurring values become select fields. Role, sector, course type or the course on the menu are then spelled the same way in every entry. A select field holds up to 200 values, each at most 190 characters long (XICflow documentation).
In total, nine field types (XICflow documentation) are available: text, text area, rich text, number, yes/no, image, URL, date and select. The field type decides two things: how you enter a value and how it appears on a detail page. Text areas and rich text become a subheading with a paragraph there, a URL field becomes a button labeled with the field name, and all short details end up in a fact list. A yes/no field appears there and on the card as “Ja” or “Nein”. It therefore suits public details such as “places available”, not internal check marks. The overview assigns typical details:
Scroll table sideways
| Detail | Field type | Why |
|---|---|---|
| Name, project title, course name | Text, as the first text field | Becomes the card heading and the detail page title |
| Portrait, project photo | Image | The first image field is the card thumbnail and the sharing image |
| Role, sector, course type, menu course | Select | Same spelling in every entry |
| Short description, task and solution | Text area | The first longer text field supplies the detail page description |
| Course date, completion | Date | Entered consistently, one row in the fact list |
| Sign-up, a partner’s page | URL | Appears as a button |
| Places available, step-free access | Yes/no | Only for details that may publicly read “Ja” or “Nein” |
| Number of participants, floor area | Number | Pure numeric values; the unit belongs in the label |
Changing a field type later
Team: roles instead of free text
For a team that only appears on one page, the “Team” block is often enough: name, role, photo and short bio, optionally a direct line and email, maintained directly in the editor.
The role is free text there, however, and there is no status per person and no detail page. As a collection, the team page is still a good place to start, because all the planning rules can be tried out on it. The name comes first as a text field and becomes the heading. The photo follows as an image field; on the card, the name also serves as the photo’s alternative text, so a carefully maintained name labels the image as well. The role becomes a select field. The reason only shows after months: without fixed options, the same position soon appears as “master electrician”, “electrical master” and “master in the electrical trade” on the same page, depending on who last edited it. The short profile becomes a text area, so that it appears as a paragraph on a detail page and supplies its description, should the collection get detail pages later. A lean field plan looks like this:
Name (plural): Team Singular name: Person
Slug field: Name Create detail pages per entry: off
Field Field type Required Purpose
Name Text yes Heading of the card
Photo Image no Thumbnail, address from the media library
Role Select yes Owner, Master craftsperson, Skilled worker,
Apprentice, Office
Short profile Text area no Task and experience in a few sentences
Languages Text no only if customers ask for itFor photos of employees, the right to one’s own image applies. Under Section 22 of the German Art Copyright Act (KUG), portraits may only be distributed or publicly displayed with the consent of the person depicted. Where publication relies on consent under data protection law, the person concerned can withdraw it at any time under Article 7(3) of the General Data Protection Regulation (GDPR). How consent, withdrawal and leftover material are handled when someone leaves is described in the article on image rights for team and stock photos. For the collection, this means in practice: if someone leaves the business or withdraws consent, set the entry to “Draft” and publish the website again. Only then does it disappear, because only published entries appear on the website and every change only becomes visible with the next publish. If the photo may no longer be used at all, also delete it in the media library.
References: titles that stand apart
References are where detail pages pay off most. A project can be linked in a quote, and someone searching for a particular job can land directly on the matching project.
With the option “Create detail pages per entry”, every published entry gets its own subpage when you publish. Title and description are created automatically: the title from the title field, the description from the first longer text field, shortened to about 155 characters (XICflow documentation). Two fields thus supply the template for the entry in the search results. Until the client has agreed to be named, the entry stays a “Draft”; what needs to be clarified legally is covered in the article on showing client references and logos. For the title field, what Google recommends for every page then applies:
Make sure every page on your site has a title specified in the
<title>element.
The same page advises against vague descriptors and gives “Profile” for a specific person’s profile as an example (Google Search Central). Applied to a collection, this means: a title field reading “Reference”, “Project” or “Bathroom renovation” produces pages that cannot be told apart in the search results. A better title carries what sets one project apart from the others, meaning the task and its particular feature, for example “Bathroom renovation with a level-access shower in an old building”. For the team, it is the name, not the position. As the title field is a required field from the start, an entry without a title cannot be saved; keeping the title distinctive is the editors’ job.
The same goes for the description. Google notes that it does not help users if every page of a site has the same or a similar description, and states: “Page-specific data is a good candidate for programmatic generation” (Google Search Central). That is exactly how the detail page works: it takes the beginning of the first longer text field. So write the first sentence of that field as a summary with task, result and location, not as a run-up like “In spring, a customer got in touch with us”. Whatever follows after about 155 characters (XICflow documentation) remains on the page, but no longer in the description.
Upkeep mistakes that creep in
Many upkeep mistakes share the same root: work on a collection is split into two steps, editing in the management view and publishing the website.
If you only do the first, you see the right state in the management view and the old one on the website. On top of that, a few properties are worth knowing before the collection grows:
- Saved does not mean visible. New and changed entries first exist only in the management view. They appear on the website once the website is published again in the editor, and only with the status “Published”.
- Expired entries stay put. A course from October does not disappear by itself; the CMS list shows every published entry. Set past dates to “Draft” or delete them.
- The order is an editorial decision. Entries are listed in the order they have in the management view, not by date or alphabet; the block offers no sorting option. A newly created entry initially sits at the end.
- The slug stays as it was created on first save. If you leave the “Slug” field empty, XICflow builds it from the slug field, usually the title. Correcting the title later does not change it. If you create an entry under a working title such as “Test”, correct the slug before the first publish, because it is part of the detail page’s address.
- Empty fields in a second language take the base language. On multilingual websites, the English version, for instance, shows the German value for an empty field. That prevents empty cards but puts German sentences on English pages when a translation is forgotten. XICflow checks required fields only in the base language.
- A deleted collection takes its entries with it. XICflow asks first and states the number of entries affected; if you confirm, they are lost along with it.
- Images belong in your own media library. An image field takes an address. Use the address from your media library, which you copy there with a click on the image, not that of an image on someone else’s website, which may vanish tomorrow or not be licensed for you.
An upkeep rhythm that holds
A collection is as current as its last pass.
Upkeep gets easier when it is tied to occasions rather than good intentions: a new employee on their first working day, a project at handover, a course schedule when the next half-year is planned. How the material for this comes together alongside daily work is shown in the article on collecting website content during daily work. A routine for the typical occasions:
- New team member: obtain consent for the photo and profile details, create the entry as “Draft”, publish after approval.
- Someone leaves: set the entry to “Draft” or delete it, publish the website, check the photo in the media library.
- Project completed: record image, task and particular feature, ask the client for approval, prepare the entry.
- New course term: take past dates off the list, create new ones in the desired order.
- Multilingual website: fill in the second language before a new entry is published.
- Once a quarter: look at the list on the live website, check the select values, delete orphaned entries.
In XICflow, collections live in the content area (CMS), separate from the pages, and each belongs to exactly one website. They reach a page through the “CMS list” block, which you add in the Flow Builder – Product like any other block: choose the collection, set the display as grid or list, the number of columns and the maximum count. That way the home page shows the first entries of a collection and a subpage shows all of them, from the same source. How to present a service area with references instead of stacked city pages is described in the article on the service area page. A collection does not save work on day one, but in the months that follow: if you plan fields from the output, keep roles and categories as select fields, write distinguishable titles and publish after every change, you have a collection that a stand-in can maintain too, without touching a page.