Skip to content
Support
  • There are no suggestions because the search field is empty.

Building Apps (UI)

This page covers how to shape the apps you build: how to create one, how data flows in, common UI patterns, controlling visibility by role, and the save / version / publish flow.

Creating an app

You don't lay out an app component by component in App Builder. You describe the app in a prompt, and the AI generates the screens, layout, and behavior together as a single working app.

An App Builder app is a single screen — usually with sections, sub-views, or modals — not a multi-page site.

The order of operations for any new app:

  1. Decide what the app should do — write down the goal in one sentence before you open App Builder.
  2. Make sure the resources exist — the workflow or table the app will use should already be set up and stable. See Workflows and Tables.
  3. Create the app in App Builder — add your resources, set clear aliases.
  4. Prompt — describe the app in plain language, mentioning the type of app (dashboard, search, form, tracker), the resources by alias, and the key fields.
  5. Iterate, save, publish — small focused prompts give better results than one long one. See Prompting & Best Practices.

UI building blocks the AI uses

You don't pick components from a library — the AI chooses them based on what you ask for. Behind the scenes it uses a few well-known UI libraries to keep the look consistent:

  • DaisyUI — buttons, cards, badges, modals, navigation, general layout
  • AG Grid — data grids with sorting, filtering, and column controls
  • Chart.js — charts and visualizations (bar, line, pie, etc.)

If you want a specific visual style or component, mention it in your prompt — for example, "use a card layout for each supplier" or "show the totals as a bar chart." The more specific you are, the more predictable the result.

Connecting data (binding to resources)

The app reads and writes data through the resources you connect (workflows and tables). When you prompt, the AI sees the schema of each resource and binds the UI to fields by name.

A few things worth knowing:

  • Workflow output is what the app sees. The app binds to the final step's output of the workflow. If you change the workflow's structure, see Workflows for how to refresh the schema.
  • Table fields are visible immediately. Tables have a defined schema, so adding a table as a resource lets the AI use it straight away.
  • Use aliases. Reference resources in prompts by their alias, not their internal ID.
  • Re-prompt after schema changes. App Builder doesn't auto-refresh — see Prompting & Best Practices → Re-prompting when your resources change.

Common UI patterns

These are the most common patterns App Builder handles well. Each one is described as a prompt shape — copy and adapt.

Dashboard — a single screen with summary information, often grouped or charted.

"Build a dashboard showing data from [your_table]. Group items by [field] and show counts and totals. Use charts where appropriate."

Search → Detail — search for a record, click to open a detail view.

"Build a search page using [your_table]. Let me search by [field]. When I select a result, show details including [field1], [field2], [field3]."

List with filters — a list of records with sortable, filterable columns.

"Show a list of records from [your_table] with filters for [field1] and [field2]. Each row should show [main_fields]. Add sorting on [sort_field]."

Form — collect input and save a record (often via a workflow).

"Build a form to create new records in [your_table]. Collect [field1], [field2], [field3]. Show a confirmation message after saving."

Tracker — an operational view that surfaces records needing attention.

"Build a tracker for [your_workflow]. Show records that need attention at the top, with status badges. Let me mark items as handled."

For a richer library of templates, see Prompting & Best Practices → Prompt templates.

Forms

When you ask for a form, the AI typically includes:

  • Input fields matching the resource's columns
  • Basic client-side validation (required, type checks)
  • A submit action that calls the relevant workflow or table
  • A success message and an error message

If you want validation beyond the defaults (for example, "the order quantity must be greater than zero"), mention it in your prompt.

Lists and search

Lists in App Builder come with filtering, sorting, and pagination by default when the underlying data justifies it. If you want a specific filter or sort, name it in your prompt — "add a filter for status and a sort by date, newest first."

For very large data sets, consider:

  • Using a workflow that returns only the records you need (server-side filtering)
  • Showing summary counts in the app and letting users drill down

Detail views

Detail views are usually generated as part of a "search → detail" or "list → detail" pattern. To get a good detail view, tell the AI which fields matter:

"When I click an item, open a detail view showing item code, description, stock, warehouse, and price."

If the detail view needs data from a different resource (for example, the item record from one workflow and the related orders from another), say so explicitly.

State and loading patterns

Generated apps include sensible default states:

  • Loading — a spinner or skeleton while data is being fetched
  • Empty — a friendly "no results" message when the query returns nothing
  • Error — a user-facing error message when something goes wrong (with details visible in the App Bridge logs)

If you want a specific behavior — "show 'No invoices found' instead of an empty grid" — include it in your prompt.

Role-based UI

InApp Roles let you control what different users see or do inside the app once it's running. Use them when:

  • An external user (supplier, transporter) should only see their own records
  • A role like "approver" should see actions that other users don't
  • Some sections should only appear for managers or admins

How it works:

  1. Define the roles in the App Builder editor and attach Vince Live roles or specific users to each.
  2. In your prompt, tell the AI how the app should behave per role — "for the 'external' role, hide the cost column and disable the edit button."
  3. Save and test by signing in as a user with that role.

For the underlying access model and how it relates to Vince Live roles, see Security, Roles & Governance.

Save, version, and publish

This is the lifecycle every app goes through. The mechanics:

  • Build session — while you're prompting and iterating, you're in a build session. Only one user can be in a build session per app at a time.
  • Save — commits the current draft into the version you're working on and ends the build session. Until you save, your work lives in a cache and can be lost.
  • Discard — throws away the unsaved changes and reverts to the last saved version.
  • Create new version — copies the current state into a fresh draft. Use this when you want to make a bigger change without risking the version that's already published.
  • Publish — promotes a version to be the live one that end users see. Only one published version per app at a time. Publishing a new version automatically archives the previously published one.
  • Archive — removes a non-published version from active use. You can't archive the only published version of an app.

A typical flow:

  1. Build and iterate in a session.
  2. Save when the app is ready.
  3. Publish when you want end users to have it.
  4. For the next change, create a new version, iterate, save, publish.

Quick reference

  • Build session — your active edit context; one user per app at a time
  • Save — commit your work and end the build session
  • Discard — throw away unsaved changes
  • Create new version — copy current state into a new draft
  • Publish — make a version live for end users (one published version per app)
  • Archive — remove a non-published version from active use

Where to go next