Appmint Content Studio: Articles, Documentation, Courses and eBooks

These recordings may show an earlier interface or an older cut. Follow the current written instructions below.

• How to Link Post Data for Your Blog on Appmint.io | No-Code Blogging Guide
• How to Create a New Category for Blog Posts on Appmint.io
• How to Create New Post Content on Appmint.io for Your Website | No-Code Tutorial

**Course written guide draft · Current source and schema reviewed 2 October 2026 **

Opening and overview

Why this matters “Categories gives you a reusable hierarchy for organizing content. A category record holds the tree; selecting a node opens that node's properties. We'll create a tree, add and arrange its children, save the structure and reopen it to check that the changes persisted.”

Visual: Depict a named parent with two related children, then move to the actual tree editor. Use one tree throughout. A category hierarchy is not itself a navigation menu or a published product filter; show those consuming features only when their actual binding is configured.

1. Create the category record

Why this matters “Name is the stable identifier. Title is the readable label. The schema also provides a description and image. Children are edited through the tree rather than as a raw array field.”

Follow these steps Open DAM → Categories. On narrow screens, open the Categories panel. Choose New Category, enter name learning_topics, title Learning topics, a description and an owned image if needed. Complete the schema form's save action. Return to Category List, select the saved category and show the tree.

Result: The named record is selected and its editable tree is visible. The editor supplies an initial New Node for an empty tree; it is a starter to edit, not evidence that a meaningful child was already created.

Name rules: The current schema specifies a unique 3–50 character name with letters, numbers, underscores and dashes and URI transformation. Avoid spaces or punctuation in the technical name. Use an available name rather than overwriting an unrelated record after a uniqueness error.

2. Add and edit child nodes

Concept illustration: A category record and its selected child are different editing scopes. Sidebar Save persists the tree. Reopen the category and inspect both children. This is not an application screenshot or evidence that the action has run.

Keep the record, tree and selected node separate

flowchart TD
 R["Category record: learning_topics"] --> T["Tree root: Learning topics"]
 T --> A["Child: Getting started"]
 T --> B["Child: Advanced setup"]
 A --> P["Select node → Properties edits this node"]
 B --> P
 P --> S["Sidebar Save → persist the whole tree"]

Concept diagram, not a screenshot. It explains which part of the category the controls change.

Use a two-child example first. Select Getting started, change its description, then select Advanced setup and confirm that its fields are different. Save the complete tree, leave the editor and reopen learning_topics. Expand its root and check both children and their order. This catches editing the wrong selected node and forgetting the whole-tree save before you attach categories to real content.

If adding a child appears to replace another, do not continue entering the whole hierarchy. Reopen the last saved tree and compare the selected parent and insertion position. The current node-property handler preserves the selected node's existing children; a missing branch after reopening needs investigation rather than recreating all records.

Why this matters “The tree shows structure; Properties edits the selected node. Keep the selected node and its position visible before changing its title.”

Follow these steps Select the starter node. In Properties, enter a stable child name such as getting_started, title Getting started, and its description/image. Use the tree's add control to create another child, select it and give it a distinct name/title such as advanced_setup / Advanced setup. Expand and collapse the parent to inspect its children. Use the category sidebar Save after the coherent edit.

The current node editor updates the working category immediately and hides its own Save buttons. The sidebar Save persists the complete category. Demonstrate that exact save destination instead of inventing a Save button within Properties.

Result: Reopen the category and inspect both child names and their hierarchy. A changed label before Save proves an edit buffer, not persistence.

3. Reorder and remove deliberately

Why this matters “Reordering changes placement. Removing a child changes the tree itself. Read the selected branch before acting so you do not remove the parent while intending to remove one child.”

Follow these steps Drag a non-root node to a before/after position, using the insertion indicator, then Save. Reopen and confirm the order. Add a temporary child, use its delete control, complete any confirmation actually shown by that shared control, Save, and reopen to show only the intended children remain. Do not promise that the root can be dragged; the current tree ignores root drag operations.

4. Maintain the category record and recover the view

Use Edit category on the Category List card for the record's base fields. Return to the tree for child properties. Use Refresh list to reload the records. If No Category Node Selected appears in Properties, select the intended node in the tree; it is not a reason to recreate the category.

