Appmint Build Studio: Pages, Components, Data and Publishing

▶ Play video

Watch on YouTube ↗

1. Choose the site and find the page

Cedar & Form needs a Services page that shows current service records, explains the design process and introduces runtime actions and the current support-form limitation. You will build that page, then extend it with responsive layouts, interactive components, data binding, AI assistance and publication recovery. The same page stays at the centre of the course so that each new capability has a visible purpose.

Illustration, not an app screenshot. Select the site and page first; inside the page select a screen, then the element you want to edit. Save persists changes. Publish controls publication status, but a site configured to serve drafts can already display a saved draft.

Use a training organisation and an existing site you can edit. You need permission to save pages; publication may also require a reviewer. Prepare two non-sensitive service records with the fields name, summary, price, active and imageUrl: Room Consultation, “A focused session for one room”, 150, true; and Whole Home Planning, “A coordinated plan across rooms”, 600, true. Use images you own. The Database course explains how to create a custom collection if you do not already have one. Record its actual datatype identifier rather than assuming that its display name is the API identifier.

Expand Build Studio in the left navigation. Dashboard is the visual starting point. In Recently edited, distinguish the eye preview control from the pencil edit control: preview opens the site view; edit opens the authoring canvas. Saved Pages provides the saved page records. New Web Page starts a new design. Templates offers a separate library of starting designs.

Current local dashboard. The practice site here is formdemo; choose your own site. The eye beside the saved page opens preview, and the pencil opens editing. Not published records publication status, not a promise that the draft is private.

Before creating anything, read the site name in the top toolbar. Open the site selector, search for your Cedar & Form training site and select it. The page selector is a different control: it switches pages within your current working context. A page with the correct title in the wrong site is still the wrong result.

When returning to an existing design, use the page's edit control and read its name before typing. Closing an editor tab and deleting a page are separate actions; a close control is how you leave a working page. If the canvas opens blank when you expected saved content, return to the page library and open the intended record instead of saving the blank canvas over it.

2. Create a blank page or adapt a template

For the main example, choose New Web Page with the training site active. Build a small page with a heading, introduction, service area and contact area. The first heading is Services for a home that works for you. The introduction is Explore a single-room consultation or a coordinated plan for your home. These are example contents, not generated business claims.

To establish a reproducible blank-page starting point, open HTML, click inside the code editor, select all existing code and delete it before pasting the following scaffold. Confirm that the editor is empty before you paste: inserting at the caret instead of replacing the document can leave duplicate content. Use Apply this HTML to the page you’re editing in the HTML panel. The Page applied to canvas notice identifies that local apply step. Keep the top toolbar Save for the next paragraph.

<!doctype html>
<html lang="en">
<head><meta charset="utf-8"><title>Cedar &amp; Form Services</title></head>
<body>
  <nav><a href="#services">Services</a> <a href="#contact">Contact</a></nav>
  <main>
    <h1>Services for a home that works for you</h1>
    <p>Explore a single-room consultation or a coordinated plan for your home.</p>
    <section id="services">
      <article class="service-card">
        <h2>Room Consultation</h2>
        <p>A focused session for one room</p>
        <span class="service-price">150</span>
      </article>
    </section>
    <section id="contact"><h2>Ask about your project</h2></section>
  </main>
</body>
</html>

The scaffold deliberately contains no photograph. Add a real image with its source and alternative text in the media chapter. This is editable content, not an image of a page. Reduce the HTML panel with Small height or close it with the panel’s ×, then select the heading on the canvas. You will change its content visually and extend its structure in the following chapters.

Save early with the top toolbar's Save. On the new page's information form, set Site to your training site, Name to cedar-services, Slug to cedar-services, and Title to Services — Cedar & Form. Complete the form's Save action and wait for the saved page name to replace the generated name. Keeping Name and Slug alike makes this first exercise easy to trace; Title can be readable without becoming the URL segment. The recorded example uses course-services-20261002 so it does not replace an existing page. Use your own unused name.

Verified save result: the starter content remains after a browser reload. It is intentionally unstyled at this stage; styling comes next. “Not published” describes publication status, not a guarantee of private access.

The template alternative starts at Build Studio → Templates. Choose Services, or All if there are no service templates. The library also separates Home, Store, Listing, Blog, Form, Landing and About. Inspect the template preview before invoking its create-page action. The result should be a new page you own, with its own identity, not an instruction to modify the library template. Select the intended site and replace inherited business names, links, images and form destinations before saving.

A category refresh reloads that category. It does not create a missing template. If no suitable result appears, use the blank-page route. If creation returns an error, return to the page library before retrying: check whether a page was created despite the response so you do not accumulate duplicate examples.

Read the creation notice as well as the page name. A site can serve drafts. A newly saved page therefore is not automatically private. Use your training site for unfinished work, and inspect its publication policy before placing sensitive content on a page.

3. Edit content and control the element hierarchy

The canvas is a view of nested elements. A service card contains a heading, a paragraph, an image and a link. Selecting the heading changes the heading; selecting the card's parent changes the group. Read the selected tag and its outline before applying a style or deletion.

