Skip to content
flowlakes FlowLakes documentation home

Tables and records

A table is where you keep a kind of record, with its own fields and scoped to your tenant. A table can build on a parent and inherit its fields: the parent holds what every child shares, and the child adds its own columns. The shared parent for work items is fl_tasks, which carries state, priority, assignment, numbering, the activity timeline, and SLA due dates. A record and its parent row share one id, so you work with a single record even though it spans the chain.

When you’d use it

  • Model a new kind of record with the exact fields you need.
  • Share the work-item spine by inheriting from fl_tasks, so a new table gets state, a timeline, and SLA without rebuilding them.
  • Define shared fields and behavior once on a parent and have every child receive them.
  • Tailor a child by overriding an inherited field’s label or requirement, or switching off an inherited rule for that table alone.

What you manage

The Tables list

You manage tables on the Tables page (/admin/tables), the sidebar’s “Tables” entry. It is a full-featured list: search by name, filter and sort on any column, and pick which columns show, same as any other record list. The default columns are the label, the stored name, the app it belongs to, whether its records are work or plain, its parent, and whether it is switched on. Four quick views sit above the grid: All, Work records, Made by people, and Switched off. Tables the platform itself makes never appear here at all, not even as a read-only row; they are never a table you manage. A row opens that table’s own page.

New table

New table opens a short dialog, not a blank page. You name it (a plural name, and “one record is a” for the singular), pick an app for its menu entry, and choose Work records or Plain records: work records move through states, get a number, a timeline, SLA and assignment, and plain records are just a list, like locations or vendors. The table’s stored name is derived from what you type and shown live as you type it; once the table is created, that name is fixed.

Folded under “Build on another table” is the one way to inherit: pick a table to start from, and the dialog explains what that buys you, a sentence naming the parent and whether the new table’s records end up work or plain because of it. The parent decides that, not the cards above it: once you start from a real table, whether yours is work or plain follows the parent’s own kind. The parent’s fields show as chips, so you can see what you are inheriting before you create anything. This choice is fixed once the table is created. The list of tables you can start from never offers a platform table or a CMDB table; CMDB keeps its own, separate way of extending a class.

Create table saves the table and opens it straight to its Fields tab.

A table’s page

A table’s own page reads, top to bottom, as a header and six tabs. The header shows the label, a pill for Work records or Plain records, the stored name, and one sentence giving the app it belongs to, its own and inherited field counts, its record count, and its number prefix if it has one. From there: View records, and a menu holding Repair the table and Delete. Beneath the header, when you can edit the table, three fields let you rename it, add or change its description, and move it to another app’s menu (or none) — each saves through the same save bar as the rest of the page.

The six tabs are Fields, Who can use it, Inheritance (only for a table that actually inherits), Rules, API access, and AI. Rules, API access and AI keep settings of their own, so each of those tabs has its own Save button, and says so in its footer; the page’s own save bar at the bottom covers the header fields.

Delete asks first, and tells you beforehand what will actually happen: a table with no records in it is deleted outright, and a table already holding records is switched off instead, keeping the data, reachable again by switching it back on. A table the schema capability still reaches through routing, or a platform table, opens read only here with the reason.

Fields

The Fields tab is a grid: each row is one of the table’s own columns, showing its label, its kind in plain words (never a raw database type), whether it is required, shown in the list, and marked as the table’s display field. A primary key row is marked “Key”. Add a column opens a dialog to add a new field; the edit icon on a row opens the same kind of dialog to change a field’s label, section, help text and display settings. A field’s kind is fixed once it is saved.

The trash icon on a row asks first, and tells you beforehand what will actually happen: a field no record holds a value in is deleted outright; a field a record holds a value in, or a blueprint added, is hidden instead, keeping the values, and the confirm names which and gives the record count. An inherited field has no delete icon here at all — hiding or showing an inherited field for this table alone is the Inheritance tab’s job.

Who can use it

The Who can use it tab has three views of the same access: Roles lists every role that grants access to this table, with what each one may do and how many people hold it. Permissions is the raw permission rows filtered to this table, for a precise look. User assignments shows who holds a role that reaches this table. Changes to who can use a table are made on the role’s own page; this tab is where you check who can already get in.

Inheritance

The Inheritance tab only shows for a table built on a parent. It lists the chain up to the root, the fields and behaviors (rules, notifications, approvals, workflows) this table inherits, and lets you manage them per table: suppress an inherited behavior for this table and its own children, or replace it with one of your own; hide or show an inherited field for this table alone, or edit its label, section or requirement through a child-only override. None of this touches the parent or its other children.

Rules