On a narrow display, demonstrate opening Categories and Close categories without losing the selected record. If a loading error appears, the sidebar supplies an inline failure state and retry; show its actual result. An empty list and a failed request should not be narrated as the same condition.

Use Delete category only for a separate disposable record after inspecting dependencies. The current list handler calls the delete route directly; do not script a confirmation dialog unless the live shared behavior actually supplies one. Removing the category does not prove that every content reference was migrated or removed.

5. Use the tree in a consuming feature

Why this matters “A saved hierarchy is ready to be referenced. The content or website feature that uses it must select the intended category and decide how it appears to readers.”

Demonstration requirement: In the intended content/product form, inspect the actual category picker and select the saved category or child it supports. Save and reopen that consuming record. Then inspect the corresponding reader/filter experience if configured. Do not substitute a different module's category schema or claim that creating this tree automatically adds public navigation. Exact consumer picker captions and hierarchy behavior remain a capture dependency; the core category editor procedure above is documented.

Why this matters “You have a saved category structure with deliberate names, editable children and a verified order. Keep that structure and its consuming records together when changing identifiers or removing branches.”

Limitations and checks

Schema read: . Core fields and save behavior are documented; exact live create/save/reorder/delete outcomes and a consuming feature's picker remain unverified. Video should preserve continuous actions with concise commentary, supported by a separately explained hierarchy overview.

Written course · documented draft · Live walkthrough pending

What you will build

Tags connect content that belongs together without forcing it into the same category. You will create one reusable label, apply it to two draft posts, find both posts in Content Studio and learn how to rename the label without leaving old values behind.

Unlike a category tree, a tag does not define parent and child relationships. Adding one also does not publish content or add a website menu. See the Categories course for hierarchical organization.

Before starting, have two draft posts available in Content Studio. If you have not created content yet, follow the Content Studio course first. Keep the posts unpublished while learning metadata. The example tag is product-guide; its name is a reusable value, not a required naming convention.

1. Create a tag

Open DAM → Tag, or open DAM → Dashboard → Organize → Tags. The current entry uses Appmint's shared data table for the Tag collection.

1. Choose Add to open the record form.
2. Enter product-guide in Name. The schema specifies a unique name between 3 and 50 characters. Choose a name your editors will recognize and reuse consistently.
3. Enter a Value if your own consuming application needs it. The standard content tag selector uses Name for both its visible label and stored selection; Value does not replace that name in post metadata.
4. Save, wait for the result, then find and reopen the saved record.

The Name becomes the shared label editors select. Value is a separate field; changing it does not rename the tags already stored on posts.

If a duplicate name is rejected, search for the existing record and reuse it. Do not create a near-duplicate merely to get past validation. A failed table load has its own retry state; it is not proof that no tags exist.

2. Apply the tag to content

Concept illustration: Tags link related content without creating a parent–child hierarchy. Filter Content Studio by the tag, then verify the exact two post titles. This is not an application screenshot or evidence that the action has run.

A shared label is different from a category branch

flowchart LR
 T["Tag record Name: product-guide"] --> A["Draft: Choosing a mug"]
 T --> B["Draft: Caring for ceramics"]
 A --> F["Content Studio: filter by product-guide"]
 B --> F

Concept diagram: both posts store the same tag name. This does not represent a verified website filter.

For a multi-page document, open the document and select Categorization beside Content and Settings. This edits the document's post metadata, not the selected page's lesson text. Select the tag, save the document, then reopen Categorization and check it. Use the content-type-specific metadata controls for other post formats; do not look for a tag input inside the body text editor.

After tagging both drafts, return to Content Studio and filter by that tag. Check the two exact titles and their unchanged draft state. A tag record with no associated posts can exist successfully; its creation alone cannot populate a filtered content list. When renaming a label, migrate the stored selections in the affected posts and check the old label no longer remains there before removing the old tag.

Open Content Studio, select a draft post and open its editable post metadata. Find Tags, select product-guide and save the post. Reopen it and verify the selection persisted. Apply the same tag to the second draft.

The shared post schema supports multiple string tags through a collection-backed selector. The post stores selected tag names, not the Tag record ID. If the record form is too narrow to read its fields, expand the form before editing. Confirm the selected tag is visible before saving.

