Prompting

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.

Quick reference

Habit	Why
Use aliases for resources	Clearer instructions, fewer wrong-field errors
One change at a time	Easier to review and fix
Save often	Sessions can expire
Re-prompt on schema changes	App Builder does not auto-refresh
Run new workflows once first	App Builder needs execution history to infer shape

---

Three habits that make prompts work

1. Be specific about what you want. Vague requests produce unpredictable results. "Build a dashboard showing invoices from invoice_table, grouped by status, with counts for failed, sent, and pending" is far more useful than "Build a dashboard."

2. Reference resources by alias. Use the alias you assigned when adding the resource. "Show data from supplier_table" is clearer than "show the supplier data."

3. Name the fields. When you know which fields matter, say so. The AI may select the wrong fields if you leave it to guess.

---

Good prompt versus 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 progressively. The effective pattern:

1. Start with the simplest version of what you want.
2. Save to lock it in.
3. Add one feature at a time with focused prompts.
4. Create a new version before making substantial changes, so the current state is preserved.

When modifying something existing, describe what to change — not what to rebuild. "Move the chart to the right side" works better than re-describing the whole app from scratch.

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 focused. After each one, review the preview, save, then proceed.

---

Prompt templates

Starting points you can adapt. Replace bracketed sections 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.

---

Build prompt history

Every build session keeps its conversation, so you can see how an app was built and reuse prompts that worked.

1. Open the app in the editor.
2. Open the actions menu (the three dots) next to the version selector and click Build Prompt. While you are in a build session, the Build Prompt button at the top does the same.
3. The Build sessions window lists earlier sessions of the selected version with the person who ran them and the time. Click a session to read the whole conversation: your prompts, the AI's answers, and any screenshots or files you attached.
4. During a build session, click one of your earlier prompts to copy it into the prompt box, then edit it and send it. Outside a build session the history is read-only.

This is useful for handing an app over to a colleague, or for repeating a prompt in a new version or a copied app.

---

Getting unstuck

When a prompt doesn't deliver the intended result:

• Be more specific. If the AI selected the wrong field, specify the correct one. If the layout is wrong, describe what you actually want.
• Break it down. For complex apps, build in smaller pieces rather than re-prompting the entire app.
• Reference resources by alias. Avoid "the data" — use "data from invoice_table."
• Check the App Bridge logs. If something appears broken at runtime, the logs in the editor show exactly what is happening.
• Discard and start fresh. If a build session becomes difficult to recover, discard it and re-prompt from a clean state.

---

When resources change: re-prompting your app

App Builder learns the structure of your workflows and tables at the moment you prompt. If a resource changes later, the app does not update automatically — you need to return and re-prompt.

Run new workflows before you use them

New workflows need to be run at least once with realistic inputs before App Builder can use them (workflows created with the M3 Workflow Builder can be used straight away) — see Workflows — The 1-run requirement for why and how. The same applies after you modify a workflow's output.

When to re-prompt

Return and re-prompt whenever:

• You added a new resource and want the app to use it
• A field was added or renamed in a table the app uses
• A workflow was updated and its output changed (after re-running it once)
• 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.

What changed	Example prompt
New resource added	"I just added orders_workflow as a new resource. Add a section to the dashboard showing open orders from it."
Field added	"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."
Workflow updated	"I updated goods_receipt_workflow — it now returns a 'warehouse' field. Use it to group receipts on the dashboard."
Field renamed	"The field status_message in invoice_table is now called status_detail. Update the app to use the new name."

After re-prompting, Save and republish.

What happens if you don't re-prompt

Change	Impact if ignored
Added field	The field does not appear in the app
Renamed field	Runtime errors when the app tries to read the old name
Deleted resource	The app breaks entirely for every user who runs it
New workflow	The AI cannot use it until it has been run and re-added

---

What to avoid

• Don't put secrets in prompts. No passwords, API keys, or customer-identifying details — prompts are sent to the AI as text.
• Don't expect identical output from the same prompt. The AI is not deterministic. 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 a published app depends on. The app will fail at runtime. Update or replace the resource first.
• Don't forget to Save. Long idle build sessions can expire. Save before stepping away.

---

Further reading

• Resources — set up the workflows and tables your prompts reference
• Publishing — save, version, and publish after prompting
• App messaging — example prompts for apps that exchange messages with Infor OS
• Troubleshooting — when something is actually broken