Placeholders

Placeholders identify the values within a Data Design that should be supplied from data when the design is rendered.

Use placeholders when repeated items share the same visual structure but need different names, descriptions, prices, images, statuses, or destinations. For example, a product-card Data Design can use the same layout for every product while displaying a different image, name, price, and View Details link in each rendered card.

A placeholder connects a supported element property to a Field Name in the data prepared for rendering. It does not retrieve records or render the design by itself. Those responsibilities belong to Page Flow or another supported rendering workflow.

For the overall Data Design process, see Data Design and Creating Data Design.

Understanding Placeholders

A Data Design typically contains a combination of static and dynamic content.

• Static content stays the same for every rendered item, such as a Price label or a View Details button label.
• Dynamic content receives an item-specific value, such as a product name, price, photo, or details URL.

For example:

Data Design (ProductCardDesign)
  Card
    Image              → ProductImage
    Card Body
      Heading          → ProductName
      Text             → ProductDescription
      Text             → ProductPrice
      Badge            → Availability
    Card Footer
      Link Button
        Label          → "View Details" (static)
        Destination    → DetailsUrl

The names after the arrows are example placeholder Field Names, not element names or Page Flow commands.

When the design is rendered for different products, supported dynamic properties receive the corresponding values for each product. The static labels and visual structure remain consistent.

Placeholder Types

Data Design supports two common placeholder patterns:

Placeholder Type	Purpose	Examples
Visible Content	Populates text and other supported content displayed to users.	Product name, description, formatted price, membership level, status text.
Element Values	Populates a supported property of an element rather than its visible wording.	Image source, profile photo location, link destination.

Most Data Designs use both patterns. A product card may have visible content placeholders for the name and price, an image-source placeholder for the photo, and a link-destination placeholder for the details action.

Not every Page Element or property supports Dynamic Content. The available controls depend on the selected element and its editing context. Configure only the dynamic properties exposed for that element.

Configuring a Placeholder

When a supported element is inside a Data Design, its Element Settings can expose a Dynamic Content option and an associated Field Name.

To configure a placeholder:

1. Open the Page containing the Data Design in the Page Editor.
2. Select the child element whose content or supported property should change for each item.
3. Open Element Settings from the Selected Element Toolbar.
4. Find Dynamic Content, where available for the selected element.
5. Enable Dynamic Content and enter the appropriate Field Name.
6. Repeat for the other dynamic values in the design.
7. Save the Page, then test the placeholders through a configured rendering workflow.

For example, a Heading displaying the product name might be configured with:

Setting	Example
Element Name	ProductNameHeading
Dynamic Content	Enabled
Field Name	ProductName

When the rendering data includes a value for ProductName, that value is used to populate the supported dynamic content of the Heading.

For element-specific controls, see Element Settings.

Element Name vs. Field Name

An element's Name and a placeholder's Field Name are different properties.

Property	What It Identifies	Example
Name	The Page Element within the editor and related configuration.	ProductNameHeading
Field Name	The value expected from the data supplied during rendering.	ProductName

The two names do not need to match.

For example, you might name a Text element CardPriceText for easier maintenance and assign it the placeholder Field Name ProductPrice because that is the key in the data.

Do not assume that either name is the element's HTML ID, a CSS class, or the identifier of the underlying Project Database record. These have different purposes.

Visible Content Placeholders

Use visible content placeholders for supported elements that display record-specific wording or values.

Examples include:

Field Name	Example Value	Typical Use
ProductName	Trail Backpack	Product heading.
ProductDescription	Lightweight daypack for everyday use.	Product description.
ProductPrice	$89.00	Displayed price.
MemberName	Asha Patel	Profile heading.
MembershipLevel	Gold	Membership summary.
StatusText	Approved	Visible status wording.

The content entered in the Page Editor can help you design and inspect the layout before rendering. Once the dynamic property is populated, the supplied value takes the place of the design-time content for that property.

Design-time text should not be assumed to be an automatic fallback. If a supplied value may be missing or empty, plan the desired fallback in the data preparation or supported rendering workflow and verify the result in Preview.

Static Labels Alongside Dynamic Values

A repeated item often combines a fixed label with a variable value.

For example:

Price: $89.00

One approach is to keep Price: as static text and configure a separate element for the dynamic ProductPrice value. This makes it clear which part is populated by data.

For a compact presentation, a workflow may instead prepare a single display-ready value, such as Price: $89.00, for a supported text placeholder. Choose the approach that best fits the design and how the value will be maintained.

Image Placeholders

Use an image placeholder when the displayed image should vary between rendered items.

Typical uses include:

• Product photographs.
• Member or team profile images.
• Event images.
• Category thumbnails.
• Record-specific illustrations.

Examples:

Field Name	Example Value	Purpose
ProductImage	/media/backpack.jpg	Image for one product.
ProfilePhoto	/media/member-102.jpg	Image for one member.
EventImage	https://assets.example.com/events/autumn.png	Image for one event.