Both posts can share this label while retaining different categories, content types and publication states.

Do not change the publication state as part of tagging. A saved metadata selection is not evidence that an anonymous visitor can access the post. Public publication and visibility belong to the Content Studio procedure.

For a consuming page with a Tags setting, open that actual page configuration, select the relevant tag and save it. The page schema also selects tag names. Check the rendered page separately; layouts can use tag metadata differently. A saved selection alone does not establish a visible public filter.

3. Find posts by tag

Return to the Content Studio dashboard. Open Tag and choose product-guide. Confirm both expected posts appear, allowing for any additional active status, type, category or keyword filters.

The dashboard builds its tag choices from tags attached to posts. Creating an unused Tag record alone does not guarantee a matching dashboard filter option. Apply and save the tag to content, then refresh the dashboard before looking for it.

Combine the tag with Draft to review unpublished material. Clear the other filters when diagnosing a missing result. Return Tag to its all-values state or use the dashboard's filter reset when finished.

Check the result: the filtered list should contain the two exact post titles. Open each post to confirm the stored tag rather than relying only on a similar title or a previously loaded list.

4. Edit, remove and retire tags safely

To remove a tag from one post, edit that post, remove the selected tag, save and reopen. Check the Content Studio filter again. The Tag definition remains available for other posts.

To change a tag definition, open its row's Edit, update the intended field and save. Because posts store names, do not assume that renaming a Tag record migrates existing post metadata.

For a deliberate rename:

1. Create the desired replacement tag.
2. Find posts using the old name in Content Studio.
3. Replace the old selection with the new one on each affected post and save.
4. Check any pages or custom consumers that use the old name.
5. Verify the new filter results before retiring the old definition.

Delete only a disposable or deliberately retired Tag record through its table action and confirmation. Deleting the definition is not a demonstrated cascade that strips the name from every post or page. Existing metadata may still contain the old string, and dashboard facets derive from those strings.

When a keyword search is active, select the individual rows you intend to delete and check their names. The local application now blocks Delete all matching during keyword searches because that API does not carry the search term. Do not clear the search just to bypass this message: doing so changes the scope of the action.

5. Move tag definitions between datasets

The shared table provides Export and Import. Select explicit tag rows before Export when you need only those definitions; with no selection, the export can contain the collection rather than just the current page or search results. Inspect the JSON file before sharing it.

Import opens the data-import wizard targeting this collection. Review the mapped Name and Value, duplicate handling and preview before writing records. The Import and Export Data course covers that wizard in detail. Moving tag definitions does not move the posts that reference them.

The SDK also defines Tag Group with a Name and an array of embedded tags. This menu entry opens Tag; it does not provide a separate tag-group organizer.

Check your finished result

You should be able to reopen the saved Tag definition, find its name on both draft posts and use the Content Studio Tag filter to locate those posts. After removing the tag from one post, that post should no longer match the tag filter. If you rename the label, verify the replacement in each affected record before retiring the old definition.

Limitations and checks

Required captures: Tag creation and reopen; post metadata selection and persisted state; two matching Content Studio results; removal from one post; replacement-name check. No captures have been fabricated for this draft.

Source reviewed: sidebar links.ts; SDK models/tag.ts, models/base.model.ts and models/page.ts; components/data-view/data-table-view.tsx; components/content/post/modern-post-dashboard.tsx. Live proof pending: validation, editor field placement, saved metadata, search/filter results, controlled rename and deletion behavior.

**Course written guide draft · Current module source reviewed 2 October 2026 **

Opening and scope

Why this matters “Comments brings responses from your content into one place so you can find a particular comment and inspect its context. This screen is currently a read-only table. We'll use it to locate a response and distinguish a matching record from an empty search or a loading problem.”

Visual: A real content item and its comment lead into the Comments table. Use the actual configured column names at capture time. Do not illustrate approve, reply, delete or moderation queues: the current module supplies no such row actions.

Before you start

Use an organization where you can read the intended content comments. Retain the known comment text and the original content identifier; two responses can contain the same words. The sidebar entry is singular Comment, while the opened page says Comments. This distinction helps locate the correct screen without looking for a nonexistent moderation area.