Select the main heading, then open Property Panel from the right toolbar. In Props Editor → Content, replace Edit Text with Design support for every room, click the panel’s Save, then use the top toolbar’s Save to persist the page. This precise path was verified on the current editor. In-place text editing is an alternative; finish editing before dragging.

The field edits only the selected heading. Keep H1 selected for this page’s primary heading. The captured field shows the starting words; replace them with the words above. Finish text editing before dragging. While the caret is active, selecting words should edit text rather than reposition the heading. Click the card background or select its parent in the element tree when you want to move the complete card.

Select the starter's Room Consultation article in the tree. Its heading and paragraph must both be children of that article. To insert a copy at a particular position, use Copy element, select the target container and choose Paste → Paste as last child. The same menu offers Paste as first child, Paste before, Paste after and Replace. These are relative to the selected target. Use Replace only when you intend to remove that target. If Paste reports that there is nothing to paste, copy an element first. Inspect the tree after the insertion instead of correcting a wrongly placed child with large margins.

For the main two-card result, select the original article and use Clone element to duplicate it for Whole Home Planning, then replace the copied text. Remove any extra copy made during the Paste exercise so there are exactly two cards. Duplication is useful for maintaining the same visual structure; it also copies attributes and actions. Change any copied HTML id so each target remains unique. Otherwise a button that opens a dialog by ID may open the wrong copy.

For a coordinated edit, use the editor's multiple-selection controls and confirm which elements are selected. Open Text Alignment and choose Align Left, Align Center or Align Right for the selected text. The multi-selection toolbar also provides sibling text alignment. Text alignment centres words inside their boxes; it does not rearrange unrelated boxes into a grid. To move several related elements as one unit, open Container Tools → Put in Container. This wraps the selection. Remove Container performs the reverse operation by moving its children into the parent. Inspect the resulting hierarchy after grouping, because a new wrapper can alter layout.

An accidental deletion is easiest to recover immediately with Undo. After recovery, inspect the parent and its children, not just the visible heading. The meaningful saved result is a service area containing two complete cards with distinct text, preserved links and predictable parent containers.

After a page save, selection may clear. If Props Editor says Select Something, select the heading or container again before opening Style or Runtime. This happened during the recorded walkthrough; it is not a missing property panel.

4. Set layout, typography, media and reusable styles

Select the service-area container and open the element property panel. Style changes the selected element's visual settings. Class edits its classes; Attributes edits attributes such as id, href, src and alt. Preset provides the selected element's available treatments. Keep the selected tag visible while working so a style intended for the whole section does not land only on a paragraph.

Open the paintbrush Style control in Props Editor. These controls belong to the currently selected element; select the service section before changing grid or container spacing. This capture establishes the controls, not the finished page styling.

Give the section a readable content width, space around its contents and a consistent gap between cards. Use a two-column arrangement on wide screens and one column on narrow screens. Prefer layout rules over individually positioning each child: when the service summary grows, the container should accommodate it rather than overlap the next card.

Use a restrained example palette: dark green #244B3A for headings, cream #F5F2EA for the page and charcoal #202522 for body text. Change the heading font size on the heading, then the paragraph size on its paragraph. Use the same named class, such as service-card, on both cards when they need shared styling. A class is a shared styling hook; merely duplicating a card creates a copy and does not establish a centrally updated component.

At page level, use the theme settings to choose a theme or adjust the inherited site theme. A page theme can affect more elements than a local style. Make one change, inspect the heading, body copy and button, and then decide whether a local override is still needed. Avoid compensating for an unwanted theme choice with many separate overrides.

Select a card image and set its real media source. Add an alt value that describes the relevant room, for example Living room with a reading corner and oak shelving. Preserve the image's proportions; crop intentionally instead of stretching it. Set the contact link to the intended contact section or a real destination you control, then test the link in preview.

When using a reusable preset or component, insert another instance and inspect what is inherited: layout, text, IDs, links and runtime configuration. Change the second instance's content and save. Treat global-update behaviour as a distinct capability to establish, rather than assuming that every inserted or copied block stays connected to its source.

Finish the first-page design: a reproducible checkpoint

The plain starter is useful for learning selection, but your first saved page should have a coherent design. This checkpoint supplies the complete example used in the live walkthrough: a heading, two service cards with example prices, navigation and a contact area. It uses typography and CSS rather than borrowed photographs. The contact buttons currently navigate to the contact area; they do not submit an enquiry or take a payment. You will add that behaviour in the runtime-action chapter.

Use this checkpoint on the practice page before adding your own data bindings or form actions. Replacing the document replaces its content; do not use it to overwrite an existing customer website or a later completed exercise.