The Rules tab lists the business rules that run on this table: each rule’s name (linking to its own page), when it runs in a plain sentence (“Before a record is created”), what it does, and whether it is Active or Off. Add a rule opens a new rule with this table already chosen.

API access

The API access tab says in one sentence whether other systems can reach the table, and at which address. Below it: a switch to allow access from other systems, what they may do (List, Read, Create, Change, Delete), the address with a copy button, records per page, and advanced restrictions folded away. Changing the address warns first, because systems using the old address stop working. Under Keys you create a key for another system (its secret shows once, so copy it then) and revoke a key, which asks first.

AI

The AI tab says in one sentence what the assistant does on this table right now. Three sections follow, each explaining what it means for you: Let the assistant work on these records (the switch), What it should know (a short note it reads before every piece of work), and Who approves its changes. Every other setting sits under More settings.

Author a table and set up inheritance in the builder guides.

Good to know

  • Inheritance is on by default; a table can turn it off. When it is on, reading a record shows the parent’s values for shared fields and the child’s for its own, and each field is saved to the table that owns it.

  • Every task-capable record gets a matching fl_tasks row that shares its id. The activity timeline, the SLA clock, and sub-tasks all hang off that shared row.

  • A child override or suppression only affects that child and its descendants, never the parent or its siblings.

  • Suppressing an inherited approval or notification can remove a control. Treat those suppressions as a deliberate compliance decision.

  • A record form is grouped into sections. An application declares which section each field belongs to (for example Details, Classification, Assignment and SLA on an incident). Updating the application files any field still in the General section into its section; a field you moved yourself stays where you put it.

  • A field can carry a minimum, a maximum, or a write once rule. An application can declare a number’s floor and ceiling, a text field’s shortest length, or a field that can be set when a record is created but never changed again (the record’s parent, for example). The platform refuses a value, or a later edit, that breaks the rule, in your own language.

  • A choice shows its color in lists. When a choice value has a color, such as a state or a priority, the list shows it as a colored chip. Change the color on the choice to change the chip.

  • Your tenant id is never shown. It is not a column, a filter or an export field. The server decides which tenant a request reads; a filter, sort or grouping on it is refused.

  • Changing a table’s fields needs the schema capability, and every change is audited. Creating or deleting a table, adding or removing a field, and editing a field’s choices or its table settings need the Tables write capability, not permission to edit records. Each change is written to the audit log with who made it.

  • History shows each change once. Every change on a record appears once in its history, with who made it, when, and the old and new value. Choices show their labels and references show names. The create entry lists the values the record started with, a state change reads “State changed from New to Assigned”, a field that had no value before reads “set to”, and dates and times show in your time zone.

  • On hold is a declared state. A record is on hold when its state is On hold (or a state whose choice pauses the SLA clock). The card at the top names the on hold reason; Take off hold puts it back into work. A new task waiting to be picked up is not on hold. While a record is open and nobody owns it, the card says so and offers Assign to me; once it is done, closed, resolved or cancelled it never asks for an owner.

  • Search finds symbols literally. Searching for <b>, % or C++ matches those characters, not every word that starts with the same letter.

  • Pickers show the person’s display name, with the job title where there is one.

Creating a record

New on a list opens a short create form, not every field on the table. Up front: the fields a person actually fills in, in this order: required fields, the table’s display field, and a short and a long description field where the table has them. Everything else editable sits behind “Add more details”, closed by default, and opens on its own if a field behind it fails validation. A table with none of those shows every field up front instead of an empty form behind a link.

The form never shows a field the person does not write: a field the system populates (an id, a record number), a field set by context (a parent reference), a read-only field (an SLA timestamp the lifecycle stamps), or the record’s state, which starts at its default and appears as a badge once the record exists. Hiding a field never changes whether it is required; a required field with a default is satisfied by that default even while hidden.

Search and filter a list

Every record list has a search box above the grid. Type a word or a number and the list narrows to records whose text or number fields contain it, inherited fields included. The search stays beside the advanced filter: both apply at once, and clearing the box brings the full view back.

The advanced filter can look through a reference. Under a reference field such as Parent incident, the column menu lists the fields of the record it points at, so a filter like “Parent incident, Category is Network” narrows a task list by the incident it belongs to. One level deep, and only where you may read the referenced table.

How it connects

This primitive owns your schema and how fields split across the chain. It does not run automation: a Business Rule decides when logic fires on a record, a Workflow orchestrates a longer process, and the SLA clock owns due-date math. A field’s label, in whatever language a user reads it, is owned by Languages; the field’s stored value never changes across languages.

  • Author a table and set up inheritance in the builder guides.
  • Exact shapes: registry table fl_table_registry (parent and inheritance flag); work-item table fl_tasks (state, priority, assigned_to, parent_task_id); every noun in the glossary.