Data protection in TimeTonic does not rely on a single setting, but on around thirty mechanisms spread across eight levels, from the user account down to the API call.
This page brings them all together, with what each one protects and where it is documented. It is the entry point of this category.
How to read this page. The levels go from the broadest to the finest. A setting applied at a high level, for example a member's role, applies to everything below it. A fine-grained setting, for example a column made invisible, only protects within the view where it is applied. A sound configuration combines several levels.
1. The account: who can sign in
2. The workspace: who gets in, and with which role
| Mechanism |
What it protects |
| Member rights |
The role (Owner, Admin, User), web and mobile access, API access, messages and the member list, person by person. |
| Invitations |
Who has been invited, and who has not accepted yet. A pending invitation is still an open access. |
| Mirror view to a dedicated workspace |
Gives a client or a contributor a workspace that contains only what concerns them, with no access to your production workspace. |
| User ID as a default value |
Limits each person to their own rows, through a view filtered on their identifier. |
3. The table: freezing the structure and the data
| Mechanism |
What it protects |
| Lock the table |
The structure: prevents the table itself from being modified. |
| Read-only rows |
Freezes specific records against any modification. |
| Secure edit mode |
Frames data entry through a secure form, rather than free editing of the table. |
| Trash |
Recovers from a row deletion. It is specific to each table. |
| Table options |
The overview of the Actions menu on the table. |
4. The view: what the person who opens it sees
This is the level used most on a daily basis. A view defines both the rows displayed (through its filters) and the fields that can be reached (through its restrictions).
5. The column: protecting one specific piece of data
| Mechanism |
What it protects |
| Encrypted field |
Encrypts the data, including on the server side. The only mechanism that protects the data itself. |
| APPLY_MASK() |
Displays only part of the value. To be combined with a restriction, otherwise it protects nothing. |
| Conditional visibility |
Displays the field only if a condition is met. |
| Conditional read-only |
Makes the field non-editable depending on a condition. Guards against mistakes, not against reading. |
| Conditional mandatory field |
Requires a field to be filled in depending on a condition. Protects the integrity of the record. |
| Field dependencies |
Shows what depends on a field before you modify or delete it. |
| Column options |
The overview of a column's menu, from which Restrict access also opens. |
6. Records and links: the leak you do not see
The level most often forgotten. A link column displays records from another table. If no view is selected on that column, from the record the user can reach data that you had carefully hidden in the view. Check link columns just as carefully as you check the columns of the view.
7. External sharing: what leaves TimeTonic
8. Technical access: API and integrations
| Mechanism |
What it protects |
| API keys and their four rights |
Write, read data, read messages, read the calendar: tick the minimum. |
| API account restricted to filtered views |
Limits what the key can see, which its rights do not do. |
| filterRowIds |
Returns only the rows of a filtered view, on the development side. |
| Revoke an access |
Sessions, API keys, share links, invitations: four distinct mechanisms. |
| Your AI keys (BYOK) |
What TimeTonic does, and does not do, with your OpenAI or Mistral keys. |
Where to start
Administrator checklist
The ten points to check on your workspaces right away.
Read more →
To choose
Encrypt, mask or restrict
The decision guide between the mechanisms.
Read more →
To answer quickly
Frequently asked questions
Short answers, grouped by topic.
Read more →