1. Open the complete styled-page source. Select and copy the entire document, from <!doctype html> through </html>.
2. Return to your named practice page in Build Studio. Open HTML and expand the panel with Large height. Click inside the editor, select all, delete, and then paste the complete source. Confirm that you have one document, not a second document appended to the first.
3. Click Apply this HTML to the page you’re editing. Wait until Choose your starting point and both service cards are visibly present on the canvas. Do not immediately click toolbar Save while the old canvas is still showing: in the live test, that saved the earlier content. Apply and Save are separate stages.
4. Use the top toolbar Save once the new canvas is visible. Wait for the save to finish. Reload the page, confirm the same page name, and check that both cards and the large heading remain.
5. Close or minimize the HTML panel. If the Build Studio AI input covers the page, use its Hide (Esc) control. This changes the editor view; it does not delete your page content.

Verified result: the same page now has a large green heading, readable introduction and two equal-width cards. The screenshot is the actual editor canvas after save and reload, not a generated mockup. The editor can show its own canvas background; inspect external preview separately before promising an identical public rendering.

The design decisions are small and reusable. .service-grid uses display:grid, two minmax(0,1fr) columns and a 24px gap. Each .service-card has 32px padding, a border and a 20px radius. .hero h1 sets the headline size; using a scoped selector avoids the generic heading reset that kept the first test heading at body-text size. Below 680px, the grid changes to one column and the card padding reduces to 26px.

You can continue editing this imported page visually: select a heading, open Content, change its words and Save. The HTML is real editable structure. Importing it does not flatten the design into an image.

5. Add navigation and interactive page components

A visitor needs to reach a service, inspect details and return to the main page without losing context. Start with navigation linking to the service section and the contact area. Select the navigation element, inspect its source and title options, and use the navigation data available in your site. If using ordinary links, set each link's href in Attributes. A visible label without a destination is only text.

For a precise HTML insertion route, open HTML, Revert and add a component inside main, after the service region. Apply to canvas, select the new custom element in the tree and use its element settings. This short tab example shows the required slots; label and content positions match by index:

<wm-tabs default-active="0">
  <button slot="label">Room consultation</button>
  <button slot="label">Whole-home planning</button>
  <div slot="content">A focused session for one room.</div>
  <div slot="content">A coordinated plan across rooms.</div>
</wm-tabs>
<wm-accordion>
  <wm-accordion-item>
    <button slot="header">What happens next?</button>
    <div slot="content">Send your question through the contact form below.</div>
  </wm-accordion-item>
</wm-accordion>

Use the same insertion route for the other training components. A slider contains child divs with slot="slide"; a dialog or drawer contains a button with slot="trigger" and a content div with slot="content". Give the dialog id="consultation-details". A mega menu pairs slot="trigger" buttons with slot="panel" divs in the same order. Navigation links inside wm-navigation use slot="nav-item". Insert real labels and content before testing, because an empty custom element does not demonstrate an interaction.

For a grid-layout exercise, wrap the two service articles in <wm-grid columns="1" columns-md="2" gap="24">, set each article to slot="item", then apply and select the grid element and set Columns (Default) to 1, Columns (MD - 768px+) to 2 and Gap (px) to 24. The grid schema also exposes wider breakpoints, search, filters, sort options and an empty message. Set the empty message to No services are available right now. Search and sorting must operate on the displayed records; changing the labels alone does not establish data behaviour.

Use tabs for alternative service descriptions and an accordion for short questions such as What happens after I send a request? Put each answer inside the corresponding panel/item. In the edit canvas, a component may show its underlying content structure so you can edit all children. Switch to preview for the actual tab or accordion interaction. Click each heading and confirm it reveals its own content without hiding the contact action permanently.

For an optional project gallery, select a slider. Set Slides Per View to 1, enable Show Navigation Arrows and Show Pagination Dots, and leave Autoplay off for the first test. Move forward and back manually. Then try Transition Speed (ms) 300 and, if needed, an autoplay delay of 5000. A gallery should remain usable without waiting for automatic movement.

A dialog suits a compact contact explanation; a drawer suits a longer side panel. Give the target a unique ID, such as consultation-details, and wire a button to ui.dialog with Dialog id consultation-details and Action open, using the Runtime Action panel. Set Show Close Button on the dialog and decide whether Close on Overlay Click is appropriate. For a drawer, inspect Slide Direction, Width, Height and Show Overlay. Exercise open, close and reopen in external preview.

A mega menu is an advanced navigation alternative. Its settings include Trigger Type, Animation, Hover Delay, Hide Delay and Mobile Breakpoint. Choose a click-capable interaction for touch access, then inspect desktop and phone operation separately. For the later Runtime Data exercise, use a regular source container with the chosen responsive CSS layout, keeping the grid component's own data/search/filter system as a separately tested branch. This prevents conflating the grid component's configuration with the runtime row-template contract. Do not add every component to the final page just because it exists. Keep the service grid and useful questions; retain the other components in a training screen until their interaction is satisfactory.

6. Adapt the layout across screen sizes

Use the desktop, phone and tablet preview controls in the top toolbar. The orientation control changes the current device orientation. These controls let you inspect one page under different viewport sizes; they do not create independent pages with separate content.

Select the narrow phone icon in the top toolbar. The current app gives both tablet and phone buttons the accessible label “Phone View”; visually use the narrow phone icon, not the wider tablet icon. This recorded canvas is 446 pixels wide and its introductory paragraph wraps. It verifies the viewport change, not the completed two-card responsive design.