No matching comment-table screenshot was available for this pass. The procedure is checked against the mounted read-only component; its current column and search behavior still need a browser check with a real fixture.

Find a comment

Concept illustration: Comments is a read-only lookup, not a moderation workflow. Finding a row does not approve, hide or delete a comment. This is not an application screenshot or evidence that the action has run.

Before the demonstration: Prepare one non-sensitive comment whose distinctive wording and source content are known. Obtain it through the appropriate content experience, not through an invented Add Comment button on this read-only screen. If the source content does not currently support that route, keep fixture preparation as a production dependency rather than claim a visitor submitted it.

Why this matters “A search result helps you locate the record. Its text and source information let you confirm that it is the response you intended to inspect.”

Follow these steps Open DAM → Comment (the page heading is Comments). Let the table finish loading. Read the actual column headings and locate the known record. Use the table's visible search control with the distinctive phrase, inspect the matching row's text and its available content/user/time fields, then clear the search. Search for an intentionally nonexistent phrase and show the empty result, then clear it and return to the original record.

Result: The viewer sees the expected record disappear and return as the search changes. Do not narrate fields absent from the current schema.

Use the available table controls

Show sorting, filters or page navigation only where the actual read-only DataTableView exposes them on this build. For each visible control, choose a meaningful value and inspect the resulting rows. Treat the table's loaded result count and page boundaries as displayed; do not describe an unlimited complete history if pagination is active.

Why this matters “No matches and failed loading need different responses. Clear your search and filters first when a record seems missing. If the view reports a request error, use the displayed retry or reload route and preserve the error if it repeats.”

Keep these checks separate from the main search operation. Do not spend the main demonstration waiting over an unchanged table while explaining unrelated content publishing.

What this screen does not currently execute

The mounted CommentView sets readOnly: true and rowActions: []. It cannot be taught as a demonstrated moderation, deletion or reply workflow. An older app-directory description mentions moderation, but the mounted implementation is the evidence for this course's current scope. Use the underlying content experience for any separately verified reply/moderation operation; do not invent a button here.

Why this matters “Use Comments to locate and inspect responses across your content. Keep the original content identity with the result so a matching phrase is not mistaken for a different conversation.”

Limitations and checks

Exact shared-table column captions, search behavior, filters and pagination still need a current browser rehearsal. This module is read-only; editing and moderation actions are not available here.

BusinessMade entry: Content → Categories (/content/categories).

Create a category tree for the business catalog. A saved Content category does not automatically become a POS filter or menu item; configure and verify its actual consumer.

Scope: This BusinessMade route uses the shared component whose complete procedures follow. Use the BusinessMade menu and organization throughout. Shared references are implementation evidence, not instructions to switch products. These written steps have not been replayed as a new BusinessMade live walkthrough.

**Course written guide draft · Current source and schema reviewed 2 October 2026 **

Reader update: Current mounted source and retained application images inspected 5 October 2026. No new BusinessMade save or external outcome is claimed.

Understand the two selections

First select a category record in Category List; then select a node inside its tree. The record is the stored container. The selected node determines what Properties edits. Changing a node’s name and title is different from editing the category record’s base fields.

In the retained view below, the right side says No Category Selected because no record is open. Select its card first. Once a tree is visible, No Category Node Selected in Properties means select a node, not create another category record. Existing demo names are not recommended names for your catalog.

Personally inspected retained application view; current action/result captures remain pending.

Opening and overview

Why this matters “Categories gives you a reusable hierarchy for organizing content. A category record holds the tree; selecting a node opens that node's properties. We'll create a tree, add and arrange its children, save the structure and reopen it to check that the changes persisted.”

1. Create the category record

Why this matters “Name is the stable identifier. Title is the readable label. The schema also provides a description and image. Children are edited through the tree rather than as a raw array field.”

Follow these steps Open Content → Categories. On narrow screens, open the Categories panel. Choose New Category, enter name catalogue_sections, title Catalogue sections, a description and an owned image if needed. Complete the schema form's save action. Return to Category List, select the saved category and show the tree.

Result: The named record is selected and its editable tree is visible. The editor supplies an initial New Node for an empty tree; it is a starter to edit, not evidence that a meaningful child was already created.

