Use dynamic Elementor content to connect a layout to stored site or post data, and display conditions to control when an element appears. Identify the source field and expected value, then define the visibility rule separately. Test populated, empty and mismatched records to check both the data connection and the display decision.
A useful brief says more than “make this section dynamic”. It names the record being displayed, the field that supplies the value and the circumstances in which the section is useful. For a team directory, that might mean showing an agreed role description from a staff record and displaying an additional introduction only for a selected category.
The worked sheet below uses fictional directory entries. It draws product examples from Elementor’s own documentation, retrieved on 24 October 2026. Begin with the existing WordPress content structure; wider application decisions belong with web development.
Which record supplies the content?
Elementor dynamic content pulls values from the site or current post into a layout. The dynamic-content introduction describes this relationship. Write the expected value beside the source record before selecting a widget. That simple comparison gives the reviewer an independent reference when the editor preview looks plausible.
Elementor documents Dynamic Tags as an Elementor Pro feature. Record the installed edition and the particular widget input used in the demonstration. Availability of an editor control should be checked in the proposed environment rather than assumed from a screenshot of another site.
Custom fields store additional information about a post or custom post type. Decide whether the proposed value already exists in the content model or needs a new agreed field. Avoid creating several similarly named fields to solve a display problem before checking which one owns the information.
Elementor documents integrations with ACF, Toolset and Pods. These are examples of supported field sources, not instructions to install all three. Identify the source already used by the project and record the field key, purpose and content owner. A readable label helps an editor; the precise key helps the implementer trace a wrong value.
How do fields reach the intended layout?
Elementor lets users choose custom fields from Dynamic Content lists. Ask the implementer to show the source selection on the actual widget input. Then open a second fictional record with a different value. If both previews display the same text, investigate the selected record and field before changing the typography or adding another condition.
Elementor can apply Single Post and Archive templates to custom post types. Elementor requires a custom post type’s Has Archive setting for its Archive Templates. These documented configuration details matter when a directory listing and an individual entry need different presentations. Keep the intended listing route and individual route on the same brief, with their respective templates identified.
A directory card may use a short role description while the full entry provides a longer biography. Decide which fields belong in each context. Reusing a field is helpful when the meaning is the same; forcing a long biography into a compact card can make both editing and reading harder. This is a content-design decision to agree before configuring the template.
| Proposed test record | Field situation | Visibility rule | Expected review question |
|---|---|---|---|
| Sample Entry A | Role description populated | Selected category matches | Does the correct value appear? |
| Sample Entry B | Different role description | Selected category matches | Does the layout change with the record? |
| Sample Entry C | Role description empty | Category still matches | What useful empty state is intended? |
| Sample Entry D | Description populated | Category does not match | Is the additional section absent? |
| Sample Entry E | Several criteria partly match | Combined rule under test | Is the logic understood by the content owner? |
The sheet is an original acceptance proposal. Complete its observed-result column in a separate test copy once the intended fields and rules are configured.
What do AND and OR conditions mean?
Elementor AND conditions require all listed conditions to match. Elementor OR condition groups allow an element when either condition matches. The display-conditions guide documents both forms. Translate the intended rule into a sentence the content owner can check before constructing it in the editor.
For the fictional directory, the proposed extra introduction could appear for category Community, or for category Projects when the author is Sample Editor. These are two branches with different requirements. Write down which sample entries should satisfy each branch, including a record that satisfies only part of the second branch. That makes a mistaken grouping visible.
Elementor requires saving or publishing the page for display conditions to take effect. Include the saved state in the demonstration record, then inspect the ordinary page view. A rule still being edited and a saved rule serving the page are different stages of the work.
Original field-to-rule diagnostic worksheet
Prepare the fictional records before opening the template editor. For each, write the record identifier, expected field value, category and author used by the exercise. Keep the information invented and make the expected results clear enough that a colleague can assess them without knowing how the template was built.
First, connect the role-description field to a suitable widget and compare Entries A and B. Retain the selected field key and actual text shown for each. Next, inspect Entry C with the empty value. Agree whether the section should be hidden, present an alternative or invite an editor correction. Record that design requirement separately from the behaviour already demonstrated.
Then configure the proposed visibility rule and use Entry D to check the non-matching case. For the combined rule, work through every branch on paper before inspecting the saved page. If the editor and reviewer disagree, return to the written rule and identify the specific record that exposes the difference.
Finally, inspect the listing and individual-entry layouts using the same sample set. Check that the template and field choices match the intended context and that an ordinary content update reaches the appropriate page. Retain the configuration version and observations with the worksheet so the next editor can repeat the check after a template change.
The useful result is a clear chain from record to field to layout to visibility rule. It helps distinguish a data correction from a template correction and gives each issue an owner. To discuss the field model or the remaining conditions, get started with the sample sheet and the page contexts it must support.
Add one sample record whose field contains unexpected but harmless text. Inspect both the displayed value and the visibility decision, so the acceptance sheet distinguishes a data-entry problem from a condition configured against the wrong field.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.