Begin on desktop and note the intended relationship: the main heading above the service grid, two cards alongside one another, and the contact area after the services. Switch to phone. The cards should become a single column, the heading should wrap within the page, and the contact button should remain readable without horizontal scrolling. Switch to tablet and landscape orientation to catch awkward intermediate widths.

When something overflows, select its container first. Look for a fixed width, a child minimum width, excessive padding or a long unbroken value. Reduce the constraint that caused the overflow. Shrinking every font can make the screen fit while making it harder to read. For the grid, use the breakpoint column settings rather than manually moving the second card below the first.

Open the external preview using the external-link control, whose tooltip describes full functionality with external loading. The internal design canvas includes editing infrastructure; an external page tests loading, links and runtime behaviour in the site's context. For signed-in staff, the preview route can use /__preview/page/<site>/<page>; use the URL the application opens rather than fabricating a production address.

Follow every navigation link and activate the contact interaction in that external window. A button that is selectable in the canvas has not yet been tested as a visitor control. After correcting a layout, save, reopen preview and inspect the same width again. Your result is a single saved page whose content and interactions remain usable at desktop, tablet and phone sizes.

Check the finished checkpoint at phone width

After applying the styled checkpoint in the layout chapter, select the narrow phone icon again. The same two cards should stack, while the heading becomes smaller and wraps naturally. Scroll to the second card and contact area; checking only the top of the page can miss an overflowing button lower down.

Verified in the saved page: the phone canvas is 446px wide, the grid has one 366px content column and the heading is 42px. Both cards remain present and the body has no horizontal overflow. The desktop check showed two 516px columns and a 76px heading. These measurements describe this editor viewport, not every possible device.

The two service buttons point to the existing #contact section. At this checkpoint, that is navigation only. A working visitor submission still requires the form and runtime-action configuration later in the course. Do not report that an enquiry was sent merely because this section appeared.

7. Organise multiple screens within the page

A page can contain multiple screens in the editor. Use them to organise a richer design, such as a service overview and a separate gallery composition. A screen is part of the page; it is not automatically another independently published page record.

Open the screen navigator and select the screen you intend to change.

Hover over the screen tab to reveal Screen Options. The menu opens with Name, screen slug, Order and Description. This capture shows the starting fields before the example values are entered. If a selected element’s floating toolbar overlaps the menu, use Clear Selection first. From Screen Options, inspect Edit Screen. Set Name to Service overview, the screen slug to services-overview, and Description to Primary service selection and contact action. Give it Order 10. Lower order values are intended to render before higher values when screens combine with a parent page.

Use Clone to make a training variant, then rename it Project gallery, give it slug project-gallery and Order 20. Change its content so you can tell which screen is active. Use the drag handle to reorder screens, then reopen their options and inspect the persisted ordering. The Style action opens styling for that screen; use it to set the gallery background without unintentionally repainting the service screen.

Save the page and switch away and back to both screens. Check their names, contents and styles. Inspect external preview to establish how this site's page rendering uses the screen arrangement. A screen slug must not be presented as a guaranteed public URL until that route is actually opened.

To remove the temporary variant, choose Delete Screen and then the second Confirm action. Deletion is offered when more than one screen exists. Read the selected screen before confirming, since the page selector and screen selector represent different levels. Save and reopen: the service overview should remain intact, and the removed test screen should be absent.

8. Set page identity, metadata and page data

Open the page property area and choose Page Config. This form edits the page record, whereas the element panel edits the current heading, card or container.

Open Show Page Config on the right toolbar, then Page Config → Information. The recorded page retains its Site, Name, Slug and Title. Close Show Page Tree if its pane covers this form. Your page name should match the name you chose earlier; do not rename an existing page just to match the example. Keep Name and Slug as cedar-services. Set the readable Title to Services — Cedar & Form, and use the available metadata fields for a short description such as Explore Cedar & Form consultations and whole-home planning. Use your actual image when the page form offers a social preview image. Metadata describes the page; it does not guarantee a search ranking.

Choose Page Data Config to inspect page-level initial data. This is different from attaching a collection directly to one element. Page-level configuration establishes data available to the page; an element source establishes the dataset for a particular region. Use the datatype picker supplied by the form to choose your actual service collection when the page requires it, then fill only the query or selection controls that the current form exposes. Keep the collection identifier beside your sample records so you can trace the result.

Return to the canvas and give the service region its own data source in the next section. That makes the two relationships visible: page configuration belongs to the page, while the grid and its child bindings belong to the service region. Do not enter a collection display label where a datatype ID is required.

Save and reopen Page Config. Read the identity and metadata again. Then reopen Page Data Config and check that the intended datatype remains selected. If the page shows the wrong services, inspect the selected organisation, collection and query before editing the visible text. Manually replacing a wrong bound label would hide the source problem rather than repair it.

9. Bind collection records to the page

