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:
- Support for all of the standard database permissions, with one key addition,
- More granular permissions that allow you to keep sensitive and less sensitive data in the same place, and
- Sharing options that let you seamlessly share individual records with anybody inside or outside of your organization
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. In a relational database, the same data can be shared and referenced across a number of tables or documents, and changes in one location can cause a ripple effect. Confidential and less sensitive data is often stored in the same database, and providing access to one location might unintentionally expose data stored elsewhere.
Structural changes in a table or document can have drastic consequences compared with changes in the data itself. An admin could assign a collaborator “update” access so that they can update a single record, but the collaborator could instead use their new role to delete entire columns of data, breaking formulas and references outside of the table they have access to.
Back to our balancing act – how can an organization maintain a database that gives users enough free reign to edit, analyze, and manipulate the data they require while placing enough restrictions on them to protect the database as a whole?
Grist solves the situation simply: 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 an extra layer of security before sharing the document with other editors.
Locking down the structure of a document can prevent editors from making changes to column formulas or tables (maliciously or accidentally) that may cause errors spilling out into other referenced tables across the database, while still granting them enough access to make necessary changes to the data.
The structure permission also helps owners protect sensitive data used in formulas. Column formulas and the data they reveal are not limited by access control rules. For example, if Table A uses column formulas to return data from a confidential Table B, a user with structure permissions in Table A could manipulate the column formulas to glean unintended confidential information from Table B – even if they don’t have access to Table B at all.
By restricting that user’s access level in Table A to something below the ‘S’ level, the user will still be able to view the intended output of the formulas and make changes to the data in Table A without being able to edit formulas and find confidential data.
Introducing the structure permission lets document owners give collaborators as much access in a document as they would have with full CRUD permissions while safeguarding the rest of their database from being affected by any changes they might make.

Private tables, hidden in plain sight
Assigning per-user permissions and locking down the structure of a document helps you prevent collaborators from accessing or editing sensitive information, but what do you do if you don’t want others to know where that information is kept – or that it exists at all?
The simplest solution is to segregate sensitive data entirely by keeping it in its own document or database that’s shared with a select audience. But maintaining separate datasets introduces its own set of challenges, like needing to manually sync changes across documents or multiplying the risk of creating discrepancies caused by data entry errors.
Instead of requiring you to duplicate data, Grist lets document owners set access rules for individual tables within a document, designating some as private tables. Private 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 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 specific access – 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 that reference your data to generate reports or readouts, Grist lets you securely 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 points to that record alone.
Sharing a link key with somebody grants 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 database, but can also be configured to provide higher levels of 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.
Because link keys point only to the row or rows from which they’re generated and are governed by specific permissions you define, they don’t reveal anything about other data, other tables, or the structure of your document or database. You can freely distribute them without worrying about compromising your data security.

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.