Creating Data Design

A Data Design is a reusable visual layout for displaying dynamic content. Create the layout in the Page Editor, add the Page Elements that make up one item, and configure the parts that should receive different values when the design is rendered.

Use Data Design for product cards, search results, profile summaries, custom record rows, and other interfaces where the same visual structure should be repeated with different data.

A Data Design defines one item, not the entire list. The design acts as a reusable source pattern. A Page workflow or other supported rendering behavior supplies data and places the rendered items into a separate area of the Page.

For an introduction to the overall capability, see Data Design.

Before You Begin

Before creating a Data Design, decide what one rendered item should represent.

For example:

Experience	One Data Design represents
Product catalog	One product card.
Search results	One search result.
Member directory	One member profile.
Order summary	One order summary block.
Dashboard	One metric or summary tile.
Custom record list	One record row or grouped record panel.

Also consider:

• Content: Which text, images, statuses, and actions should each item contain?
• Dynamic values: Which properties change from one item to the next?
• Data: What Project data or prepared values will supply those properties?
• Placement: Where should the rendered items appear on the Page?
• Interactions: Should each item include a link, button, input, toggle, or other action?

You can create and style the design before its data retrieval or rendering workflow is complete. However, plan the dynamic values early so the design and the data structure can use consistent field names.

Add a Data Design

To create a Data Design:

1. Open the Page in the Page Editor.
2. Open the Element Library.
3. Find Data Design in the Dynamic Content area.
4. Add Data Design at the intended location in the Page's editable structure.
5. Select the new Data Design and add the Page Elements that will form one repeated item.
6. Configure the content and appearance of those elements using Element Settings.
7. Save the Page as you work.

The Data Design can contain supported Page Elements, including text, images, buttons, links, cards, containers, inputs, toggles, and collapsible areas.

As with other Page content, the available child elements and settings depend on the selected element and its supported nesting structure. Select the intended parent element before inserting content.

For details about adding and organizing elements, see Element Library and Editing Page Content.

Design One Item

Start by designing a single representative item with realistic example content. Do not manually create separate copies for every record you eventually want to display.

Example: Product Card

A product card might contain:

• A product image.
• A product name.
• A price.
• A short description.
• An availability badge.
• A View Details link or button.

An illustrative element hierarchy is:

Data Design (Product Card Design)
  Card
    Image (Product Photo)
    Card Body
      Heading (Product Name)
      Text (Product Description)
      Text (Product Price)
      Badge (Availability)
    Card Footer
      Link Button (View Details)

The Card provides the visual grouping. The individual elements provide the content and actions. During rendering, supported dynamic properties can receive different values for each product.

For example, the same design could display a backpack, a jacket, and a water bottle without manually building three separate cards.

Example: Member Profile

A member profile might use a different arrangement:

Data Design (Member Profile Design)
  Container
    Row
      Column
        Image (Profile Photo)
      Column
        Heading (Member Name)
        Text (Membership Level)
        Text (Location)
        Link (View Profile)

Choose the Page Elements and layout according to the information users need to understand. A card is useful for a visually grouped item, but a Data Design does not have to use a Card.

For element-specific configuration, see Layout Elements, Text and Content, and Tables and Cards.

Separate Static Content from Dynamic Content

Not everything inside a Data Design needs to change.

For example, a product card may always display the label Price, while the actual price varies between products. The label can remain ordinary text, and only the value needs a placeholder.

Content	Typical approach
Price label	Keep as static content.
Product name	Configure a dynamic placeholder.
Product price	Configure a dynamic placeholder.
Product image	Configure a supported image-source placeholder.
Availability status	Configure a dynamic placeholder if it changes by product.
View Details label	Keep as static content.
View Details destination	Configure a supported link-destination placeholder when the destination varies by product.

Keeping shared labels and styling static makes the design easier to maintain. Use dynamic values only where the rendered item needs record-specific information.

Name Elements You Will Use Later

Give important elements meaningful names, especially when they will be selected during editing, referenced by Page Flow, or involved in item-specific interactions.

Examples include:

Element	Example Name
Data Design	ProductCardDesign
Image	ProductImage
Heading	ProductNameHeading
Price text	PriceText
Badge	StatusBadge
Details button	DetailsButton
Favorite toggle	FavoriteToggle
Results container outside the Data Design	ProductResults

Prefer names based on purpose rather than placement. ProductNameHeading is more useful than TopText, and DetailsButton is more useful than BlueButton.

Element Name vs. Placeholder Field Name

An element's Name and a placeholder's Field Name serve different purposes.

• Name identifies the Page Element for editing and related configuration.
• Field Name identifies the value supplied to that element when the Data Design is rendered.

