App Builder Overview

App Builder

1. What it is

App Builder is where an administrator describes something the business needs and gets a working app, instead of filing a ticket against a six-month internal-tools backlog. It asks one question first: does this need code?

Most of the list does not, so App Builder produces two different kinds of thing:

• Mini apps — no code. Describe something you need to track, count, or log. An AI drafts a plan, you review it on a plain-language approval card, and on approval it becomes a real app at /apps/<slug> with its own icon, launcher entry, tabs, and permissions. Nothing is generated and nothing is deployed — a mini app is configuration stamped onto shared platform primitives (a Power Tables table, saved views, automation rules, and optionally a Live Board), so it inherits their scale, permissions, and audit trail and improves as they do.
• Custom apps — AI-written code. When the need is custom screens, unusual logic, or an integration with an outside system, the same conversation writes real, inspectable files that deploy as their own app at /apps/ext/<slug>. The code path can also produce narrower artifacts — a dashboard widget or an Ask AI agent — which appear as their own categories on the Templates shelf.

Both paths pause for your approval before anything is created, and both produce apps that are enabled per business like any other marketplace app.

• Enablement: App Builder is pay-as-you-go — billed per deployed app, annually, with no per-employee charge and no floor — and off by default. An administrator enables it from the Apps Marketplace; a tenant with no deployed apps pays nothing. Mini apps deploy nothing, so they never add a per-app charge; their rows bill through Power Tables like any other table data.
• What it is not: App Builder is the tool that creates apps. It is not where they run. A mini app runs at /apps/<slug>; a custom app runs at /apps/ext/<slug>. To manage or troubleshoot a running app, use the Your apps tab inside App Builder, the app’s own settings page, or the Custom Apps page under Admin → Apps & Integrations.

2. Standing it up

1. Go to Apps Marketplace and enable App Builder. It is a pay-as-you-go app — there is no seat license. Enabling it costs nothing until you deploy a custom app.
2. Open Apps → App Builder. Only administrators see it; the entire app is admin-only.
3. On the App Builder Home page, the Create fork offers three cards, stated as needs rather than technologies — Mini app, Custom app, and Start from a template. Only full administrators see the fork, because only they can create anything.
4. For a mini app: click Create a mini app, describe what you want to track, and click Draft my app. Review the approval card — fields, views, automations, board, and quick-update form are all shown before anything exists — then click Approve & create app. The app is live immediately at /apps/<slug>.
5. For a custom app: click Build a custom app and describe what you want. The builder drafts a plan showing the record types, screens, and capabilities it intends to generate, then pauses for your approval before writing any code. Approve it, wait for the build, then click Deploy.

What is visible to whom, by default: the two paths differ, and this is the single most common surprise.

• A mini app is published to members the moment you approve it. Its whole point is frontline use — someone reporting a count from their phone — so it appears in members’ launchers straight away. Unpublish it from the Apps Marketplace like any app if you want to stage it.
• A custom app is deployed and enabled but not published. Employees cannot see it in the app launcher until you publish it from the Apps Marketplace, using the same audience controls every other app uses. Enabling App Builder does not make built apps visible to anyone.

Host apps: enabling a mini app also enables Power Tables and Live Boards for the business if they were not already on. A mini app’s grid and board are served by those apps, so the mini cannot work without them. Both are zero-barrier pay-as-you-go, and your deliberate creation of the mini app is the opt-in. Nothing is ever disabled on your behalf. One consequence: because each mini app creates a table, how many mini apps you can run is bounded by your Power Tables table quota — the FAQ has the numbers and where to raise it.

Delegating access: a full administrator can grant another person App Builder app-admin access from the Apps Marketplace. That person can then monitor deployed apps and analytics without being able to create, build, deploy, or change settings.

3. Key Concepts (How It Works)

These are the distinctions worth getting right before you start — most confusion about App Builder traces back to one of them.

Mini app vs. custom app vs. widget

	Mini app	Custom app	Widget / agent