The supplied value must be an image location or URL supported by the receiving element and the Project's media configuration. The examples above illustrate possible values; use the actual media paths or locations available in your Project.

Preparing Image Values

When using dynamic images:

1. Configure the supported image property as dynamic in the Data Design.
2. Assign a Field Name such as ProductImage.
3. Prepare the corresponding image location for each record.
4. Consider what the Page should display if a record has no image.
5. Preview different source images to confirm their sizes and proportions work in the layout.

Image data does not automatically determine the visual dimensions of the Image element. Use the element's supported sizing and layout settings to control the presentation.

For Image configuration, see Media Elements.

Link Destination Placeholders

Use a link placeholder when each rendered item needs to navigate to a different destination.

For example, a product catalog may render the same View Details control on every card, but each control should open the corresponding product page.

Field Name	Example Value	Purpose
DetailsUrl	/products/trail-backpack	Product-specific details Page.
ProfileUrl	/members/member-102	Member-specific profile Page.
DownloadUrl	/files/product-guide.pdf	Record-specific resource.
ExternalUrl	https://example.com/resource	External destination.

Use the supported dynamic destination property on the selected Link or link-capable element. Keep the visible label static if it should remain the same for every item.

Dynamic Links vs. Custom Actions

A dynamic destination tells a supported link where to navigate. It does not automatically create a custom application workflow.

For example:

• Open Product Details: A record-specific link destination may be sufficient.
• Add to Cart: May require Page Flow and record-specific data.
• Toggle Favorite: May require an item-specific interaction and a permitted data operation.
• Delete Record: Requires appropriate authorization and a deliberate application workflow; a destination placeholder is not a substitute.

When an action depends on the selected rendered instance, coordinate the supported control with Page Flow and the appropriate record context. Rendering can use ID and optional ID2 values to distinguish instances; those identifiers have a different purpose from placeholder Field Names.

For more information, see Rendering Data Design and Page Flow.

Matching Field Names to Rendering Data

The Field Name is the connection between the design and the values prepared by the rendering workflow.

For example, a product-card Data Design might expect:

Placeholder Field Name	Supplied Value
ProductName	Product title.
ProductDescription	Short description.
ProductPrice	Formatted price.
ProductImage	Supported image location.
Availability	Availability text.
DetailsUrl	Product-specific destination.

The data for one product could be 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 JSON is an illustrative data object, not a Page Flow block definition or an ioLoop rendering API call.

If Page Flow obtains records using different field names, prepare the values to match the placeholder names before rendering.

For example, data retrieved with fields such as name, price, and image_url may need to be prepared as:

Source Field	Placeholder Field Name	Example Prepared Value
name	ProductName	Trail Backpack
price	ProductPrice	$89.00
image_url	ProductImage	/media/backpack.jpg

Do not assume that ioLoop automatically maps a Database field to a differently named placeholder. Keep the expected Field Names and the supplied data aligned, including their spelling and capitalization.

One Design, Different Records

The same placeholder configuration can be reused for multiple records.

For example, a second product could supply:

{
  "ProductName": "Rain Jacket",
  "ProductDescription": "Lightweight shell for changing weather.",
  "ProductPrice": "$129.00",
  "ProductImage": "/media/rain-jacket.jpg",
  "Availability": "Limited stock",
  "DetailsUrl": "/products/rain-jacket"
}

Both products use the same Data Design. Only their supplied values differ.

If two supported elements need to display the same information, they can be configured to expect the same Field Name where appropriate. Use different Field Names when the elements require different values.

Preparing Values for Display

The values retrieved from Project data are not always in the format users should see.

Examples include:

Source Value	Display Consideration	Example Prepared Value
Numeric amount	Currency formatting.	$89.00
Stored status code	User-friendly wording.	Approved
Date/time value	Appropriate date display.	Oct 12, 2026
Media reference	Supported image source.	/media/backpack.jpg
Record identifier	Link to the appropriate Page.	/products/trail-backpack

Prepare data in the appropriate Project workflow when formatting or transformation is needed. A placeholder receives a value; do not assume it automatically formats currencies, translates status codes, creates URLs, or resolves record identifiers.

The precise Page Flow operations used to prepare values depend on the application's data and rendering workflow.

Missing, Empty, and Invalid Values

Repeated content must work even when the source data is incomplete.

For example, a product might have a name and price but no description or image. Another might have a long name or a missing details destination.

Plan the expected behavior for each field:

Situation	Recommended Approach
Missing product description	Prepare an appropriate empty value or concise fallback text.
Missing image	Supply a valid fallback image where appropriate, or design the layout to handle its absence.
Missing price	Use meaningful wording such as Price unavailable if suitable for the application.
Missing details URL	Avoid presenting an apparently functional link with no valid destination.
Long name or description	Verify wrapping, sizing, and spacing in the rendered layout.
Missing status	Prepare an understandable default or omit the status presentation through supported behavior.