Before changing the page, prepare the collection in Database. Add name and summary text fields, price as a number, active as a boolean and imageUrl as a text URL. Save the two service records from the opening chapter. A collection with field definitions but no records cannot produce two cards. Use only content intended for visitors and configure its access deliberately; permission to inspect records inside Studio does not prove anonymous visitors can read them.

Verified foundation: the text-only collection exercise below passed the local visitor walkthrough, including a saved record change and a clean browser session. The styled service-card extension, images, filters and numeric formatting still need their own outcome checks.

First prove the connection with two simple records

This short check separates binding from layout. Use a harmless text-only collection before applying the same mechanism to the styled service cards. The inspected example uses Course Requests October 3, datatype course_requests_1003, with one Text Field named requestCode and titled Request code. If following the Database lesson, reuse that collection; otherwise create your own equivalent collection and substitute its actual datatype.

1. In Database → Data Explorer, select the collection, choose Add Record, enter DB-COURSE-1003 in Request code and Save. Add a second record with BUILD-RUNTIME-1004. If those example rows already exist, reuse them rather than adding duplicates.
2. In a practice page, open HTML and insert this small section inside the body. Apply the document and wait until Request code placeholder appears. This is deliberately a plain data check, not the finished Services design.

<section>
  <h2>Saved request codes</h2>
  <div id="request-list">
    <article id="request-row">
      <h3 id="request-code">Request code placeholder</h3>
    </article>
  </div>
</section>

3. Select the placeholder heading, open the floating toolbar's Parents, and choose its div parent. Confirm the Property Panel identifies #request-list. This prevents accidentally attaching the source to the heading. Open Runtime → Data. A container opens Data source directly; if the panel instead shows Bindings, choose Attach a datatype. In Datatype, select your collection. Leave filters empty for this two-record check.
4. Choose Open data table. Both saved codes should appear. Close this table using its own upper-right close control, leaving the page editor open.

This is the actual source readback before changing the second record. It proves that two rows exist; the visitor-page result is checked separately below.

5. Select the heading again, use Parents → article, and choose Use as row template in Runtime → Data. The control changes to Row template. Keep one article in the HTML: the runtime repeats it once for each returned record.

6. Select the heading inside that article. In Text content, type data.requestCode, then leave the field. Check Data from still identifies your collection. Do not mark this heading as another row template.

7. Save the page. Open its visitor preview URL and allow it to load. Expect DB-COURSE-1003 and BUILD-RUNTIME-1004 rather than two copies of the placeholder. A blank result requires checking the exact datatype, field spelling, row-template placement and visitor access; an editor-side table is not proof of visitor access.
8. Return to Data Explorer, locate your BUILD-RUNTIME-1004 row and choose its Edit control. Change Request code to BUILD-RUNTIME-1004-UPDATED, then Save. Reload the visitor page. The changed text should appear without editing the page again.

Actual rendered result after the record edit. The same two values also appeared in a fresh browser context with no saved login. No publication or collection access settings were changed during this test. This proves this harmless local fixture's visitor read and update behaviour; check your own collection's intended access before using real records.

Apply the same structure to service cards

Select the service-list container and open Runtime → Data. If you used the styled checkpoint, select the div.service-grid inside section#services: it contains the two articles, while the section also contains its heading. Attach the source to that grid so the section title does not repeat with each record. On a container, Data source opens directly. If you see Bindings instead, choose Attach a datatype. Open Datatype and select your saved collection. The selector shows collection display names; confirm the intended collection instead of choosing an unrelated built-in type. If you are returning to an already bound container, its Data source opens directly. Use Open data table to inspect the underlying records: the two Cedar & Form names, numeric prices and active flags must be present before a list can display them. This shortcut helps separate an empty collection from a broken design.

Configure a filter for data.active equal to true, using a boolean value appropriate to the query control. Sort by the service name and set a page size that includes both examples. If using the advanced query field, enter valid JSON such as {"data.active":true}. The advanced query replaces the structured filter query when present; an old advanced query can therefore defeat later changes to the filter rows. Clear it when returning to the structured controls.

Remove the extra static Whole Home card from the list after saving your layout exercise; the data source will supply that record. Keep exactly one card as the template. Inside the source container, select that service card and choose Use as row template. This marks the card as the structure to repeat for every returned row. The source belongs to the outer list; the row template belongs to the card. Marking the entire page as a row template would repeat far more than the service card.

Select the card heading.

This inspected panel shows the binding controls before a datatype is attached. Data from currently lists site, page and company. It does not yet prove the service collection is connected. After attaching your collection to the container, reselect the card heading and check that its inherited source is correct before binding the name. In Bindings, focus Text content and choose the actual name field from the field browser. Ordinary record fields become paths such as data.name. Focus the paragraph's Text content and bind data.summary. The browser writes into the most recently focused binding slot, so first select the intended slot, then the field. Check Data from to confirm the inherited collection.

For the image, add an attribute binding called src and point it to data.imageUrl; use an alt binding to the service name if no separate descriptive field exists. Attribute binding changes an attribute, while Text content changes words. Use HTML content only for trusted formatted content: that slot renders HTML rather than escaping it.

