Building Blocks
Before diving into the AI Builder or working with data, it helps to understand how Alchemify is organized and what the key pieces are.
How Alchemify is organized
Section titled “How Alchemify is organized”- Customer — the person or organization that signs up with Alchemify.
- Org — the workspace created at signup (e.g.,
acme.alchemify.ai). One org per customer. Everything you build lives inside your org. - App — a self-contained application within an org. Each app has its own tables, views, and pages. You might have one app for order management and another for project tracking. See Managing Apps for creating, renaming, and deleting apps.
- Users — people invited to use apps within the org, each with a role.
Your data
Section titled “Your data”Tables
Section titled “Tables”Tables are where your data lives. Each table stores a collection of related records — for example, an order management app might have customers, items, and orders tables.
Tables are created through the AI Builder and come with automatic list, detail, and edit interfaces.
Columns & data types
Section titled “Columns & data types”Each column has a type that determines how data is entered and displayed:
- Text — plain text, email, URL, phone, color
- Number — integer, currency, percent, rating
- Date/Time — date, datetime
- Other — boolean, choice (dropdown), file upload, JSON
The AI picks appropriate types based on your description, but you can change them before approving a table.
Relationships
Section titled “Relationships”Tables can reference each other. For example, each order belongs to a customer. In the UI, this shows as a dropdown to pick the related record. The AI sets up these relationships automatically when it creates related tables.
Views are saved queries that combine or filter data from one or more tables. They’re read-only. For example, a view might show “orders with customer names and totals” by joining two tables together.
Views appear in their own sidebar section and work like tables in the UI — you can sort, search, and paginate — but you can’t edit the data directly.
Internal details like indexes and triggers are managed automatically — you don’t interact with them.
Pages are the screens of your app. The AI creates them based on your requests. There are several types, each suited to different needs:
Table views
Section titled “Table views”Auto-generated list/detail/edit interfaces for each table. Created automatically when you add a table. Supports sorting, searching, pagination, and inline CRUD. You don’t need to ask for these — they appear as soon as a table exists.
Data entry pages for submitting records to a table. Include smart widgets for foreign keys, file uploads, and validation. Use these when you want a dedicated entry screen separate from the default table interface.
Reports
Section titled “Reports”Structured data summaries with grouped or nested layouts. For example, orders grouped by customer with line items under each order. Unlike views (which show flat tables), reports use visual grouping to make related data easier to read.
Charts
Section titled “Charts”Visual data representations — bar, line, pie, and more. Created by the AI from your data. Use these when you want to visualize trends or compare values.
Dashboards
Section titled “Dashboards”Pages combining multiple charts, reports, or data summaries into a single view. Good for at-a-glance overviews of your business data.
Wizards
Section titled “Wizards”Multi-step guided flows — onboarding sequences, multi-part forms, or any process that benefits from breaking into steps. Each step has a title shown in a progress indicator, with Back/Next navigation and per-step validation. The AI generates these when your request involves a sequential process.
Custom pages
Section titled “Custom pages”Fully custom pages written in TSX by the AI. For anything that doesn’t fit the other types — landing pages, admin tools, specialized workflows.
Every user in the org has a role that determines what they can see and do:
| Role | Access |
|---|---|
| Owner | Full access including managing admins. Created the org. |
| Admin | Full access except managing other admins or the owner. |
| Staff | Sees business data with limited write access. |
| Member | Sees only their own data. |
Permissions are enforced by the database itself (PostgreSQL Row Level Security), not just the UI. This means there’s no way to bypass access controls — even direct API calls respect the same rules.
Next steps
Section titled “Next steps”- Managing Apps — create, switch, rename, and delete apps
- Using the AI Builder — create tables, views, and pages through conversation
- Working with Data — view, create, edit, and delete records
- Navigating the App — sidebar, URL routing, and user menu