App Builder

It depends on which kind of app. Writing, editing, and deploying a CODED app — plus App Builder's own Settings — are restricted to global administrators and are not configurable, because a code build deploys real code into your tenant. COMPOSING a mini app is a tenant decision: the "Who can create mini apps" setting on App Builder → Settings ships open to any manager or above, and an administrator can narrow it to App Builder app admins or to named people and groups, or widen it to everyone. A delegated App Builder app-admin can monitor: Your apps, Builds, Templates, and Analytics. Anyone outside whichever audience you set never sees the builder; they just use the apps it produces, on web and mobile.

A real app: record types with list/detail/create/edit screens, its own page at /apps/ext/, notifications and SLA/overdue logic, optional approval chains and event automations, QR and public submission links, CSV import/export, inbound webhooks with signed secrets, semantic search over its records, demo data, and mobile rendering. It is registered like any other app and enabled per business.

Built apps run inside the MangoApps SDK sandbox with a declared-capability model — they can only call APIs the platform grants, from a fixed list of 16 capabilities, and their data access is tenant-isolated. On top of that, every build passes deterministic fit checks, an AST-level static security scan, and an AI QA review before deploy, and a per-session token budget caps runaway builds.

No. The builder drafts a plan and pauses for your approval before writing code, and you can revise, edit, or decline that plan. After generation you can inspect and hand-edit every file, and after deploy there's version history with restore plus per-app rollback. "Fix with AI" reopens the build conversation against the live code at any time.

App Builder watches for it. Health problems — a quarantined app, a failed load, a suspended event handler, a rolled-back auto-update — raise a lifecycle alert to the people who built and deployed that app, filed as an Inbox action request rather than mailed to every admin in the tenant. From Your apps you can retry the load, roll back to a previous version, or reopen the build with "Fix with AI".

Yes. App Builder issues scoped, revocable API keys and exposes an MCP endpoint, so external tools — Cursor, Claude Code, a CLI — can list tools, call them, and run read-only platform queries against your tenant. Keys track last use and can be revoked from the builder at any time.

Usage-based, billed per deployed app on an annual interval — no per-employee charge and no floor, so a tenant with no deployed apps pays nothing. Only apps that were built here and are running count: an app that fails to load or is quarantined is free while it's broken, redeploying the same app doesn't bill twice, and something you installed from the community directory isn't a build. Mini apps don't touch that meter at all — because nothing is deployed, they carry no App Builder per-app charge; approving your first one enables the two apps that host them, Power Tables (per 1,000 rows) and Live Boards (per active board), and their usage bills there instead. The AI tokens the builder spends are not billed separately either; they stay on the shared platform AI-credits meter, and the app's Analytics tab shows the spend. App Builder is off by default and an administrator opts the business in, because it can deploy code into your tenant.

Start from what the thing is, not from how it should be built. If you're tracking, counting, or logging records — supplies on a shelf, visitors at a desk, equipment on loan — that's a mini app: no code, reviewed on an approval card, and running the same day. If you need custom screens, unusual logic, or an integration with an outside system, that's a custom app and AI writes real code for it.

You don't have to get this right up front. The create screen asks in those terms rather than by technology, and the two paths cross-recommend each other — start describing a tracker in the code builder and it will point you at the faster path. The honest rule of thumb: most of the backlog of small apps nobody ever built is the first kind, which is why that's the default.

They can update a field on the record, notify a person, open a task, send a daily digest, or ask for an approval. That's the entire palette an AI is allowed to author, and the limit is deliberate rather than unfinished: a composed automation cannot call a webhook or delete a row, so an app described in one sentence can't quietly become a way to exfiltrate data or destroy records. Email is in the palette but fenced: a rule may only write to an address already stored on the record, the plan has to declare that capability, and the approval card spells the disclosure out before you say yes. Notifications go to the person who filed the record or the person who created the app — not to arbitrary lists.

Two things worth knowing before you buy. Time-based rules run on a daily or weekly schedule bound to a saved view — so "what's expiring in the next 30 days" arrives as a digest, not as a per-row ping at T-30. And a mini app can span up to three linked tables, composed and installed together; past that, Power Tables itself has the fuller automation palette, including webhooks, for admins who want it.