How your app stores data

Every app you build on AppHandle comes with storage built in. There is nothing to set up and no service to connect. When your app saves something, AppHandle keeps it and gives it back the next time it is needed, whether that is a moment later or a year later.

Storage is part of the app

You do not add storage to an app the way you add a page. It is already there, the same way a spreadsheet already has rows. When you ask for a form, a list, or a way to mark something done, the app both shows it and remembers it.

What your app keeps

An app keeps two kinds of information.

Saved items. Each thing the app records is one saved item: one appointment, one product, one student, one invoice. Items of the same kind form a list. A booking app has a list of appointments; an inventory app has a list of products. The desk calls a saved item a record.
The fields on each item. A saved item is made of the pieces of information you asked for. An appointment might have a client name, a date, a time, and a note. A product might have a name, a price, and a quantity. The fields are whatever the app needs, and you describe them when you ask for the form.
The app's own settings. Some information belongs to the whole app rather than to one person: a shop name, opening hours, a chosen colour, a tax rate. The app keeps these separately, and they stay the same for everyone who uses it.

Each field also has a name the app uses to tell one field from another. Those names are plain machine names, built from letters, numbers, and underscores, with no spaces or dashes. The desk shows the name beside the value, and the label a person reads in the app can still say whatever you like.

Files a person uploads

The app's own files (logos, documents, generated images) live in its asset folder. A file uploaded by a signed-in person is different: it belongs to that person, lives in their own folder, and only they and the owner and people who work on the app can open it. A handle function runs as that person, so it can read their folder to do the work, but one person's files are not another person's.

You do not have to file these by hand. When the app needs a profile picture, a homework upload or a scan, your agent wires the upload; the person's identity comes from their sign-in, not from anything the page sends.

Your records stay with your app

An app can only ever read and write its own records. No other app on AppHandle can reach them, including another app that you own. The platform keeps each app's records apart. This does not depend on any setting and cannot be switched off.

Reading and saving records is limited to the people the kind of record names, and by default that means a signed-in person. If you want the app to keep something for each person, ask the builder to add sign-in; Give your app its own sign-in covers that.

Who sees which records

A record belongs to the person who saved it, and by default that is the only person who can see it. Two people using the same app therefore each see their own list, and a page that lists everyone's records shows an empty list until the app is told otherwise.

Each kind of record carries a setting for exactly that. The builder chooses it while building the feature. Read permission has four choices, from narrowest to widest:

Admins. You, the people you invite to edit the app, and a hired AppHandler see every record; nobody else sees anything.
Users (own). The default. Someone sees the records they saved; you and your editors see all of them.
Signed-in users. Any signed-in person sees every record. Right for a directory, a noticeboard, or a list of listings.
Public. Every record is visible to any visitor. Only for content that is public by design.

Write permission decides who may add and change records:

Admins. The strict choice for a catalogue or a menu the app presents.
Users (own). The default: people add records and change only what they added.
Signed-in users. A shared workspace where people edit each other's records. Only for a list that is meant to work that way.
Public. A contact page or a questionnaire. A visitor can add a record and nothing else — not read it, not change it, not delete it. It only matters on a public app: a private one turns visitors away first.

A record added by someone who has not signed in belongs to nobody, so reading cannot be set to Users (own) while adding is open to anyone. Choose Admins unless the submissions are meant to be seen.

By default the app's pages do not read saved records directly: the app's own server-side code answers each page and decides which records that person gets. This is what makes per-person lists work. A list can be opened to the pages themselves with Allow Frontend calls, for content every user of the app may see — a leaderboard or a public listing. Leave it off for anything personal; when it is on, every user of the app can read the whole list.

That last adding value only stores the submission. It does not send anything by itself. A form that must reach you by email needs a scheduled function that reads the new records and sends them; ask the builder for it, and it will tell you how often the function runs and that each run is charged.

Everyone who works on the app sees every record in the desk whichever value is set: you, the people you invite to edit the app, and a hired AppHandler can all open the Data tab and browse everything the app has stored, whoever saved it.

Look inside at any time

Open your app in the desk and choose the Data tab. Each kind of saved item is listed separately. You can read the records, filter them, remove one you no longer want, and download the list. You do not have to build anything to see this.

The desk shows the records themselves and not who saved them, so "everything" means every record, not whose record it is. The desk also has no way to edit a record and no search box. It reads, filters, removes, and downloads records. Editing and searching are additions you ask the builder for inside the app.

What counts towards your storage

Saved records are not part of the storage you are billed for. What is measured is the app itself, including the files you add to it. Records are kept separately, so an app that saves a great deal does not grow the storage part of your bill. Plans and limits has the allowance and how it is charged.

Deleting an app also deletes its records, its settings, and its files. There is no separate copy to recover afterwards.

Where to go next

Add and edit entries explains how to ask for the form that creates records in the first place, and Who can see your app's data covers privacy in more detail.