Name rules: The current schema specifies a unique 3–50 character name with letters, numbers, underscores and dashes and URI transformation. Avoid spaces or punctuation in the technical name. Use an available name rather than overwriting an unrelated record after a uniqueness error.

2. Add and edit child nodes

Why this matters “The tree shows structure; Properties edits the selected node. Keep the selected node and its position visible before changing its title.”

Follow these steps Select the starter node. In Properties, enter a stable child name such as homeware, title Homeware, and its description/image. Use the tree's add control to create another child, select it and give it a distinct name/title such as lighting / Lighting. Expand and collapse the parent to inspect its children. Use the category sidebar Save after the coherent edit.

The current node editor updates the working category immediately and hides its own Save buttons. The sidebar Save persists the complete category. Demonstrate that exact save destination instead of inventing a Save button within Properties.

Result: Reopen the category and inspect both child names and their hierarchy. A changed label before Save proves an edit buffer, not persistence.

3. Reorder and remove deliberately

Why this matters “Reordering changes placement. Removing a child changes the tree itself. Read the selected branch before acting so you do not remove the parent while intending to remove one child.”

Follow these steps Drag a non-root node to a before/after position, using the insertion indicator, then Save. Reopen and confirm the order. Add a temporary child, use its delete control, complete any confirmation actually shown by that shared control, Save, and reopen to show only the intended children remain. Do not promise that the root can be dragged; the current tree ignores root drag operations.

4. Maintain the category record and recover the view

Use Edit category on the Category List card for the record's base fields. Return to the tree for child properties. Use Refresh list to reload the records. If No Category Node Selected appears in Properties, select the intended node in the tree; it is not a reason to recreate the category.

On a narrow display, demonstrate opening Categories and Close categories without losing the selected record. If a loading error appears, the sidebar supplies an inline failure state and retry; show its actual result. An empty list and a failed request should not be narrated as the same condition.

Use Delete category only for a separate disposable record after inspecting dependencies. The current list handler calls the delete route directly; do not script a confirmation dialog unless the live shared behavior actually supplies one. Removing the category does not prove that every content reference was migrated or removed.

5. Use the tree in a consuming feature

Why this matters “A saved hierarchy is ready to be referenced. The content or website feature that uses it must select the intended category and decide how it appears to readers.”

Follow these steps Open Storefront → Products, edit the controlled product and use its Categories selector. Search for the intended saved category and select the returned entry, then Save Changes and reopen the product. The product picker loads categories through the storefront category API; it is not a direct rendering of every Content category-tree node. If an intended child is absent, inspect the actual API-backed choices instead of inventing a nested picker result. Check the customer listing or POS category consumer separately where configured. Do not substitute a different module's category schema or claim that creating this tree automatically adds public navigation. Exact consumer picker captions and hierarchy behavior remain a capture dependency; the core category editor procedure above is documented.

Why this matters “You have a saved category structure with deliberate names, editable children and a verified order. Keep that structure and its consuming records together when changing identifiers or removing branches.”

Limitations and checks

Schema read: . Core fields and save behavior are documented; exact live create/save/reorder/delete outcomes and a consuming feature's picker remain unverified. Video should preserve continuous actions with concise commentary, supported by a separately explained hierarchy overview.

BusinessMade routing and outcome check

The menu and route were checked in packages/ui/src/ui/sidebars/business-made-links.ts and apps/business-made/src/shell/route-registry.ts. Open the module through the route stated at the start, perform the controlled procedure, save, reopen and inspect its actual BusinessMade consumer. Do not infer branch isolation from a header location selection when this shared screen reads organization-wide records. Record any access refusal or consumer mismatch with the exact record identity. No new provider, payment, physical-device or live-tenant action was performed for this adaptation.

Check the exact saved structure

After sidebar Save, return to the list and reopen the same record. Expand the same branch and compare each child name, title and order. If you changed a node but did not save the full category, an on-screen label alone is not persistence evidence.

Before using Delete category, inspect which content records refer to it. The current list handler calls delete directly; do not rely on a confirmation window to provide another chance. A separate disposable tree is the appropriate place for a deletion exercise. Current tree editing, saved children and a verified downstream category consumer remain capture gaps; the retained starting list proves none of those results.