What it is	Configuration on shared primitives	Generated Ruby/ERB files	A dashboard card or Ask AI agent inside a built app
Is code written?	No	Yes, and you can read and edit every file	Yes — it is part of a code build
Is anything deployed?	No	Yes, to /apps/ext/<slug>	Yes, with its package
Where it lives	/apps/<slug>	/apps/ext/<slug>	The dashboard / the Ask AI sidebar
Good for	Tracking, counting, logging, registers	Custom screens, unusual logic, integrations	Surfacing a number, or answering questions
Billing	No per-app charge — rows bill through Power Tables	Counts as one deployed app	Counts with its app

The honest rule of thumb: if you are tracking, counting, or logging records — supplies on a shelf, visitors at a desk, equipment on loan — that is a mini app, and it will be running the same day. If you need screens or logic that a table cannot express, that is a custom app. You do not have to decide correctly up front: the create fork asks in those terms, and the two paths cross-recommend each other.

Plan vs. manifest vs. install

Three words that sound interchangeable and are not:

• A plan is what the AI drafts and you approve. It is data, written in field names, and it is what the approval card renders. A plan is validated before it is shown to you and validated again when you approve it, so nothing can be smuggled past the rules between those two moments. A plan you draft but do not approve is saved as a draft you can resume later.
• A manifest is what a plan compiles into: a versioned JSON definition of the app, stored against your business. The manifest is the app’s source of truth, and its version number goes up each time you make an additive edit.
• An install is the record of that manifest having been stamped into your tenant — the actual Power Table, columns, saved views, automation rules, and Live Board that were created, and which manifest version created them. Stamping is idempotent: re-running it heals a partial install instead of duplicating anything.

For a custom app the equivalent sequence is plan → generated files → deployed package, and the artifact you inspect is the code rather than a manifest.

What “additive-only” means

When you go back to a mini app and describe a change, the edit loop can only add: new fields, new views, new automations, and a board or quick-update form if the app does not already have one. It cannot rename, modify, or remove anything, and it will decline and tell you so rather than pretending.

This is a deliberate design, not an unfinished one. Renames and removals live in the app’s own settings and in the Power Tables and Live Boards surfaces, where referential protection applies and the tool can warn you what a removal will break. It also means the platform can ship a new version of a mini app template without ever overwriting something you changed.

Template vs. copy

Starting from a template compiles a copy. There is no upgrade tie back to the source: a template is a starting shape, and from the moment you approve it the app is yours to change. The app’s settings page says exactly this, naming the template it came from.

Two kinds of mini-app template exist side by side on the Templates shelf: full platform app manifests (fields, views, automations, and board together) and Power Tables gallery packs (column structure only — you add automations afterwards through the edit loop). Both render on the same approval card as an AI draft and pass the same validation, so where a plan came from never changes what it is allowed to contain.

Who owns an object after you change it

Every object a mini app stamps is a real platform object, and you can manage it in Power Tables or Live Boards directly. What you do there decides who owns it:

• Renaming is always free. Views, automations, and the board reference fields by ID, never by name, so a rename never breaks anything and is never overwritten by an upgrade.
• Archiving is not divergence. An archived object still resolves, so upgrades continue normally.
• Hard-deleting an object the app created means you own the app now. Automatic upgrades stop for that app so a future release can never resurrect something you deliberately removed. The app’s settings page says so plainly and names what was removed. If you want the original set back, disable and re-enable the app from the Apps Marketplace — that re-stamps the missing pieces.

Build sessions (custom apps)

Every time you describe a new custom app or reopen an existing one, you work inside a build session. The session holds the conversation with the AI agent, all generated files, and up to 10 version snapshots you can restore. A session progresses through phases: planning → plan review → building → verifying → ready to deploy → deployed. Each session belongs to one business, but co-admins can reopen a deployed app’s session — the session is tied to the app, not the person who started it.

Plan → approve → build (custom apps)

The builder never writes code without approval. It drafts a plan showing record types, screens, workflows, and the capabilities the app will declare, then pauses. You can approve, request changes with feedback (the agent revises and re-presents), edit the plan inline, or cancel to describe something different. If the builder detects that a similar app already exists in the business, it pauses and asks whether to update the existing app or build a new one.

Complexity tiers and the iteration cap

The builder classifies each request as Simple, Medium, or Rich based on the number of record types, workflows, and widgets you describe. Every build turn runs under the same iteration cap regardless of tier; what the tier governs is auto-continue. When a build hits the cap mid-flight, Medium and Rich builds can extend themselves automatically (up to 2 extra rounds) if the Auto-continue long builds setting is on. Simple builds always pause and wait for you to click Continue. Exact numbers are in the FAQ.

