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

Prompting & Best Practices

Good prompts are how you get good apps. This page covers how to write prompts that work, refine your app step by step, and avoid the most common pitfalls.

Three habits that make prompts work

Whatever you're building, three things consistently make a difference:

  1. Be specific about what you want. "Build a dashboard" is vague. "Build a dashboard showing invoices from invoice_table, grouped by status, with counts for failed, sent, and pending" is workable.
  2. Reference resources by alias. Use the aliases you set when adding resources. "Show data from supplier_table" is much clearer than "show the supplier data."
  3. Name the fields. If you know which fields matter, name them. The AI may pick the wrong field if you don't tell it which one to use.

Good prompt vs better prompt

Good (works, but vague) Better (specific, predictable)
"Build a list of orders." "Build a list of orders from orders_table. Show order number, supplier, date, and status. Sort by date, newest first."
"Make a search page for items." "Make a search page for items using item_lookup. Let me search by item number or name. Show code, description, stock, and warehouse."
"Show me a dashboard." "Build a dashboard from goods_receipt_table. Show receipts by warehouse, with a chart of receipts per day for the last 30 days."

Iterate, don't rewrite

Apps come together in passes, not in one shot. The pattern that works best:

  1. Start with the simplest version of what you want.
  2. Save to lock it in.
  3. Add features one prompt at a time.
  4. Create a new version when you want to make a bigger change without risking what's already working.

When you're changing something existing, say what to change, not what to rebuild. "Move the chart to the right side" lands cleaner than describing the whole app again.

Example: building a supplier portal in three prompts

Prompt 1. "Build a supplier portal. Show suppliers from supplier_table. Each row shows name, code, and country."

Prompt 2. "When I click a supplier, open a detail view showing their open orders from orders_workflow."

Prompt 3. "Add a filter at the top to filter suppliers by country. Add a button on the detail view to send a reminder email for overdue orders."

Each prompt is small and specific. After each one, check the preview, save, then move on.

Prompt templates

Starting points you can copy, paste, and adapt. Replace the bracketed parts with your own aliases and field names.

Dashboard

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

Search → Detail

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

List with filters

"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

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

Supplier portal

"Build a supplier portal. Show suppliers from [supplier_table]. For each supplier, show their open orders from [orders_workflow]. Let me drill into an order to see line items."

Operational tracker

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

Getting unstuck

When a prompt doesn't give you what you wanted:

  • Be more specific. If the AI used the wrong field, name the right one. If the layout is off, describe what you actually want.
  • Break it down. If the app is complex, build it in smaller pieces rather than re-prompting the whole thing.
  • Reference resources by alias. Don't say "the data" — say "data from invoice_table."
  • Check the App Bridge logs. If something looks broken at runtime, the logs in the editor show exactly what's happening.
  • Discard and start fresh. If a build session went sideways, discard and re-prompt from a clean slate.

Re-prompting when your resources change

App Builder learns the structure of your workflows and tables at the moment you prompt. If a resource is added, updated, or reshaped later, your app may still be working from what App Builder learned earlier — so you need to come back and re-prompt.

Run new workflows before you use them

When you create a new workflow, App Builder doesn't know its output shape yet — workflows don't have a fixed schema. App Builder infers it from previous executions.

Before adding a new workflow to an app:

  1. Run the workflow at least 3 times with realistic inputs.
  2. Confirm the output is what you expect — open the workflow logs and check the result of the final step. Make sure the fields you want the app to use are actually there.
  3. Only then add the workflow as a resource and prompt against it.

If you skip this step, App Builder may not be able to use the workflow at all, or it may bind to fields that aren't really there.

The same applies whenever you change a workflow's output — re-run it a few times after the change so App Builder picks up the new shape.

When you need to re-prompt your app

Come back and re-prompt the app whenever any of these happen:

  • You added a new resource (table or workflow) and want the app to use it
  • A field was added or renamed in a table your app uses
  • A workflow was updated and its output changed (after re-running it 3+ times)
  • You removed a resource and need to clean up references to it

How to re-prompt

Open the app, start a new build session, and tell the AI exactly what changed. Be specific.

Adding a resource: "I just added orders_workflow as a new resource. Add a section to the dashboard showing open orders from it."

Adding a field: "The invoice_table now has a 'priority' column. Show priority next to status in the list, and add a filter for it at the top."

Updated workflow: "I updated goods_receipt_workflow — it now returns a 'warehouse' field at the end. Use it to group the receipts on the dashboard."

Renamed field: "The field status_message in invoice_table is now called status_detail. Update the app to use the new name."

Then Save and republish.

What happens if you don't

  • Added fields won't appear in the app automatically
  • Renamed fields can cause runtime errors
  • A deleted resource will break the app entirely the next time someone runs it
  • A new workflow can't be used by the AI until it's been run a few times

What to avoid

  • Don't put secrets in your prompts. No passwords, API keys, customer-identifying details, or anything sensitive. Prompts are sent to the AI as text.
  • Don't expect identical output from identical prompts. The AI is not deterministic — small variations between runs are normal. Iterate rather than retry.
  • Don't write giant all-in-one prompts. Long, complicated prompts produce inconsistent results. Build in pieces.
  • Don't delete a resource that a published app depends on. The app will fail at runtime. Update or replace the resource first, then re-prompt the app.
  • Don't forget to Save. Long idle build sessions can expire. If you have to step away, Save first to lock in what you have.

Quick reference

  • Aliases — set clear names for your resources before prompting
  • Plain language — write the way you'd describe the app to a colleague
  • One change at a time — iterate in small steps
  • Save often — don't lose work
  • Re-prompt on schema changes — App Builder doesn't auto-refresh

Where to go next