Choosing the right level of protection: encrypt, mask or restrict
TimeTonic offers several mechanisms for protecting a sensitive piece of data. They do not do the same thing and they do not replace one another.
The encrypted field protects from creation: it encrypts the data and stays out of exports.
This article helps you choose the right one, and above all to understand what each of them does not protect.
1. Which questions should you ask before choosing?
1
Does the data still have to be readable by someone?
If nobody in the team needs to read it day to day, and it is a secret (password, key, access code), encrypt it.
2
Does the row need to be recognised without reading the whole value?
If your colleagues have to identify the right record, but not know the complete value, mask it.
3
Is it a question of person, of situation, or of stability?
If the answer depends on who is looking, restrict the fields of the view. If it depends on the state of the row, use a condition. If what you mainly want is that nothing moves, lock it.
4
Must the data stay out of exports?
If the field holds personal data and goes into an FTP / SFTP or Metabase file, mark it Sensitive. Marking adds to the other mechanisms, it does not replace them.
Does not remove the need to restrict the fields of the shared view.
3. How do you encrypt a secret with the encrypted field?
The Encrypted field column type stores information in encrypted form, including in the database on the server side. Its content can only be read after entering a password, set when the column is created and specific to it.
It is the only mechanism in this list that protects the data itself, and not its display. Use it for anything that is a secret: passwords for external tools, API keys for third-party services, access codes. An encrypted field is also marked Sensitive from creation. It is excluded from exports that tick the GDPR checkbox.
The price of encryption. Encrypted data cannot be searched, sorted, or used in a formula or a filter. If you need to find the row by that value, this is not the right mechanism.
4. How do you mask part of a value with APPLY_MASK()?
APPLY_MASK() creates a partially hidden version of a value, in a formula column. The mask uses @ to display a character and X to hide it.
A mask on its own protects nothing. APPLY_MASK() creates an additional column; the original column still contains the full value. The mask only becomes a protection once the source column has been set to Invisible in the views concerned.
5. How do you keep personal data out of an export?
The GDPR / confidential marking option flags a field that holds personal data. It does not protect what is displayed. It decides what leaves TimeTonic in an FTP / SFTP or Metabase export.
A label set on the field
Field menu → GDPR / confidential marking → Sensitive. Only the workspace owner and administrators can set it.
An exclusion in every export
The Exclude fields marked GDPR / confidential checkbox is ticked by default. Marked fields stay out of the file, even when marked later.
Inheritance, except for formulas
A linked table column that reads a sensitive field becomes sensitive on its own. A formula does not inherit: mark it Sensitive by hand if it copies personal data.
Marking hides nothing. Every member who saw the field still sees it. To hide data, choose another mechanism on this page. The manual CSV export does not remove marked fields: exclude them one by one when you download.
This is the central mechanism. Restrictions are set view by view, in a single window that lists every field of the table and its access level. It opens from the toolbar of the view, or from the menu of a column with Restrict access.
Read / Write
The field is visible and can be modified. This is the default level.
Read only
The field stays visible but can no longer be modified from this view.
Invisible
The field disappears completely from the view. The level to use for columns that have been replaced by a masked version.
The window permanently displays the count per level, for example 28 fields in Read / Write, 1 in Read only and 34 Invisible. It is the quickest way to check that a view intended for outside use only exposes what is intended.
Remember to tick « Hide in record mode as well ». Without this box, a field made invisible in the table can reappear when the user opens the record in record mode. The column looks hidden, and it is only half hidden.
Finish with Save with the view: the restriction is stored in the configuration of the view and applies to everyone who opens it, including through an external share.
The previous mechanisms depend on the view, and therefore on who is looking. This one depends on the content of the row, and is set from the menu of the column.
Conditional visibility
The field only appears if a condition is met. Useful to display a reason field only when a status changes to « Rejected ».
8. How do you prevent your configuration from being undone?
Restricting decides what is visible. Locking decides what can be changed. Lock a restriction so that it lasts: users can no longer remove a filter or display a column again.
9. How do you control what a record shows through its link columns?
A setting worth knowing: the view of each link column. A link column displays the records of another table through a view of that table. Select a view on each link column: the record then shows only the rows and fields of that view. The setting is made column by column.
On each link column, choose the view to be used, pointing to a view that is itself filtered and restricted. It determines which rows and which columns of the linked table will be visible from the record.
Another element visible from the record: the Changes panel, which displays the old and the new value of each field, the author and the timestamp. See Change history and Personal data and technical data.
10. How do you limit an end user to a dedicated workspace?
A client, a subcontractor or an external contributor often has no reason to enter your production workspace, even with restricted views.
The mirror view answers that need: you create a workspace dedicated to that person, and you project into it only the views you have configured.
1
Prepare the view in your production workspace
Filters for the rows, Field restrictions for the columns, and view selection on each link column.
2
Lock the settings of that view
So that the recipient cannot undo the filters or display the columns again.
3
Create the workspace intended for the end user, and the mirror view
One workspace per client or per contributor, which will contain only the mirror views.
4
Invite the person to that workspace only
With the least permissive role that still lets them work. They have no access at all to the production workspace.
The most common case, that of a sensitive value the team must be able to identify without reading it in full, is handled in five steps.
1
Keep the complete value in its original column
You will need it for processing, reconciliation and documents.
2
Create a formula column with APPLY_MASK()
This is the one your colleagues will see.
3
Set the original column to Invisible
In the working views concerned, ticking Hide in record mode as well.
4
Lock the view settings
Without this step, the restriction can be undone by whoever opens the view, and the first three serve no purpose.
5
Mark the original field Sensitive
With the GDPR / confidential marking option. The full value stays out of your FTP / SFTP and Metabase exports. The APPLY_MASK() field is a formula: it stays Not sensitive and goes out with the masked value.
This pattern is the most concrete application of the privacy by design principle: expose only what is strictly necessary, from the moment the table is designed, rather than adding protection afterwards.