The same panel supports className and style bindings. A class expression such as data.active ? 'service-active' : 'service-inactive' can select an existing style. In Attributes, data-show or data-hide can control a secondary element's visibility from a runtime path. Select the price span and set Text content to data.price. For its numeric display, add data-format="currency" and data-format-opt-currency="USD" to the bound price element. Formatting affects display, not the stored number.

For nested content, use Loop a sub-array on this container only when the selected record actually contains an array, such as data.tags. Start with the two service rows before adding a nested loop. Save and open external preview. Expect two differently named cards with the two prices. Change one record's summary through the data table, reload the page and look for that exact changed summary. This connects the business record to its visible result.

10. Configure runtime actions and understand submission limits

An action connects an element to an Appmint runtime method. Its Trigger decides when it runs; its Payload supplies values; On success and On error decide the response. A success notification alone is not proof that data was saved.

Current ticket-form limitation: the editor offers ticket.guestCreate, but the current backend requires an authenticated actor and expects title and description. The editor advertises subject and message, and the runtime does not translate those names. A public visitor cannot complete the older guest-ticket exercise as written. Do not publish that form as a working contact route or retry it repeatedly. The setup below explains the controls and the mismatch; a saved-ticket result remains unverified. Use the following local UI action to practise the same configuration process without a backend write.

First configure a local interface action

1. Insert a button with type="button" and label Show service information in the contact section. Apply HTML, then select that button in the page tree.
2. Open Runtime → Action and choose ui.notify. If it is not visible, check that the selected element is the button, not its enclosing section.
3. Set Message to Choose a service above to review its details, Kind to info, and Duration (ms) to 4000.
4. Set Trigger to click. Leave Confirm and both effect chains empty: this method already displays the notification.
5. Choose Apply action, save the page, then open external preview and click the button. The expected result is the exact information message. It does not create a ticket or send an email. The action settings were saved and independently reopened during the local walkthrough. The visitor page retained the same action and payload, but the expected toast did not appear after clicking. Treat the notification result as an unresolved application issue, not a finished working example. Do not substitute a screenshot of the settings for proof of the message.

Actual controls reopened after saving and reloading the practice page. This verifies configuration persistence only. The notification itself did not appear in the local visitor test.

If the button appears to do nothing, first reopen its Action panel and check the saved method, Message and Trigger. Test on the page's visitor URL rather than expecting the editing canvas to execute actions while selecting elements. If the settings are present but no message appears, report the page, action and expected message through Report a Bug. Repeatedly pressing Save does not establish that the runtime action works.

Understand the form configuration before enabling a write

First add the form to the existing contact section. Open HTML, Revert (reload the editor from the current page; discard any unsaved code edits only when intended), and insert this markup after Ask about your project, keeping the surrounding page. Replace YOUR_TRAINING_CATEGORY_ID with the category's actual identifier. Apply it to the canvas, then select the form parent in the tree.

<form id="service-question" data-payload="form">
  <label>Email <input name="email" type="email" required></label>
  <input name="collection" type="hidden" value="YOUR_TRAINING_CATEGORY_ID">
  <label>Subject <input name="subject" required></label>
  <label>Question <textarea name="message" required></textarea></label>
  <input name="priority" type="hidden" value="normal">
  <button type="submit">Send question</button>
</form>

Select the form element and open Runtime → Action. The picker lists ticket.guestCreate and ticket.create. Do not infer access from the method name: the current guestCreate backend rejects unauthenticated requests despite the editor description. ticket.create is the customer-authenticated route and also needs an independently verified payload. The picker filters methods by element; use Show all only when you understand why an action fits a different tag.

The guest payload exposes Email, Category, Subject, Message and Priority. These are the editor’s current field labels, not a verified backend contract. For inspecting a draft, use a training address you control, the actual category ID, subject Room consultation question, message Can a consultation cover shelving and lighting in one room?, and priority normal. Bind visitor-editable values to the corresponding form inputs when configuring the final form; do not leave one learner's fixed email in a publicly used payload. For the supplied HTML form, keep the form-serialization route: after Apply action, reload the HTML from the canvas with Revert and inspect data-payload. If the panel has emitted a fixed object, change it back to data-payload="form", retaining the emitted action/trigger/effect attributes, and apply the document. The matching input names are email, collection, subject, message and priority. This avoids accidentally submitting fixed example values instead of visitor input.

Set Trigger to submit for the form. Leave the submit button as the form's submit control instead of giving both form and button separate write actions. Add the optional confirmation Send this question to Cedar & Form?. Set On success to notify Your question was sent and then reset the form. Set On error to notify an error while preserving the entered fields. Press Apply action, then save the page with the top toolbar.

Do not enable the draft ticket action on a public page yet. After the editor and backend contracts agree, acceptance requires a controlled submission from the intended visitor session, followed by staff-side inspection of the exact saved title, description and reporting email. The backend currently sets new web requests to medium priority; it does not establish the category/priority behaviour advertised by the old form. A toast alone would not establish those values.

