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. Building custom apps, the deployed-apps register, and Settings are admin surfaces — but creating a mini app is its own tier: by default every manager can compose one, and the tenant can widen that to everyone or narrow it back to app-admins with the Who can create mini apps setting (see Settings below).
3. On the App Builder Home page, the Create fork offers cards stated as needs rather than technologies — Mini app, Custom app, and Start from a template. The cards match your tier: a manager with composer access sees the mini-app and template cards; only full administrators see Build a custom app, because only they can deploy code.
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 the edit loop may change

When you go back to a mini app and describe a change, the drafter proposes it on its own approval card, and the palette covers both directions:

• Adding: fields, saved views, automations, screens, a linked table (up to the three-table cap), a board, a quick-update form, or a public form.
• Changing and removing: rename a field, remove a field, remove a page (screen), edit which status values a workflow field may move between, and revoke a capability the app holds (the card names everything the revocation takes with it — for example, revoking public capture kills the public link).

Removals are referentially protected and refuse honestly rather than half-working: you cannot remove a table’s only page (every table needs one), and an app always keeps at least one page. What the loop still will not do is restructure data underneath you — for that, the app’s own settings page and the Power Tables / Live Boards surfaces remain the home of bulk operations, with the same referential warnings.

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.

Three sources feed the Templates shelf, and all of them render on the same approval card and pass the same validation, so where a plan came from never changes what it is allowed to contain:

• Platform mini-app templates — the curated gallery (Inventory, Equipment Loans, Goods-In Log, Temperature Log, and the rest), each a full working shape: tables, views, automations, screens, and any capabilities, disclosed on the card like any draft.
• Power Tables gallery packs — column structure only; you add automations afterwards through the edit loop.
• Your own mini apps — any mini app already installed in your tenant appears under “Your mini apps” as a start-from shape. Using one compiles an independent copy (name suffixed “(copy)”); the original is never touched by anything you do to the copy.

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 bounded palette, in two tiers.

The base palette — always available — is: update a field on the record, notify a person, open a task, and send a digest (one summary message for everything a saved view currently matches, on a schedule). Triggers are a record was created, a field changed, and on a schedule — so “remind the assignee every Monday about anything still open” and “alert me before these expire” are both expressible, the second as a scheduled digest bound to a saved view filtered to the expiry window. Recipients come from a fixed vocabulary, never a free list: the person who filed the record, the person who created the app, a person-field on the record (an assignee), that person’s manager, a role (admins, managers, members), or a team.

The capability tier adds four grants that only exist if the approval card disclosed them and you approved:

• Send email — to an email-address field stored on the record (one address, rate-capped per hour). This is how a mini app confirms something to an outside contact; it can never email an arbitrary list.
• Request approval — pauses on a named approver’s real approval; what happens on approve and on decline is part of the plan you read.
• Public capture — a public form at a tokened link, so people without accounts can submit records (see the public capture concept below).
• Kiosk capture — a shared-tablet kiosk at a tokened link: an employee taps their badge on the tablet’s reader (or scans the code on it), fills in the kiosk’s own fields, and the record is written as them — no sign-in, no PIN (see badge tap and kiosks below).

A revocation is a first-class edit: “remove the public link ability” drafts a card that names everything the revocation takes with it. What remains off the palette entirely: webhooks, deleting or archiving rows, invoking AI, and nesting an approval inside an approval.

Tables: a plan may hold up to three linked tables — the drafter links them with reference fields (a stay points at its pet, a pet at its owner) and every table gets its own page. Describe more entities than fit and it folds the extras into fields on an existing table and says so on the card in plain words, rather than declining. Power Tables itself still carries the fuller admin palette (including webhooks), and a mini app’s table is an ordinary Power Table, so that door stays open.

Workflow transitions (governed status fields)

A choice field can carry transitions: which status values may move to which. Once governed, the machine is enforced for every writer — the grid, the drawer, mobile, the quick-update door, form submissions, board drags, and the app’s own automations all obey the same rules, so “Received can only move to Inspected or Rejected” is a fact about the data, not a hope about the UI. Values you add later but do not govern stay free, so adding an option can never brick the field.

Public capture and the printed-QR contract

An app with the public capture grant serves a public form at a tokened link — contractors requesting site visits, suppliers logging a delivery — no account needed. Three facts to plan around:

• The link is findable in the app’s settings, and submissions are honeypot-protected and rate-capped per business per hour.
• Fields the app’s own automations write (a governed Status, for instance) are never offered on the public form — outsiders state facts; the app decides workflow.
• Revoking the grant kills the link; re-granting revives the SAME link. The token survives revocation on purpose, so a QR code you printed and taped to the gate is not garbage after a pause-and-resume.

Badge tap and kiosks

Any person field can be set to identify by badge tap (a column setting; the composer’s plan carries it as badge: true). The record form then shows a badge box above the people picker: a tap on a USB or Bluetooth badge reader — or a camera scan of the barcode/QR printed on the badge — fills in the person from the Badge ID on their profile. A badge counts only when it matches that profile field, which admins fill by tap (the profile’s Badge ID box accepts a tap) or through the user import (badge_number, card_number, prox_id…). QR-coded badges whose code is a URL or JSON are unwrapped to the badge number automatically.

An app with the kiosk capture grant also serves a kiosk — a shared-tablet page at a tokened link you open once on the tablet: tap your badge → pick what applies → Done, then the screen resets for the next person. Four facts to plan around:

• The kiosk is badge only: an employee number typed at the tablet is refused, because a number is printed on paperwork while a badge has to be in hand. The tap answers a two-minute step token, and the record is written as the badge’s owner — the person field and the change history both name them.
• The kiosk’s fields are the same anonymous-safe types a public form allows (text, number, counter, choice, date); the person field is filled by the tap and is never a form field.
• The link is findable in the app’s settings (copy it, replace it, or turn the kiosk off) and, like the public link, the token survives a pause so re-enabling revives the same tablets. Lookups and writes are rate-capped per tablet and per business.
• A kiosk is declared when the app is composed or comes from a template (Cafeteria Meal Log ships one); the edit loop cannot add a kiosk to an existing app yet.

Adding an existing table to a mini app

The promote flow has a second form: a Power Tables owner can add their existing table to a mini app they can see, instead of minting a new app around it. The table keeps its data and origin, the app grows a page for it, and the app’s users find it in the app’s own navigation. This is how a table that grew up in Power Tables joins the app your team actually opens.

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 three tiers:

• Authoring tier — full administrators only (admin or above). Build and deploy custom apps, manage API keys, and change Settings.
• Composer tier — governed by the “Who can create mini apps” setting. Compose a mini app, edit one, and start one from a template. The default admits every manager (plus admins and app-admins); a tenant can widen it to everyone or narrow it to app-admins only. Composer-tier users see Home’s mini-app and template cards and nothing of the code-build surfaces.
• Monitoring tier — a delegated app-admin (granted via Apps Marketplace admin delegation) or any global admin. Sees Home, Your apps, Templates, and Analytics. No code builds, and no Settings.

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 an external integration or is not a record-tracking need at all. An ask that is merely big is folded rather than declined: up to three linked tables, with anything beyond that folded into fields — and the card says where the extras went.
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, the public capture link (when the app holds that grant — copy it, rotate the token, or print it as a QR), the kiosk link (when the app holds the kiosk capture grant — open it on the shared tablet, replace it, or turn the kiosk off), 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

Two agents divide this territory, and Ask AI routes your question to the right one:

• The App Builder agent answers about built custom apps: it lists the custom apps this business has built and their deployment state, reports one app’s health, shows a built app’s deploy/enable/disable audit trail, and lists 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. It cannot deploy, roll back, or delete an app, and it does not cover mini apps.
• The Mini Apps agent answers about composed mini apps, for anyone the mini is published to: “what mini apps do we have”, “what fields does the goods-in log capture”, “how many vehicles are in the fleet list”, record lookups and searches, and submitting a mini app’s quick-update form (with confirmation). It respects each mini’s own audience and each table’s access — ask about a table you cannot see and it says so plainly instead of inventing an answer.

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.

One more setting lives on App Builder’s marketplace configure page (Admin → Apps → App Builder → Configure) rather than this tab: Who can create mini apps — the composer tier. app_admins (global admins plus App Builder app-admins), managers (also every manager — the default), or everyone (any member). Creating a first mini app enables the usage-billed host apps whichever value is set, and every created app is visible in App Builder’s register.

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.