For example, a Heading could be named ProductNameHeading in the editor while its dynamic Field Name is ProductName.

These names do not have to be identical. The placeholder Field Name must match the data prepared for rendering, while the element Name should make the element easy to recognize and maintain.

Do not assume either value is interchangeable with an HTML element ID, a CSS class, or an identifier assigned to a rendered item.

For more information, see Element Settings and Placeholders.

Configure Dynamic Content Placeholders

A placeholder marks a supported element value that will be supplied when the Data Design is rendered.

For each part of the design that should change:

1. Select the relevant child element inside the Data Design.
2. Open Element Settings.
3. Find the supported Dynamic Content option, where available for that element.
4. Enable Dynamic Content and provide a meaningful Field Name.
5. Repeat for the other values that will change per item.

For a product card, the configuration might use:

Visual part	Example Field Name	Value supplied during rendering
Product name	ProductName	The product's name.
Description	ProductDescription	A short description.
Price	ProductPrice	A display-ready price.
Product photo	ProductImage	The supported image source or URL.
Availability	Availability	The product's status.
Details link	DetailsUrl	The product-specific destination.

Not every Page Element or property supports dynamic values in the same way. Use the controls available for the selected element rather than assuming every property can be populated through a placeholder.

For example, a rendered item could be supplied with values shaped like:

{
  "ProductName": "Trail Backpack",
  "ProductDescription": "Lightweight daypack for everyday use.",
  "ProductPrice": "$89.00",
  "ProductImage": "/media/backpack.jpg",
  "Availability": "In stock",
  "DetailsUrl": "/products/trail-backpack"
}

This is an illustration of the values a design could expect, not Page Flow API syntax. The exact data retrieval and rendering configuration are handled separately.

See Placeholders for detailed placeholder configuration and field-name matching.

Plan the Rendering Target

Rendered Data Design content needs a target area on the Page. This is separate from the Data Design that defines the reusable item.

For example:

Page
  Data Design (ProductCardDesign)
    Card
      Image
      Heading
      Text
      Link Button

  Container (ProductResults)
    [Rendered product cards appear here]

The Data Design defines what each item looks like. The target area defines where the generated items appear and helps control their arrangement.

Common target areas include:

Target Area	Typical use
Section	Full-width list or results area.
Column	Results within part of a larger Page layout.
Container	Grouped cards, tiles, or custom rows.
Card Group	Repeated card-style presentation.

Give the target area a recognizable Name if Page Flow will reference it. Configure its width, spacing, alignment, and overflow as appropriate for the intended results.

Adding a Data Design does not automatically populate the target. Page Flow or another supported rendering mechanism must supply the data and place the generated content there.

For details about rendering one or many items, target selection, and replacing or appending results, see Rendering Data Design.

Plan Interactions Within Each Item

A Data Design can contain more than text and images. Supported child elements can also include links, buttons, inputs, toggles, and collapsible areas.

Examples include:

• A View Details link that opens the appropriate product page.
• A Favorite toggle associated with a particular item.
• A button that starts an action for a selected record.
• A collapsible area that shows additional item information.

Creating the visual control does not automatically configure its application behavior. When interactions require Page Flow, design the control first and then configure the corresponding workflow.

The rendering process can use an ID and optional ID2 to distinguish rendered instances. Consider which record identifiers will be available if later interactions need to act on a particular product, member, or other item. The specific identifier and rendering behavior belong to the rendering workflow rather than to the visual design alone.

For interactive content:

1. Name controls clearly.
2. Decide what record-specific information each action needs.
3. Configure supported links, actions, and Page Flow behavior.
4. Test the interaction on more than one rendered item.

Do not assume that a button or toggle in one rendered item automatically identifies the correct record without the appropriate runtime configuration.

See Rendering Data Design and Page Flow for the related implementation concepts.

Design for Repetition and Responsive Layouts

A Data Design might be rendered once or dozens of times on the same Page. Design one item so that it remains readable and usable at different content lengths and screen sizes.

Item Layout

• Use a consistent structure for the same kind of record.
• Choose image dimensions and cropping that work for different source images.
• Allow enough space for long names, descriptions, and prices.
• Avoid fixed sizing that unnecessarily clips important content.
• Keep primary actions easy to identify and operate.
• Consider how missing or empty values should appear.

Repeated Layout

• Use the target area's layout to determine how items are grouped or arranged.
• Preview the result with one item, several items, and many items.
• Check how spacing behaves between repeated instances.
• Avoid designs that require an unusually wide screen to remain usable.
• Make sure buttons, toggles, and links remain practical to use on mobile.

A product catalog may use several cards per row on a wide screen and a narrower arrangement on mobile. The exact layout depends on the target area and its responsive configuration; it is not determined by the Data Design's visual content alone.

