Confidentiality and collaboration are often at odds with one another. One thrives on secrecy, keeping things close to the chest, and maintaining a tight circle, while the other is made possible only by open communication and the free flow of ideas and information. By leaning into one, you risk undercutting the other.

Administering a centralized database is a highwire act – balancing between allowing useful and productive collaboration, while ensuring that sensitive and confidential information stays in the right hands, and that data is protected from unexpected changes or unwanted eyes.

When done correctly, a database can be a powerful and collaborative single source of truth. But without the right guardrails in place, an organization might find themselves freefalling into a privacy and security nightmare.
Grist is built on the idea that protecting sensitive data shouldn’t get in the way of collaboration, and that collaboration shouldn’t come at the cost of data security. Achieving this balance is possible thanks to Access Rules, which allow granular permissions on table, column, and row level.

The A-B-C(RUD)s of data security

In the simplest terms, data security is a matter of ensuring that the right people have access to the right information. Database applications are typically controlled by a set of permissions known by the acronym CRUD. CRUD permissions let database owners and administrators decide which users can (and can’t) create, read, update, and delete records in the database.

It’s a similar concept to sending somebody a read-only copy of a file, or inviting somebody to a document as an “editor” instead of a “viewer” or an “owner”. CRUD permissions control who has access to a database on a user-by-user basis, and to what extent each user can change the data inside of it.

CRUD permissions alone may be enough for collaborating in a small database, but more complex information environments require more nuance when assigning roles. A relational database often includes confidential and less sensitive data side by side, and different users need permissions to different data.

Further, structural changes in a table or document can have drastic consequences compared with changes to the data itself. If a collaborator is allowed to change the structure of a document, they could delete entire columns of data, breaking formulas and references even outside of the table they have access to. In Grist, they could also create formulas that would let them bypass restrictions on direct access to sensitive data.

Back to our balancing act – how can an organization maintain a database that gives users enough free reign to work with some data in a database while restricting other data?

In Grist, we start by adding an ‘S’.

‘S’ is for structure

Grist supplements the standard suite of CRUD permissions with a fifth type – ‘S’, for structure.

Only users with the structure permission can add or delete table columns, edit column formulas, and restructure data by reorganizing the pages and tables that make up a Grist document. Document owners can lock down the structure of a document to provide a layer of security before sharing the document with other editors.

The structure permission also protects sensitive data from being extracted via formulas. Column formulas access data for calculations without being limited by access control rules. For example, a user with structure permission could create a formula in Table A which looks up and  returns data from a confidential Table B – even if they don’t have access to Table B directly.

A user without the ‘S’ permission can still be allowed to view the output of the formulas or to make changes to data, but without being able to edit formulas and use them to extract confidential data.

In many ways, the structure permission is a “superuser” permission in Grist. By default, it is granted to editors to make for a similar experience to that of traditional spreadsheets. Removing this permission is an important first step when limiting collaborators to granular CRUD permissions.

Private tables, hidden in plain sight

What do you do if you want collaborators to access some information in your database, but hide other information?

One approach is to segregate sensitive data by keeping it in its own document or database that’s shared with a select audience. But this loses the benefits of collaborating in a single source of truth and creates extra work and risk of discrepancies if you choose to keep some data in both places.

Instead of requiring you to duplicate data, Grist lets document owners set access rules for individual tables within a document, in effect turning some into private tables. Tables have their own set of CRUD permissions that are more restrictive than those assigned at the document level, allowing you to keep sensitive information in the same document as the information you want to share.

For example, a quarterly report shared widely across an organization might be the same document that contains a table of highly confidential financial data accessible only to a select few executives.

Private tables are neither accessible nor visible to document users who haven’t been granted read access to them – hiding in plain sight, only known to those who need to know about them. Keeping confidential and less-sensitive information in the same Grist document helps organizations maintain a single source of truth and avoid duplicating data or maintaining different database versions that can fall out of sync.

Share data with the world without letting the world in

Whether your database has tens, hundreds, or thousands of records, sometimes all you need to share is information specific to one person – like updating a customer on the status of their order, providing a project status report to a client, or sharing specific records with an outside consultant.

Instead of relying on manual data exports or integrations with other tools, Grist lets you share individual records with anybody, whether or not they’re a member of your organization or a Grist user. Every record in your database can be associated with its own link key – a randomly generated, unique URL that serves as a key to unlock that record alone.

Imagine link-sharing a document with someone. Anyone with the link can open the document. If you’ve set up link key restrictions, however, opening a document may yield no information at all. Only when the URL contains an additional link key does it grant them access to a small subset of information in your document. Link keys are often used to give outside viewers read-only access to a particular record, but can also be configured to provide access to multiple related records, and even to allow edit access.

When a person visits the link key URL, the information they see is a live, dynamic record updated in real time, not a static copy frozen in the moment the key was generated. Any changes you make to that record will be visible to them as if they’re a collaborator in your document – no follow-up emails, status reports, or worries about sharing outdated information.

Collaborate with confidence – and confidentiality

The structure permission, private tables, and link keys only scratch the surface of Grist’s robust set of access rules and tools to keep your sensitive data secure. Learn more about configuring access rules for your documents in our Help Center, or take a look at our access rules webinar.