Working with the Database

Every application has a built-in database (Backbase), and most things you build with Forge — agents, workflows — read and write it. Forge can design the schema, manage the data, and answer questions about what's inside.

Designing tables

Describe the records, not the columns:

You:   I need to store customers: name, email, phone, and which
       manager is responsible for them.
Forge: I'll create a "customers" table with name, email, and phone.
       For the responsible manager — I see you already have a
       "managers" table. Should I link customers to it instead of
       storing the manager's name as text?

That question is the value: Forge sees your existing schema and suggests proper relationships instead of duplicated text fields. Creating a table comes as a medium risk approval; you'll see the full field list in the card's Details before confirming.

Adding a field to an existing table works the same way. Removing a field or a table is high risk — the data in it is gone for good, so read those cards carefully.

Test data

An empty table makes agents and workflows impossible to test. Ask Forge to fill it:

You:   Add 10 realistic test customers, a couple with missing phones.

Inserting data is a medium-risk change — one approval, and the table is populated. This pairs well with building: "create the orders workflow, and add a few test orders so we can run it".

Asking questions about your data

Reading requires no approvals, so exploration is free-form:

You:   How many orders came in today, and what's the total?
Forge: 14 orders today, totaling 182,400 ₸. Three are still
       unpaid — want the list?

Forge writes the query, runs it, and explains the answer. This works on any table, including ones you created long before Forge.

Changing data

Updating or deleting rows also works — "mark order #1042 as refunded", "delete the test customers we added earlier" — with approvals to match: updates are medium risk, deleting rows is high risk, since there's no undo.

Next steps