CSV to App · Your App Cloud
Turn a CSV export into a working app
An export holds what another system recorded. A working app also needs the fields your people fill in, like a status, an owner and notes. Plan both, and decide which fields a newer export may overwrite.
From another system's export to records people work on.
Read the file as text first, choose what identifies a row, then plan how the next export arrives without undoing anyone's work.
01
Check the export opens cleanly
Open the file in a plain text editor before you upload it. Note which character separates the column names, count the columns, and look for a long note that runs over several lines. Then attach the untouched file with the upload button above.
02
Pick the ID and the work fields
In the prompt, name the column the source system uses to identify each row, such as an order number. Then list the fields people will fill in that the export lacks, like Status, Assigned to and Notes.
03
Plan the next import
Say which columns a newer export may overwrite and which belong to the app. Import the same file twice, then confirm the record count didn't change and a status you set in between is still there. Last, say who signs in. Then test the access you describe for each collection with a second account.
What each part of the export becomes.
Read each row across: the part of the CSV, its place in the app, and the check that confirms it. The column names and values are made-up samples.
| In the CSV | In the app | How to confirm it |
|---|---|---|
| The header line, such as order_id,created,email,sku,qty | Field names, each with a type you confirm: text, number, date, yes/no or a choice | Two columns with the same header, such as two called Date, need separate names. Say which one is the order date and which is the ship date. |
| Each data row | One record, with a list view to scan and a detail view to open | A note typed with line breaks spans several lines of the file but is still one row of data. Compare the record count with the number the source system reports, not with the file's line count. |
| The ID the source system gives each row, such as order 10482 | The match key that lets a re-import update a record instead of adding a second one | Confirm every ID is unique and none changed form on the way, such as 00731 turning into 731 or a long number coming back as 4.80123E+11. |
| Columns that repeat on every line, like a customer's name and email on each order | A second collection, Customers, linked to each order by an ID | Pick a customer with several orders and confirm the app shows one customer holding all of them, not one customer per line. |
| A column with a few repeated values, like Pending, Packed and Shipped | A choice field people change from the record | List the distinct values first. Where the source spells one status two ways, tell the app which option each spelling maps to. |
| Yes/no answers written as Y and N, TRUE and FALSE, 1 and 0, or yes and blank | A checkbox field | Say what an empty cell means. Blank often means nobody answered, which is different from no. |
| A date column in whatever form the system writes, such as 2026-09-14 or 14.09.2026 | A date field, with a date picker on the form for records added by hand | State the format in the prompt. Then open a record dated on the 12th or earlier and confirm the day and month didn't trade places. |
| Nothing at all: status, owner and notes aren't in the export | Work fields the app adds, filled in by the people who sign in | Mark these as belonging to the app, and ask for a later import to leave them alone. Give Status a starting value, such as New, and confirm a record added by the next import starts with it. |
| The day you ran the export | An exported-on date shown with the records, entered when you import | Put the export date in each file name. After an import, confirm the date on screen matches that name, not the day you uploaded the file. |
What a CSV leaves for you to decide.
A CSV is plain text with a separator between values. It carries no types, no rules and no link back to the system that wrote it. Whatever the app should know about those values goes in the prompt.
Lines that aren't records
Some exports put an account name or a date range above the header line, or a totals line after the last row. Say in the prompt which line holds the column names, then check that no record is called Total or holds only a date range.
Letters that come out garbled
A name like Müller showing up as Müller means the file was read with the wrong character encoding. If the source system offers a UTF-8 export, use it, then search the app for one accented name after the upload.
Don't re-save it in a spreadsheet
A file opened and saved again in a spreadsheet program can lose leading zeros, shorten long numbers and change how dates are written. Upload the file exactly as the source system produced it, and keep that copy unedited.
Who owns each column after import
Columns from the export belong to the source system. If someone corrects an email address in the app, the next import can put the old one back. Decide for each column whether the app or the export wins, and write that down in the prompt.
Rows that drop out of the next export
An order closed or deleted in the source system may be missing from the next file, with nothing to say why. Choose whether the app archives those records or leaves them open, so the notes people added aren't thrown away.
An illustrative starting point
An app built around the rows, not a copy of them.
Records keyed on the source ID, the work fields the export never had, a second collection where columns repeated, and the date of the export on screen.
A record for every row
People open one order or one registration at a time rather than reading along a line of twenty values. Ask for a list view with the three or four fields they scan by, and a detail view for the rest.
The source ID on every record
Customers and staff quote the order number the source system gave them, so show it on each record and make it searchable. Ask for it to stay out of the edit form, then open that form and confirm the ID isn't a field anyone can retype.
Fields the export never had
Status, Assigned to, Notes and a follow-up date sit beside the imported columns, and people sign in to fill them in. Ask for a list sorted by follow-up date, and check where records with no date end up.
One place for repeated details
Customer details that repeated on every order line can live once in a Customers collection linked to the orders. Correct an address there, then open two of that customer's orders and confirm both show the new one.
A message when a record is assigned
Apps can send email, so whoever is given a record can get a note with a link to it. Assign a test record to yourself and check the message before others rely on it.
Together in your app cloud
The pieces behind the possibility.
Choose the models and services that support the experience you want to create.
Database
Keep data and context for apps and agents
Authentication
Give the right people access
Email
Keep conversations moving
Language models
Reason, write, and understand
A little more context
Good questions.
Why does my CSV open as a single column?
The file uses a different separator from the one the program expected, often a semicolon or a tab. Look at the header line in a text editor to see which character sits between the names. Mention it in the prompt, or export again with commas if the source system offers the choice. Then confirm the first record shows each value in its own field.
How do I bring in next month's export without duplicates?
Import it deliberately into the same app and ask for rows to be matched on the source ID, never on a name. Ask for rows with a known ID to update their record and for new IDs to become new records. Rehearse with a small file first: three IDs the app already holds and one it doesn't, then compare counts.
Will the next import erase the status and notes people added?
Plan it so it doesn't. Tell the app which fields come from the export and which belong to the app, such as Status and Notes. Also say what a blank cell in a newer export means: keep the value the app holds, or clear it. Then set a status on one record, import again, and confirm it stayed.
Can changes made in the app go back to the system that made the CSV?
Not on their own. The upload is a snapshot with no link back to its source. You can export your app's data, then check whether the source system can take in what that export contains. If it can't, choose one place where each field gets edited from now on.
Can a model tidy messy values in the export?
Apps can use models. A language model could suggest a category for each bank transaction from its description, or point out two contacts that look like one person. Treat every suggestion as a draft that a person accepts or rejects, and check the model is available for your app. Model usage is metered separately.
Can the app remind people about records nobody has touched?
Apps can send email and run tasks on a schedule you set, such as a Monday message listing orders still marked Pending three days after import. Send the first one to your own address, and have a person decide what happens to each record on the list.
Which plan does an app built from a CSV need?
An app where people sign in, change a status and add notes has to save those changes, so it needs a backend, which makes it an app with data, and putting it live needs a paid plan. Model and service usage is metered separately, and the pricing page shows what each plan includes.
Explore Pricing for plans, included capabilities, and usage details.
Keep exploring.
Connect information from several tools ↗
See the outcome and the capabilities behind it.
What a CSV export leaves behind ↗
Six sample rows that break an import, how quickly an export falls out of date, and what to settle before you import one anywhere.
Understand data and context ↗
Give information the right place in your app.
Prepare to publish ↗
Check the experience you will share.
Your ideas, up and running
Your next idea has a home.
Build an app. Run an agent. Make it yours.
Start building