Quickstart: build an expense request app

What you will build

An ExpenseRequest entity with a title, amount, date, category and description; a list screen and a form; a Draft, Submitted, Approved, Rejected lifecycle where only managers may approve or reject; Employee and Manager roles that see their own and their team's requests; and a release that carries all of it from Development to the next environment.

Architecture

1. Entity
2. Query
3. Screen
4. Lifecycle
5. Access
6. Release

Steps

1. 1Create the app

   1. Choose Create App and fill in the app code (a unique slug such as expenses), app name, category, logo, access level and description. In TAF Studio, the new-app wizard asks for the same details.
   2. Add the database connection. Pick the database type (PostgreSQL or SQL Server), then enter a connection string or the connection details, and choose Add Connection. The platform tests the connection before saving it. Until a database is connected, nothing can be created in the app.

   Later changes to the app's details and connection live under App Builder > App Setup.

2. 2Define the entity

   Create the ExpenseRequest AppObject and its fields. In TAF Studio, run TAF: New Object, then TAF: Add Field to Object for each field. TAF: Generate SQL Preview shows the table the platform will create before anything runs. If you prefer to create the table in your database yourself, register it in the web app under App Builder > Others > Custom Activity > Register AppObject: pick the connection, type the exact table name and choose Register. It then appears under App Builder > App Setup > Entities.

   Field	Field type	Notes
   Title	Text	Required. Used as the record title.
   Amount	Currency	Required.
   ExpenseDate	Date	Required.
   Category	Pick list	Travel, Meals, Equipment, Other.
   Description	Text area	Optional.

   Do not add columns for who created the request or when: every record already carries that in its record info. Then open the entity's settings and turn on Blueprint Support (needed for the lifecycle in step 5) and Allow Tracking (change history).

3. 3Check the queries

   Creating the entity also created its default, list and detail DSQs. Open the entity and go to the DataSource tab to review them. For the screens in this quickstart:

   • The list DSQ should return Title, Amount, ExpenseDate and Category.
   • The detail DSQ should also return recordinfo.title and recordinfo.blueprintid. The detail layout needs these to show the record title and the status dropdown.

   Use Test DSQ on the Summary step to run a query without handling authorisation yourself. In Studio the equivalents are TAF: Design Query and TAF: Run Query.

4. 4Build the screens

   Go to App Builder > App Setup > Screens and choose + Add Screen. In Studio, run TAF: New Screen then TAF: Design Screen.

   1. Expense requests (List). Set the screen type to List and the data source to the list DSQ. Drag a Grid onto the canvas and bind it to the same DSQ. Add the Layout component, choose the list layout, and set its target component key to the grid's key. Add a hot action button that opens the form.
   2. Expense request (Details). Set the screen type to Details and the data source to the detail DSQ. Drag in fields whose keys match the DSQ fields, then add the Layout component with the detail layout, which provides the title, breadcrumbs and actions.
   3. Preview both screens, then add the list screen to the app's menu (in Studio, TAF: Menus) so people can reach it.

5. 5Add the lifecycle

   Go to Administration > Automation > Blueprint and choose Add Blueprint. Name it, select the ExpenseRequest AppObject, leave the criteria empty so it applies to every request, and save. The Blueprint designer opens.

   1. Add the statuses Draft, Submitted, Approved and Rejected with Add Status, drag each onto the canvas, give each a colour and sequence, and mark Draft as the default.
   2. Draw transitions by dragging from one status to another and naming them: Submit (Draft to Submitted), Approve (Submitted to Approved) and Reject (Submitted to Rejected).
   3. On Approve and Reject, add a Before action that validates the user and allows only the Manager role. A transition whose Before check fails is not offered to that user.
   4. Optionally, in the Settings tab choose Add SLA to set a target time for the approval step.

   Each new request now starts in Draft, and the detail screen shows a status dropdown with only the transitions allowed from the current status.

   Note

   Need more than one approver? A role-gated transition is the simplest approval. For multi-level sign-off (for example the manager, then Finance above an amount), use an approval process, which routes the request level by level and puts each step in the approver's inbox. See Lifecycles and approvals.

6. 6Grant access

   Create the roles under Administrator > Security > Roles with Add Role (Employee and Manager), then open each role to add its users. Next, open the ExpenseRequest entity, go to its Access tab and edit each role:

   Role	Create	Read	Update	Delete
   Employee	All	Own	Own	None
   Manager	All	Team	Team	None

   Employees now see only requests they created or own; managers see their team's. In Studio, use TAF: Roles & Permissions and TAF: Object Permissions.

7. 7Test and release

   Sign in as (or impersonate) an employee, create a request and submit it; then sign in as a manager and approve it. If an access change does not show immediately, refresh the cache and try again. When it works, ship it:

   1. Create a release: give it a title and notes, and choose major, minor or patch. The platform assigns the release number.
   2. Choose the configuration changes to include (the new AppObject, its DSQs and screens) and any data changes, and attach a migration script if you need one.
   3. Review the release and deploy it.

   In Studio this is TAF: Releases, with TAF: Compare Environments to see the differences first. Read Environments and releases for what a release carries and how promotion works.

Result

Employees create and submit expense requests and see only their own; managers see their team's requests and approve or reject them. The build order was entity, query, screen, lifecycle, access, menu and release, each step depending on the one before, and nothing reaches your other environments until you deploy the release.