Word Tables to App · Your App Cloud
Put your Word tables to work
Plan rows as records, columns as fields, and tables that share an identifier as related collections. Check them against the document, then keep improving the tool in your App Cloud.
From your file to a useful experience.
Bring the source, shape the behavior, and review the result.
01
Point to the tables that matter
Say which tables hold records, for example by the heading above each one, and what each row describes. A document can mix data tables with tables used only for layout, so point out the ones to leave as text.
02
Map rows, columns and links
Say which columns become fields and what each one holds, such as a date, an amount or a status. Where two tables share an identifier, describe how they relate.
03
Check a sample, then open it up
Compare a few records with the original table before adding the rest. Then decide who can read, add and change each collection, and share the tool.
Start with the right information.
A Word table is laid out for a reader. Its header row may be typed again after a page break, merged cells may group several rows, and similar tables may not share the same columns. Explain which tables matter and how they fit together.
What to bring
The Word document, a note of which tables hold records, and a short description of who will use the app and what they do with each row.
A check for this workflow
Pick one table and a handful of its rows. Confirm that repeated headers, blank rows and totals did not become records, and that merged cells kept their meaning.
Keep changes clear
Decide how new information reaches the app. An uploaded file does not stay connected to its original by itself.
An illustrative starting point
A possible first version.
A list for each table, a detail view for each row and a form for adding the next one.
Rows as records
Each row that describes one item keeps its values together as a record that people can open, correct and update.
Columns as fields
Column headings can become field names. Decide which fields are required and which hold dates, amounts or a choice from a short list.
Tables that relate
Tables that share an identifier, such as a supplier name or item code, can become related collections instead of separate copies of the same details.
Room to improve
Start with one table, try the main task with real rows, and bring in the next table once the first one reads correctly.
Together in your app cloud
The pieces behind the possibility.
Choose the models and services that support the experience you want to create.
Data models
Turn information into useful structure
Database
Keep data and context for apps and agents
Authentication
Give the right people access
A little more context
Good questions.
Which tables in a Word document work well as an app?
The best candidates are tables where every row describes one thing, such as a requirement, a supplier or an action item, and every column holds the same kind of value. Tables used only to lay out a page are better left as document content.
What should I check in merged cells and repeated header rows?
A merged cell usually stands for a value shared by several rows or a label for a group. Decide whether to copy that value onto each record or keep it as a category field. If a long table was split across pages with its header row typed again, make sure those repeats did not become records.
What if two tables use different columns for the same information?
Say which columns match, for example Qty in one table and Quantity in another, and which table is the source of truth when values disagree. Also point out totals rows, blank rows and rows that only hold a note, because they are not records.
Can several tables become related collections?
They can when the tables share an identifier, such as an item code or a supplier name. Describe how they connect, for example one supplier with many prices, and check a few linked records against the document before people rely on them.
If I revise the Word document, do the records update?
Not by themselves. An upload supplies a snapshot of the tables. Decide whether later changes are made in the app, brought in by a deliberate re-import, or arrive through a supported integration, and test that process before relying on it.
Can a model or an agent work with the records?
Choose an ability that helps this tool, such as interpreting a new document you supply or preparing a next step for a record. Check available models, allowed actions and usage, and keep review where the task needs it.
Who can see and change the records?
Describe who can read, create and update each collection, and whether some fields, such as prices or personal details, should stay private. Check those permissions yourself before you share the app with anyone.
Explore Pricing for plans, included capabilities, and usage details.
Keep exploring.
Your ideas, up and running
Your next idea has a home.
Build an app. Run an agent. Make it yours.
Start building