TechAppForceEntities
Business objects backed by a table or view, with feature flags.
An entity (AppObject) maps to a table or a view in the environment's database. Registering a table creates its fields, three saved queries and default access.
Feature flags
Entities turn platform features on or off: change tracking, global search, reporting, activities, sharing, versioning, comments, lifecycle, approvals, location tracking, soft delete, caching and layouts.
Views
Views can be registered as entities for reading. Writes through a view are redirected to its underlying table.
Creating tables
Table definitions are planned against the live schema. The platform creates tables, adds columns and alters them, but never drops anything; a dry run returns the SQL for review. Tables need a GUID primary key.
AppObjects
In TechAppForce the entities your app stores are called AppObjects. If your database has eight tables and four views registered with the platform, your app has twelve AppObjects. Manage them under App Builder > App Setup > Entities, or in the TAF Studio explorer.
| Property | Meaning |
|---|---|
| Display name | The name shown in the UI. You can change it. |
| System name | The name taken from the database table. It cannot change after creation. |
| Object type | Table or View. A view is read-only: no lifecycle, no workflows, and writes are rejected. |
| Creation type | Standard (a table you brought) or Custom (created on the platform). |
Create or register an entity
Create a new entity
In TAF Studio, run TAF: New Object, add fields with TAF: Add Field to Object or TAF: Add Columns, and use TAF: Generate SQL Preview to see the SQL before anything runs. Studio creates the table, with a GUID primary key, and registers it as an AppObject.
Register a table that already exists
If you add a table or view to your database directly, register it so the platform can use it:
- Sign in with App Administrator access.
- Go to App Builder > Others > Custom Activity and scroll to Register AppObject.
- Select the database connection and enter the exact table or view name. Spelling and case must match.
- Choose Register, then confirm the new AppObject appears under App Setup > Entities.
In Studio the same step is TAF: Register Existing Table.
Fields
Each field (the product also calls them AppFields) maps to a column. For each one you set:
- Field name, the internal name, which is fixed once set, and a display name you can change.
- Field type and the matching SQL data type.
- Required, Unique, Searchable and Bulk Update (whether the field can be changed in a bulk update).
- Validation rules, and for pick lists the list of choices.
| Group | Field types |
|---|---|
| Text | Text, Text area, Rich text, Email, Phone number, URL |
| Numbers | Number, Currency, Percent |
| Dates | Date, Date and time |
| Choices | Checkbox, Pick list, Multi-select pick list |
| People and links | User, Lookup (to another AppObject) |
| Generated | Auto number and formatted next number (for example invoice numbers), sequence number |
| Other | Geo location, JSON, Array |
Generated numbers are assigned by the platform when a record is created and cannot be edited afterwards. Choice lists that several fields share can be kept as enums (in Studio, TAF: Enums).
Lookups and relationships
A lookup field links one AppObject to another, for example a WorkItem to its Project. A criteria builder on the lookup narrows which records can be picked. The reverse side is a child relationship: a Project has many WorkItems. Configure it on the entity's Relationship tab by choosing the related AppObject and the type (one-to-many or many-to-one).
Relationships are what let a query return related fields and child records in one read, and what lets access rules and releases follow the links between entities. See Queries.
Many-to-many links and self-referencing hierarchies are modelled with a junction entity, or with a database view registered as a read-only AppObject.
Entity settings
Each AppObject has settings that switch platform features on for its records:
| Setting | What it enables |
|---|---|
| Allow Tracking | Change history on every record (on by default). |
| Searchable | The entity’s records appear in global search (on by default). |
| Allow Reporting | Reports over the entity (on by default). |
| Allow Activities | The activity feed on records (on by default). |
| Allow Sharing | Sharing an individual record with a user, team or role (on by default). |
| Enable Comments | Comments and mentions on records. |
| Blueprint Support | A lifecycle of statuses and transitions. See Lifecycles and approvals. |
| Soft Delete | Deleted records are marked, not removed. |
| Versioning | The entity’s records travel in the data diff of a release. |
| Layout Customization | Choose the create, update and quick view screens for the entity. |
| Allow Location Tracking | Location data on records. |
Record info and history
Every record has a record info entry kept by the platform: created by and on, updated by and on, owner, tenant, app and environment, deleted flag, record title, tags and lifecycle status. Queries can select these as RecordInfo fields, and the detail layout uses them for the record title, status dropdown and history. Configure a dynamic record title so each record has a meaningful name.
Because this data is central, a business “active” flag must be a real field on your entity, not the platform's own flag.
Changing a live entity
- Adding fields adds columns. Changing an existing table only adds columns; it never drops them.
- Custom fields can be added to an entity in a running app without a code change. They can then be used on forms, lists and queries like any other field.
- Edit the existing AppObject rather than creating a second one for the same thing.
- Changes reach other environments only through a release.