For any verified form, exercise the failure path with a required value missing. The form should not produce a usable duplicate ticket, and the visitor should retain enough context to correct the input. If submission fails after complete input, inspect the action authentication requirement, backend payload names and returned error. Here the known subject/message versus title/description mismatch must be resolved before a saved-ticket test. Correct one cause and submit again. A generic database form is an alternative for custom intake; it requires its own collection schema and access configuration, covered in Database.

11. Add animation and post-action effects

Use motion to explain a change the visitor needs to notice. Select the service contact control and inspect Animate in the property panel. Try one available entrance or emphasis treatment, preview it, and remove it if it distracts from the button label. An animation applied to a parent can move all its children; keep the selected element clear.

For a slider or mega menu, use the component's own transition settings when the motion belongs to that interaction. A short slider transition and a menu reveal are different from an element's entrance animation. Test the interaction repeatedly in external preview, especially on a narrow screen, to make sure content does not remain hidden after the first run.

Runtime effects handle what happens after an action. For a working write action, notification and form reset follow successful submission. The ticket action in this edition has an unresolved contract mismatch; the following sequence describes effect configuration, not a completed submission. For a form inside a dialog, add close-dialog after success so the dialog closes only after the write resolves. For an on-page list, refresh:#service-list re-runs the source attached to that target; reload reloads the whole page and can discard unsaved visitor input.

Keep a deliberate effect order. A useful sequence is notify:Your question was sent | close-dialog | reset-form. If you navigate away first, the visitor may never see the other effects. If an action fails, check the error without running the success reset. Save and reopen the configuration. Perform both success and failure paths only with an independently verified action; the blocked ticket example cannot establish these outcomes. The useful result is feedback that follows the actual action outcome, with the contact control still available to keyboard and touch users.

12. Use AI with a controlled editing scope

Save the current page before using AI.

Use Open Build Studio AI near the lower-right edge. This capture shows the prompt input before a request is sent; it does not show a completed AI revision. Select the intended paragraph before submitting the prompt below. Select the service introduction paragraph and open Build Studio AI. Selection matters: the editor supplies the selected element as context and omits the whole body from that context when an element is selected. With no selected element, the AI receives broader page context.

For the selected paragraph, request: Rewrite only this paragraph in plain language, at most 25 words. Keep the existing element, classes, links and data attributes. Mention room consultations and whole-home planning. Submit and wait for completion. Read the paragraph, then inspect its attributes and parent structure. A correct sentence is not enough if a binding or link was removed.

Use Stop generating if the request is clearly going in the wrong direction. Command history can retrieve an earlier prompt; it is not a substitute for page version history. To try a broader change, clear the element selection and request: Suggest a quieter layout for this services page, retaining both service cards, their data bindings and the contact form. Review all affected regions before saving. A prompt constrains intent but does not guarantee scope preservation.

If an applied change removes a card or alters the ticket action, undo the change or restore the previously saved version. Reopen Runtime on the form and inspect the method and payload. Inspect desktop and phone preview after accepting any AI layout change. Only then save the page. The expected result is an intentional revision whose content, responsive structure and operational controls remain intact.

13. Edit the complete HTML document

Open the HTML editor when you need to work on structure or code directly. The current editor accepts a complete document: doctype, html, head and body. Styles and scripts in the head belong to that document. Older guidance describing only separate JavaScript or stylesheet slots does not describe the current full-document authoring workflow.

Before making a code change after a visual edit, use Revert (reload the editor from the current page; discard any unsaved code edits only when intended). This pulls the current document into the editor. Otherwise applying an older buffer can overwrite the headline or binding you just changed visually. Save a copy of the current document locally before a large replacement.

For a small example, add a head style for your existing class:

<style>
  .service-card { border: 1px solid #d8dfd9; border-radius: 12px; }
  .service-card:focus-within { outline: 2px solid #244b3a; }
</style>

Keep the document's existing scripts, head metadata and body content. Use the code editor's apply/save-to-canvas control. The notice Page applied to canvas means the document was applied to the editing iframe. It does not mean the page record was saved. Inspect both service cards, then use the top toolbar Save to persist the page.

If adding JavaScript, begin with a small isolated behaviour on a unique element rather than replacing platform action handlers. The editor writes the document through the browser document API, but the deployed page's loading environment is a separate test. Save, open external preview, inspect the behaviour and then check the published URL. Never place private credentials in page HTML, script tags or runtime payloads: the visitor receives that material.

When the canvas disappears after an apply, inspect the document for an unclosed style or script tag, a replaced body or conflicting CSS. Restore the saved document copy and apply it again. Reopen the page after saving so you test the persisted document, not just the currently open iframe.

14. Save, reopen and restore page history

Use the top toolbar Save after each coherent change. A successful-looking canvas is in-memory state; reopening the saved page tests persistence. Close the editor, return through the Build Studio page library and choose its edit control. Read the page name, heading, service binding and ticket action again.

Open Show Page Config → History. Each row identifies a version and saved time, with View and a restore control. These are actual revisions created during this walkthrough. Viewing the list is verified; restoring a previous version remains a separate test, so no restored-result claim is made here.

Open page properties and its history controls. Identify an earlier saved version by its displayed details. Inspect the version before restoring it so you know which content will return. Restore the version containing the known good contact form, then inspect the page as a complete object: visible text, screens, metadata, data source and action attributes can all matter.

The editor may offer recovery of a newer local autosaved copy when reopening a page. Distinguish that recovery choice from a server-saved historical version. Use the option whose content you actually intend to keep. If two browser tabs are editing the same page, close the stale tab before making the next save; an old buffer is a common source of seemingly lost changes.

After a restore, save as needed, close and reopen again. Open external preview and submit only one new identifiable test question if the form changed. Do not immediately publish merely because the old heading has reappeared. The recovered page should be internally consistent, including the action and data configuration that supported the earlier working state.

15. Publish through the site's review process

Before publishing, open external preview and follow the visitor route: navigation, service list and any detail interaction you have successfully tested. Leave the ticket form disabled: the action chapter documents an unresolved authentication/payload mismatch, and the local notification example did not display its toast. Publishing does not repair either issue. Read the page's publication badge and the active site's setting for serving published pages only.

Press Publish in the top toolbar. The page must already have a saved identifier; the control explains when an initial save is required. Publication saves the page before proceeding. If the organisation requires publication review, the request opens and publication stops at that gate. Complete the authorised review process and return to the page's status rather than treating request submission as public release.

When direct publication or approved publication succeeds, the status should indicate published. Open the actual public page URL from the site's navigation or hosting route in a separate visitor session. Staff preview is designed for signed-in review and is not the same access test. Read the URL and check the page title, both service rows, navigation and the tested detail interaction. Check that visitors are not offered the blocked contact action.

If the public page shows the old content, confirm which site and page are open before retrying Publish. Check the saved version, review status and public URL. A name/slug mismatch or a different site's domain can imitate a cache problem. Compare a distinctive text change, such as the exact introduction sentence, instead of judging only by a familiar layout.

Retain the final page URL, saved version and distinctive text used for your visitor check. After the ticket action is repaired, verify a separate controlled submission and inspect its saved record before enabling that form for visitors.

16. Unpublish while retaining the draft

Unpublish is useful when a page needs to leave the public site while the team retains its editable content. Open the correct published training page and use Unpublish, whose toolbar hint describes keeping the page as a draft. Read the result and look for draft status.

Return to the page library. Open the draft again and inspect the service cards and form. The record should still exist. This is different from deleting a page record or deleting one screen inside it.

Now open the previous public URL in the visitor session. Public availability depends on the site's policy. If the site serves published pages only, the unpublished page should no longer be served as published content. If the site also serves drafts, changing the page to draft is not a dependable way to make the content private. Use the site's visibility/publication settings appropriate to your goal and test the URL again.

For the training exercise, leave the page in the state you intend: a retained draft or a reviewed published page. If republishing, repeat the review gate where required. The result to recognise is both the retained editor record and the actual visitor availability; a success notice alone does not establish both.

17. Diagnose page problems and extend the design independently

When a page fails, identify the layer before changing it. Start with a specific observation: the Room Consultation card is missing, the form reports an error, or the public page has yesterday's heading. Then inspect the smallest relevant chain.

For a missing service, open the source data table. If the record is absent, the design cannot display it. If it exists, inspect the active filter, any advanced query that overrides structured filters, the container's datatype and the row-template marker. If both cards repeat the same text, check whether the heading is still static or bound to the wrong context. Correct the binding, save and reload the same preview.

For a failed form, keep the actual error message visible. Check whether the selected action requires authentication, whether the payload matches the backend contract. In this edition the ticket picker’s subject/message fields do not match the backend’s title/description, and the guest-labelled route requires authentication; this is a known application mismatch, not a learner mistake. Remove any second write action on the submit button. Once that mismatch is repaired and the intended access is verified, submit one uniquely labelled test and look for exactly one corresponding ticket.

For stale content, compare the HTML buffer, applied canvas, saved record and published version in that order. Syncing reads from the canvas; applying writes to the canvas; page Save persists; publication follows the site's release policy. Identify the step that did not happen instead of repeating all four blindly. For a script difference, compare external preview and public runtime rather than relying on legacy slot instructions.

Your independent task is to add Colour Planning, summary A practical palette for one connected living space, price 220, active true to the service collection. Make it appear through the existing row template without duplicating a card manually. Then add one accordion answer and confirm phone navigation still works. The checkable result is three distinct records rendered by one reusable card structure, a functioning detail interaction. Verify each result on your own visitor page. The local service-information notification and ticket submission remain separate blocked acceptance items; their saved settings do not establish successful execution.

Finally, edit the Colour Planning summary, save it and reload the visitor page. If the revised text appears without editing page markup, you have demonstrated the core relationship this course teaches: a saved design presents current business data, while its bindings keep the design connected to those records. Backend write actions additionally require the saved-result check described in the action chapter.