For responsive styling, see Element Settings and Layout Elements.

Example: Preparing a Product Catalog

Consider a Project that needs to show products as cards rather than as rows in a standard table.

A practical creation workflow is:

1. Create the item design. Add a Data Design named ProductCardDesign.
2. Build its structure. Add a Card with an Image, Heading, description, price, status, and View Details action.
3. Use sample content. Start with a realistic product so the card's spacing and proportions can be evaluated.
4. Configure placeholders. Assign Field Names such as ProductName, ProductPrice, ProductImage, and DetailsUrl to the supported dynamic properties.
5. Name important elements. Use meaningful element Names for controls and content involved in later editing or interactions.
6. Create a target area. Add a suitable Container or other supported layout element named ProductResults outside the Data Design.
7. Prepare the rendering workflow. Configure Page Flow or another supported mechanism to obtain product data, supply placeholder values, and render the items into ProductResults.
8. Preview the Page. Test multiple products, missing values, long descriptions, mobile layouts, and item-specific actions.

The finished Page can use one Data Design to present many products with a consistent visual structure.

This section establishes the design and its dependencies. The exact workflow for supplying records and placing rendered instances is covered in Rendering Data Design.

Testing and Previewing

Preview the Data Design through a Page that has the required rendering behavior configured. Inspect both the individual item and the arrangement of repeated items.

Test	What to check
One item	The item is complete and positioned correctly.
Multiple items	Spacing and alignment remain consistent.
No matching items	The Page provides an appropriate empty state instead of an unexplained blank area.
Long text	Headings, descriptions, and action controls remain usable.
Missing image	The layout handles the missing value appropriately.
Missing or empty fields	The design does not show confusing placeholder content.
Different screen sizes	Items fit and remain readable on desktop, tablet, and mobile.
Record-specific actions	Each action behaves correctly for the intended rendered item.

The Page Editor lets you inspect and modify the source design, but it is the rendered result that determines what application users experience.

Save your Page changes and test through Preview. Saving does not, by itself, publish those changes to the live application.

For more information, see Previewing.

Data Access and Security

Data Design is a frontend presentation mechanism. Its placeholders and visual controls do not establish who is authorized to read or change Project data.

When a design displays protected information or offers record-changing actions:

• Retrieve data through supported interfaces with the appropriate access rules.
• Enforce permissions through Project Database access controls and trusted Backend logic where required.
• Use Page Flow to coordinate browser-side behavior, not as the sole enforcement point for sensitive authorization.
• Do not rely on hidden elements, missing buttons, or filtered visual results to protect records.

For trusted server-side processing, see Cloud Flow.

Good Practices

• Design one item first. Build and refine one representative layout before rendering multiple records.
• Keep one design focused. Use a Data Design for one recognizable item type rather than unrelated content structures.
• Separate static and dynamic values. Only configure placeholders for properties that should change per item.
• Use meaningful names. Distinguish element Names from placeholder Field Names and keep both maintainable.
• Plan the target area. Create and name the location where rendered content should appear.
• Keep interactions record-aware. Test buttons, links, inputs, and toggles against the appropriate rendered item.
• Design for variable content. Check long text, missing images, empty values, and different record counts.
• Preview responsively. Test desktop, tablet, and mobile layouts.
• Choose the appropriate display tool. Use the Data Table Widget when a standard record table is more suitable than a repeated custom layout.

Common Mistakes

Avoid these patterns:

• Designing the entire list inside the Data Design. A Data Design should generally represent one item, while rendering creates the repeated instances.
• Manually duplicating every item. This defeats the purpose of a reusable data-driven design.
• Confusing element Names and Field Names. An editor label does not automatically bind an element to a data value.
• Mismatched placeholder names. Field Names that do not match the supplied data leave values unpopulated or incorrect.
• Forgetting the rendering target. Adding the reusable design does not automatically create visible repeated results.
• Treating visual controls as complete workflows. A button or toggle may still require Page Flow and record-specific context.
• Ignoring content variation. A layout that works for one short title may fail with longer or missing values.
• Overlooking parent layout behavior. The target area's sizing and arrangement affect all rendered instances.
• Assuming a hidden control enforces security. Authorization must be enforced through the appropriate Project capabilities.
• Testing only the source design. Preview the actual rendered content and its interactions before publishing.

Data Design works best when the reusable item is simple to understand, its dynamic values are clearly defined, and the rendering workflow can populate it consistently for each record.

Related Topics

• Data Design
• Placeholders
• Rendering Data Design
• Element Library
• Element Settings
• Layout Elements
• Tables and Cards
• Data Table Widget
• Page Flow
• Previewing