TechAppForcePlatform concepts
The vocabulary used throughout the documentation.
| Concept | What it is |
|---|---|
| Tenant | A customer organisation. Tenants own or subscribe to applications. |
| Application | A set of definitions that together make a product, owned by one tenant. |
| Environment | Development, QA or Production for an application, each with its own database connection and release version. |
| Entity | A business object such as Customer or Ticket, backed by a table or view. Also called an AppObject. |
| Field | A column of an entity, with one of 25 field types. |
| Saved query | A reusable query on an entity, run by screens, reports, notifications and workflows. Also called a DSQ. |
| Screen | A list, detail, filter or layout screen stored as Form.io JSON and bound to a saved query. |
| Lifecycle | The statuses of an entity and the allowed transitions between them. Also called a blueprint. |
| Approval process | Who approves a record, in what order and with what quorum. |
| Trigger | A rule that fires on create, edit, delete or a schedule. |
| Workflow | An ordered chain of actions started by a trigger, a transition, a schedule or a manual call. |
| Hook | C# code that runs before or after a data operation. |
| Role and scope | What a role may do to an entity: None, Own, Team or All, per operation. |
Record information
Every record has a companion record-information row holding its tenant, app, environment, owner, created and updated details, soft-delete flag and lifecycle status. The data engine joins it to scope every query. Status APIs identify records by this row's id.
Where an app lives
Tenant
A tenant is one organisation's own space on the platform: its users, its data and its copy of the app's configuration. If you sell a product built on TechAppForce, each of your customers is a tenant. The platform scopes every read and write to the caller's tenant, so customer A never sees customer B's records.
The tenant that builds an app owns its configuration. Other tenants that use the app inherit that configuration, and can customise parts of it for themselves. A tenant that customises an item gets its own copy of that item and stops receiving the owner's later changes to it.
App
An app is one product or solution: a set of entities, queries, screens, menus, lifecycles, workflows, reports and roles, plus a database connection where its records are stored (PostgreSQL or SQL Server). Each app has an app code, a short unique identifier used in its address.
Environment
Each app has environments, such as Development, QA and Production, in a fixed promotion order. Each environment keeps its own version of the app's configuration and its own data. You build in Development; a release promotes changes onward. See Environments and releases.
Data
AppObject (entity)
An AppObject is an entity your app stores, such as Employee, Expense request or Invoice. Each AppObject is backed by a database table (or, for read-only reporting, a view). You can create a new one on the platform or register a table that already exists in your database. AppObject settings switch platform features on for that entity: change tracking, global search, comments, record sharing, soft delete, versioning, lifecycle support and more.
Field
A field is a column on an AppObject: text, number, currency, date, checkbox, pick list, email, user, lookup and so on. A lookup field links one AppObject to another, for example an expense request to the employee who raised it. You do not add audit columns such as created by, updated on, owner or tenant: the platform keeps those for every record in its own audit data, called record info.
DSQ (data source query)
A DSQ is a saved, named query over an AppObject: which fields to return (including fields of related records and child records), filters, sort order and parameters. Screens, reports, imports and workflows read data through DSQs. When you create an AppObject, the platform creates default, list and detail DSQs for it, and you add your own for specific needs. A DSQ always applies the caller's tenant and access scope, so it is safer than raw SQL.
Screens and menus
A screen is a page in the app. The two you build most are a list screen (a grid of records) and a detail screen (a form for one record). There are also layout and filter panel screens. Screens are designed by dragging components onto a canvas, and each is bound to a DSQ for its data. A menu entry makes a screen reachable from the app's navigation. See Screens and forms.
Behaviour
Blueprint (lifecycle)
A Blueprint is the lifecycle of an AppObject's records: its statuses (for example Draft, Submitted, Approved, Rejected), the transitions allowed between them, what happens before, during and after each transition, and optional SLA targets. The record's current status is kept in its record info, and the detail screen offers only the transitions allowed from where it is now. See Lifecycles and approvals.
Approval
An approval process routes a record to one or more people for a decision, level by level. Their steps appear in each approver's inbox. Lifecycles model status; approvals model decisions made by other people.
Workflow and trigger
A workflow is a sequence of actions: create or update records, run a query, call an HTTP endpoint, branch, loop, send a notification or run a script. A trigger starts it when a record of an AppObject is created, edited or deleted, on a schedule, or after a lifecycle transition. Workflows can also be run on demand. See Workflows and jobs.
Access
Role and scope
A role is a named set of people, such as Employee, Manager or Finance. For each AppObject, each role has a scope for each of read, create, update and delete:
| Scope | The role can act on |
|---|---|
| None | No records. Requests are refused. |
| Own | Records the user created or owns. |
| Team | Records created or owned by members of the user’s team. |
| All | Every record in the tenant. |
A user with several roles gets the broadest scope any of them grants. Screens, menu items and individual components can also be restricted with named permissions. See Roles and access.
Releases
A release is a numbered, reviewable package of changes that moves from one environment to the next. It is built from a diff: you see which AppObjects, DSQs, screens, scripts and reference records differ, choose what to include, optionally attach a migration script, and deploy. Release numbers follow major.minor.patch.
How they relate
- A tenant uses one or more apps. Each app has environments, and each environment its own configuration version and data.
- An app contains AppObjects. Each AppObject has fields, DSQs, an optional Blueprint, access rows per role, and optional triggers and workflows.
- Screens read through DSQs. Menus open screens. Reports and imports also work through DSQs.
- A Blueprint transition can open a screen and run workflows. A workflow can update records, move statuses and send notifications.
- Releases carry the configuration of all of the above from Development onward.
A practical build order follows those dependencies: AppObject, then DSQ, then screen, lifecycle, workflow, notification, menu, and finally a release. The Quickstart walks through it.