Introduction

TechAppForce is a metadata-driven application platform. An application is a set of definitions: entities and fields, saved queries, screens, menus, lifecycles, approval processes, triggers, workflows, scripts and access rules. The platform's services read those definitions and run the application, so there is no generated code to maintain.

The three parts

• The platform runs applications: a data engine that serves every entity, a runtime that renders every screen, and services for identity, workflow, notifications, reports and files.
• TAF Studio is a desktop IDE on the VS Code engine for designing, scripting, reviewing and releasing applications.
• TAFI is an AI assistant that proposes changes and applies them only after you confirm.

Where code fits

Configuration covers the common foundation. When your application needs something unique, you write real code at four seams: C# hooks on the server, TypeScript extensions in the browser, a custom front end on the client SDK, or new services on the .NET SDKs. See Extensibility.

Where you use it

This documentation lives on the TechAppForce website. The product itself is at techappforce.io: sign in there to build applications, manage your apps and use the runtime.

Next

Read Platform concepts, then build your first application.

What TechAppForce is

TechAppForce (TAF) is for the kind of business software where every customer wants their own fields, rules, approvals and screens: customer-facing SaaS products, client projects built by agencies, and internal operations tools that have outgrown spreadsheets and email approvals.

Instead of writing a backend for each of those products, you describe the app as configuration. You define the records it stores, the queries that read them, the screens people use, the stages a record moves through, who may see and change what, and what should happen automatically. The platform stores that configuration, enforces it on every request, and renders it in its runtime web app. A customer's change request becomes a setting, not a project.

What you get on day one

These are the foundations most business apps need, already built. The Platform Fundamentals section covers each one.

• Records and data model. Entities, fields, lookups and parent-child records, on PostgreSQL or SQL Server. Every record carries its audit trail: who created it, who changed it and when.
• Saved queries. Named, parameterised reads with filters, sorting, related fields and child records, used by screens, reports, imports and workflows.
• Screens. List and detail screens built in a drag-and-drop designer, with rich components such as grids, charts, kanban boards and schedulers.
• Lifecycles and approvals. Statuses and allowed transitions per entity, multi-level approvals, SLA targets, reminders and escalation, and a work inbox.
• Automation. Workflows that run on record events, on a schedule or on demand, plus notifications by email, in-app message and other channels.
• Reports and data tools. Report designer, PDF and spreadsheet output, scheduled delivery, bulk import from Excel and bulk update.
• Access control. Roles, screen and menu permissions, and per-entity access for each role at None, Own, Team or All scope.
• Environments and releases. Compare configuration and data between environments, then promote a reviewed release.

Three ways to build

All three work on the same app definition, so you can start in one and continue in another.

How an app runs

End users open the app in the TechAppForce web app. The screens they see are rendered from the screen definitions you built; every list, form and chart reads data through a saved query; every save goes through the platform's record pipeline, which checks the user's access, runs validation and any record scripts, writes the audit trail and fires any workflows or notifications attached to that event.

Each app keeps its data in its own database connection. Each tenant's data is kept separate automatically: you never add a tenant column or a tenant filter yourself.

Code inside the app

Configuration covers most of an app. When a rule is genuinely specific to your product, you write code inside the same app rather than beside it:

• Scripts: C# record hooks and workflow actions, compiled and checked on the platform, and TypeScript screen extensions that run in the browser. See Custom scripts.
• Custom API endpoints with an OpenAPI description, for integrations. See Custom APIs.
• Client SDKs for Angular (with components) and React (with hooks), when a product needs its own frontend on top of TechAppForce data, sign-in and permissions. See Client SDKs.

How to read these docs

Start with Core concepts: the dozen terms everything else uses. Then follow the Quickstart to build a small expense request app end to end, and read Environments and releases before you ship anything. The Platform Fundamentals pages go deeper on each building block.

The docs use the names the product's screens use. Where the web app and TAF Studio name a step differently, both names are given.