Templates

Reusable starting points. The Templates tab carries mini-app templates at the top and coded-app templates below, in three kinds:

• System templates — curated starters shipped with the platform, organised into categories like Getting Started, CRUD / Data Management, HR & People, Automation & Workflows, Dashboard Widgets, and Ask AI Agents.
• Business templates — templates your team saved from successful builds or created manually via the drawer form on the Templates page.
• Central library imports — templates imported from the MangoApps gallery. They arrive as unpublished drafts for review before use.

Example: your HR team describes “a tracker for new-hire equipment requests with an approval step and a dashboard showing pending items.” The approval step makes this a custom app rather than a mini app. The builder classifies it as Medium, drafts a plan with two record types (Equipment Request, Equipment Item), an approval workflow, and a dashboard widget, then pauses. The admin approves, the agent builds, and after deploy the app appears at /apps/ext/new-hire-equipment. The admin saves it as a business template so another location’s admin can start from it.

Deployed apps vs. the builder

A deployed custom app runs independently at its own URL with its own records, settings, and audience. It also has mobile views at /m/apps/ext/<slug> and can expose public submission forms via a shareable link (no login required). Reopening it in the builder loads the deployed files into a session so you can edit or extend it, but changes do not go live until you deploy again. The builder plans, builds, and deploys; the running app serves users.

Records and data

Each built custom app stores its data as records, scoped to your business. Records support file attachments (up to 10 files per record, 10 MB each), platform comments, evidence capture (photo, video, voice with GPS and timestamp), and an audit timeline showing who changed what. Records can also host Live Assist video sessions if that capability is enabled for the app. A mini app’s records are Power Tables rows, with that app’s own change log, search, filters, and import.

Platform capabilities

Built custom apps run inside the MangoApps SDK sandbox and can only use capabilities they declare. The platform validates those declarations at deploy time. Available capabilities include notifications, approvals, tasks, e-signatures, comments, automation, scheduled jobs, AI features, feed integration, incoming webhooks, document generation, geocoding, HTTP access, and cross-app interop. A built app can read your real people, locations, departments, and schedules through declared capabilities — but only what its declaration permits, and only its own business’s data.

What a mini app’s automations may do — and may not

A mini app’s automations run on a deliberately narrow palette. They may update a field on the record, notify a person, or open a task. That is the whole list an AI is allowed to author.

A composed automation cannot send email to anyone outside your company, call a webhook, delete, lock, or archive a row, start an approval, or invoke AI. Recipients are limited to two: the person who filed the record, and the person who created the app — never an arbitrary list. So an app described in one sentence can never quietly become a way to send data out of the company or destroy records.

Two consequences worth knowing before you plan around it:

• Triggers are “a record was created” and “a field changed” — there is no schedule. “Alert me 30 days before this expires” is not expressible. The honest answer is a saved view filtered to the next 30 days, which stays correct without sending anything and which the drafter will offer you.
• A mini app covers one kind of record. If you need two linked tables, the AI declines and says so rather than producing something that half-works.

Power Tables itself carries the fuller automation palette, including email and webhooks, for admins who want it — and a mini app’s table is an ordinary Power Table, so that door stays open.

Health tracking

Each deployed custom app has a health status: Healthy, Failed validation, Failed to load, Failed at runtime, or Quarantined. The Your apps tab badges unhealthy apps, and the Home page shows both the total deployed count and the number that are not loading. Mini apps have no deploy step and therefore no health status; if a stamping step fails, the app repairs itself in the background and shows a “still being set up” state until it is ready.

Who can do what

App Builder itself has two tiers:

• Authoring tier — full administrators only (admin or above). Compose a mini app, edit one, turn one off, build and deploy custom apps, manage API keys, and change Settings.
• Monitoring tier — a delegated app-admin (granted via Apps Marketplace admin delegation) or any global admin. Sees Home, Your apps, Templates, and Analytics. No creation flows, and no Settings. This is a monitoring role, and the surfaces it shows match the actions it allows.

Each mini app is its own marketplace app, so it has its own two roles on top of the above:

• Mini app admin — someone holding an app-admin grant on that mini app, or a Power Tables admin. Can open the app’s settings, rename its vocabulary, print QR labels, and switch the app off.
• Mini app user — anyone the mini app is published to. Note that this is the mini app’s own audience, not Power Tables’. A member with no Power Tables data access can still open the mini app: they get the quick-update door and an honest notice explaining what they cannot see, never a silently empty grid.

Members never see App Builder itself. They interact only with the apps it produces.

4. Running it

Creating a mini app

1. Go to Apps → App Builder and click Create a mini app (or open Compose directly).
2. Describe what you need to track, in a sentence or two. Example: “We lend out projectors and cameras — track who borrowed what, when it’s due back, and flag overdue gear.”
3. Click Draft my app. One of three things comes back:
   • A plan, rendered as an approval card listing the fields with their types, the saved views and what they filter to, the automations and what they do, the board, and the quick-update form.
   • A recommendation, when what you described is already a real MangoApps app. The AI will not compose a toy version of payroll, scheduling, ticketing, chat, forms, or learning — it points you at the real product instead.
   • A decline, with the reason, when the ask needs multiple linked tables, an external integration, or is not a record-tracking need at all.
4. Read the card. If it is not right, edit your description and draft again — nothing exists yet. If it is right, click Approve & create app.
5. The app is live. You land on it, and it is in the launcher for your members.

Drafts you do not approve are saved automatically, so navigating away does not lose the work. Resume or discard them from the Your open drafts card on the compose page.

Starting a mini app from a template

From Templates, the Mini app templates shelf lists full platform app shapes and Power Tables structure packs. Click Use on one and it renders on the same approval card, prefilled. Approve it as-is or discard it and draft your own. Remember that this compiles a copy — from that point on it is yours and template updates do not apply.

Editing a mini app

Open the app and choose Edit from App Builder, or go to Compose and pick the app. Describe what to add — a field, a view, an automation, or a board or quick-update form if the app has none. The proposed change renders on its own card for approval, and applying it bumps the app’s version.

If you ask for a rename, a removal, or a restructure, the drafter declines and points you at the right place: the app’s own settings page and the Power Tables / Live Boards surfaces.

Using a mini app day to day

• Records tab — the full grid, with search, filters, sorting, and the app’s saved views as navigation pills.
• Board tab — the live board, if the app has one. It respects any audience you later set on the board in Live Boards.
• The quick-update door — a narrow “report a value” form. The person identifies one record by its code and enters the new number; the confirmation names the record and shows the movement (for example, 12 → 9), and an optional note lands in that row’s change log. It cannot create records, browse the table, or be pointed at a different table — which is exactly why it is safe to give to someone with no access to the underlying data.
• Print QR labels — from the Manage menu, a printable sheet of one QR code per record. Scanning a label opens that record’s mobile card with − / + steppers, so a phone camera is the only hardware anyone needs.
• App settings — fields and where they came from, vocabulary (rename “records” to whatever your business calls them), the list of everything the app manages, and the on/off switch. Turning the app off hides it for everyone; the data is untouched and the settings page stays reachable so you can turn it back on.

Starting a custom app build

1. Go to Apps → App Builder and click Build a custom app.
2. Type what you want or pick a template. You can also attach images (screenshots, wireframes) to show the agent what you have in mind.
3. The agent drafts a plan and pauses. Review it, then Approve, Request changes (with feedback), or Cancel plan to start over with a different idea.
4. Once approved, the agent builds the code. You can watch progress in real time, cancel mid-build, or click Continue if it pauses at the iteration limit.
5. When the status reads Ready to deploy, click Deploy. The deployer runs a security scan and file validation before anything goes live. If the files match the already-deployed version byte for byte, the deploy is skipped and you see “already up to date.”

Editing a deployed custom app

Open a deployed app in the builder from the Your apps tab (click the row, then use Edit with AI) or from the builder’s welcome screen. Describe what to change in the chat — the agent modifies the existing code in the same session. Changes are not live until you redeploy.

You can also hand-edit individual files in the built-in code editor. The editor accepts .rb, .erb, .json, .yml, .yaml, .css, .js, .txt, and .md files. Ruby files are syntax-checked and security-scanned before saving. The version history panel lets you restore any of the last 10 saved snapshots.