These are application design recommendations, not claims that ioLoop automatically applies a particular fallback.

Test the result of missing, empty, and unexpected values in Preview. Do not rely solely on how the original design appears before rendering.

Placeholder Names and Maintainability

Choose Field Names that describe the information rather than the visual position of the element.

Good examples:

• ProductName
• ProductImage
• StatusText
• ProfileUrl
• TotalAmount
• MembershipLevel

Avoid names such as:

• Text1
• TopImage
• LeftValue
• BlueButton

Visual positions and styling may change. Data meaning is generally more stable.

When changing a Field Name, also review the Page Flow logic or other rendering configuration that supplies the corresponding value. A design change and a data mapping change often need to be made together.

Placeholders, Rendering, and Data Access

A placeholder identifies what value to display or use in a supported element property. It does not decide:

• Which records to retrieve.
• Whether a Project User is authorized to see a record.
• How a data operation is executed.
• When rendered items are created, refreshed, or removed.
• Which rendered record a custom action is permitted to modify.

These responsibilities belong to the applicable Page Flow, Project Database access configuration, and trusted Backend operations.

For protected data:

• Retrieve only values the current user is permitted to access.
• Apply the appropriate Database permissions or trusted authorization checks.
• Treat values and destinations received from external sources as untrusted until validated through the appropriate workflow.
• Do not treat hidden or unpopulated placeholders as an access-control mechanism.

Page Flow coordinates browser-side behavior. Sensitive authorization and protected processing should use the relevant Backend capabilities, such as Cloud Flow, where required.

Testing Placeholders

Once the rendering workflow is configured, Preview the Page with representative data.

Test	What to Check
Normal values	Expected text, images, and destinations appear in the correct elements.
Different records	Each rendered instance receives its own values.
Missing field	The application shows the intended fallback or handles the absence appropriately.
Empty value	No confusing blank labels, broken images, or misleading controls appear.
Long content	Text remains readable at different screen sizes.
Image values	Media loads correctly and fits its designated space.
Link values	Links open the correct record-specific destination.
Repeated rendering	Updating or refreshing a results area does not mix values between items.
Interactive elements	Page Flow actions use the intended rendered record context.

Save changes before previewing. Saving the Page does not automatically publish its changes to the live application.

For the complete runtime sequence, see Rendering Data Design.

Troubleshooting Placeholders

Symptom	What to Check
A value does not appear	Confirm Dynamic Content is enabled for the relevant supported property and that its Field Name is supplied.
The wrong value appears	Compare the Field Name with the keys or prepared values for the current record.
A design-time value remains visible	Verify that the rendering workflow is supplying and applying the intended dynamic value.
An image is broken	Check the source location, availability, and supported image format or URL.
A link opens the wrong Page	Check the prepared destination for that record and the element's link configuration.
Different items show the same data	Review how values are supplied for each rendered instance, not only the placeholder configuration.
An action affects the wrong item	Review the rendered item's record identifiers and Page Flow context.

Good Practices

• Use placeholders only for changing values. Keep fixed labels, common button text, and shared styling static where appropriate.
• Choose meaningful Field Names. Name fields by their data meaning rather than their visual position.
• Keep names aligned with data. Prepare rendering values that match each expected Field Name.
• Distinguish Names from Field Names. Use element Names for editing and Field Names for dynamic population.
• Prepare display-ready content. Format text, prices, status labels, and destinations in the relevant workflow where needed.
• Plan for missing data. Test empty fields, absent images, and invalid destinations.
• Keep interactions explicit. Configure Page Flow and record context for actions that go beyond link navigation.
• Test multiple records. Check that each rendered item receives the correct values.
• Enforce data permissions separately. Presentation settings do not replace Database access rules or trusted authorization.

Common Mistakes

Avoid these patterns:

• Assuming an element becomes dynamic merely because it is inside a Data Design.
• Using the element's Name as though it automatically matched a data field.
• Setting a Field Name that differs from the data supplied at rendering time.
• Assuming every Page Element property supports Dynamic Content.
• Making a shared label dynamic when only the adjacent value needs to change.
• Assuming design-time text or images are guaranteed fallbacks for missing data.
• Supplying raw values and expecting placeholders to format them automatically.
• Giving every rendered card the same hard-coded link destination.
• Treating a dynamic link destination as equivalent to a custom record action.
• Testing only the source design rather than the rendered result with real values.
• Using missing or hidden content to enforce access restrictions.

Placeholders are most effective when their Field Names, supplied data, and intended element properties stay aligned. That separation allows one Data Design to display many records consistently without manually rebuilding each item.

Related Topics

• Data Design
• Creating Data Design
• Rendering Data Design
• Element Settings
• Text and Content
• Media Elements
• Buttons and Actions
• Page Flow
• Cloud Flow