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.
This article helps you choose the right one, and above all to understand what each of them does not protect.
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.
Does not remove the need to restrict the fields of the shared view.
Encrypt: 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.
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.
Mask: the APPLY_MASK() formula
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.
Restrict: the fields of a view
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. These three depend on the content of the row, and are 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 ».
The field stays visible but becomes non-editable depending on a condition. To freeze data once a file has been validated. It is not a protection against reading.
Requires a field to be filled in as soon as a condition is met. It is a protection of integrity: it prevents a file from going out without the required document or reason.
Before modifying or deleting a field subject to conditions, look at Field dependencies: it shows what relies on it, formulas and conditions included.
Lock: prevent your configuration from being undone
Restricting decides what is visible. Locking decides what can be changed. A carefully applied protection is worth nothing if a user can remove a filter or display a column again: locking is what makes it last.
A perfectly restricted view can leak through its link columns. A link column displays the records of another table through a view of that table. If no view is selected on it, from the record the user reaches data that you had hidden. The setting is made link column by link column: it is not automatic.
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.
The mirror workspace: a limited workspace for the end user
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 four 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.
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.