Fixing a failing custom app

The Your apps tab shows each app’s health status (Healthy, Failed to load, Quarantined, etc.). If an app is deployed but not loading, click Retry load to clear the error and ask the platform to reload it. If the problem is in the generated code, open the builder and click Fix with AI — the agent receives the error context and attempts a code-level fix.

Saving and managing templates

After a successful build, click Save as template in the builder to save the app’s specification as a reusable business template. From the Templates tab you can also create templates from scratch, edit, or delete your business’s own templates using the drawer form. System templates are read-only. To import templates from the central MangoApps gallery, click Template Library at the top of the Templates page.

Reviewing build history

Build history lists every custom-app build session in the business, reachable from Your apps and from the Recent builds card on Home. Filter by status (Draft, Generating, Ready to deploy, Deployed, Failed) or search by name. Each row links back into the builder to resume or inspect the session. Both Your apps and Build history support CSV export of the full filtered set.

Viewing analytics

The Analytics tab shows business-scoped numbers:

• Deployed app count and records per app (total and last 30 days).
• Build sessions in the last 30 days by status, with a deploy success rate (deployed vs. failed, excluding drafts and in-progress builds).
• AI token spend attributed to the builder (limited to retained telemetry — the retention window is stated on the page).
• Top templates used by this business, ranked by builds started.

Analytics can be exported as CSV. All numbers are scoped to your business.

Using the Ask AI agent

If the App Builder agent is enabled for your business, you can ask the AI assistant about your built apps from any page — without opening App Builder. The agent can list the custom apps this business has built and their deployment state, report one app’s health, show a built app’s deploy/enable/disable audit trail, and list recent build sessions. As a full administrator you can also ask it to enable or disable a built app, which it confirms with you first.

Two honest limits. The agent cannot deploy, roll back, or delete an app. And it cannot see mini apps at all — it reads the deployed-package register, which mini apps are not in. Ask it about a mini app and it will not find one; use Your apps or the compose page instead.

Downloading and sharing built apps

From an open build session you can download all generated files as a ZIP. Built custom apps can also be submitted to the community marketplace for other businesses to install — use the listing editor under Admin → Apps & Integrations → Custom Apps to manage the listing and submit for review.

Mini apps are private to your tenant by design. They never appear in the public app directory or in another tenant’s marketplace, and there is nothing to publish or submit.

API keys

The builder includes an API key surface for programmatic access. Keys are business-scoped and carry scopes (builder, query, manage). A generated key is shown once — copy it immediately. Keys can be revoked but not re-displayed.

5. Settings

App Builder’s own settings are at Apps → App Builder → Settings (full administrators only).

Setting	Default	What it changes
Auto-continue long builds	On	When a Medium or Rich custom-app build hits its iteration limit mid-build, the builder automatically extends it (up to 2 extra rounds) instead of pausing. Turn off to review progress before each extension.
Alert on health problems	On	Sends a notification when a built app is quarantined, fails to load, has an event handler suspended, or has an auto-update rolled back. Alerts are deduplicated per app per event — at most one every 6 hours.
Alert when an update is available	On	Sends a notification when a newer published version of an installed app can be applied. Informational only — at most one per new version.
Additional notification recipients	None (the app’s builder + App Builder admins only)	Widens built-app alerts to an additional admin-configured recipient group. Without a builder or group, alerts fall to the business’s App Builder admins — or, if none are designated, to every administrator.

All four settings concern custom-app builds. They do not affect mini apps, which have no build job, no iteration limit, and no deploy step.

Per-app settings live on each app’s own settings page, not here — record visibility, notifications, and automations for a custom app; fields, vocabulary, and the on/off switch for a mini app. Licensing and who can open App Builder are managed from the Apps Marketplace.

6. More help

• App Builder FAQ — specific setup and operating questions, exact limits, troubleshooting, and allowed ranges for settings.
• Admin → Apps & Integrations → Custom Apps — the platform-level registry of all deployed custom apps, including community marketplace installs.
• Power Tables and Live Boards — the apps that host a mini app’s data and board. Anything you can do to a table or board there applies to a mini app’s, too.
• Ask AI — the assistant answers questions about App Builder and your deployed custom apps from any page, without opening the app.