Personas Collection Reference

Last Updated: August 12, 2026 | Audience: Everyone

Status: Empty and Not Yet Live

The Personas collection exists with a full schema but zero items. Its template page is at /role/{slug}. Nothing is live and nothing links to it yet.

Note the slug mismatch: the collection is displayed as "Personas" but its slug is role, which is why persona pages will publish under /role/. That was a naming decision made at creation and cannot be changed without breaking URLs later, so plan around it.

What It Is For

Two jobs, and it is worth being clear which is which:

1. A tagging vocabulary. Other collections reference Personas so content can be filtered by audience. The FAQs collection already has a Personas field waiting on this. This works as soon as items exist, with no landing pages needed.
2. Audience landing pages. A persona with the Public Page switch on gets a full page at /role/{slug} built on the StoryBrand structure.

You can do the first without the second. Populating the Core fields alone makes persona tagging work across the site.

Fields

Core — enough for tagging

• Name — The public-facing audience label, like "IP Professionals" or "R&D Scientists." This renders anywhere the persona appears: filter chips, tag pills, headings. Use audience language, not internal persona-speak.
• Internal Persona Name — The name from the marketing persona docs, "IP Attorney Ian" style. Never rendered on the site. It exists so whoever is tagging content can map the CMS item back to the source documentation without guessing.
• Short Description — One or two sentences describing the audience. Plain text deliberately, so it works in cards, filter tooltips, and meta descriptions without markup getting in the way.
• Sort Order — Display order in filter UIs and "who we serve" grids. Alphabetical almost never matches business priority.

Landing page — only when the persona gets a page

• Hero Headline — The "what this audience wants" statement. In StoryBrand terms, the character-wants line.
• Overview (Rich Text) — Who this audience is and the world they work in. The page intro.
• Pain Points (Rich Text) — The problem section. What is hard about their work that CAS addresses.
• How CAS Helps (Rich Text) — The guide-and-plan section. Keep it outcome-focused rather than a product list; the solutions block below handles products.
• Related Solutions (MultiReference to CAS Solutions) — Three to five solutions this persona cares about, in priority order. MultiReferences preserve the order you add them. This renders through the template's one allowed nested collection list, which caps at 5 items, so five is the practical maximum.
• Spotlight Resource (single Reference to CAS Insights) — One hand-picked featured article. Single reference on purpose: single refs let you bind the referenced item's fields directly on the page with no nested list, and the nested list slot is already spent on Related Solutions.
• CTA Label and CTA Link — The persona-specific conversion action. "Talk to an IP specialist" converts differently than a generic "Contact us."
• Meta Title, Meta Description

Ops and integration

• HubSpot Persona Value — The matching value in HubSpot, so persona segmentation lines up between the site and the CRM.
• Public Page (Switch) — Whether this persona has a live landing page. Leave off for tagging-only personas.

The Nested List Constraint

Worth understanding before designing a persona page, because it drives several of the field choices above. A Webflow collection template page allows one nested collection list. On this template it is spent on Related Solutions.

Everything else on the page — tagged CAS Insights, FAQs, testimonials, webinars — comes from native "contains current persona" filters on separate collection lists rather than nested references, which is why those relationships do not need fields here at all. If someone asks for a second nested reference list on a persona page, the answer involves restructuring, not adding a field.

Before Populating

One decision needs making first: whether persona names on the site should match the marketing team's internal persona set one-to-one, or whether the site uses a smaller, broader set. That choice determines how many items go in and how content gets tagged, and reversing it later means re-tagging everything. Confirm with Jimmy before creating items.