Who Should Be Able to Search Your Team's Meeting Notes

The permission question always arrives late

A team buys a meeting notes tool for one reason. Somebody got tired of reconstructing what was decided. Nobody asks who should be able to read the archive during that purchase, because on day one there is no archive to read.

The question shows up around month four. The archive is finally big enough that searching it beats asking a person, someone searches it, and they land on a conversation they were not part of. Sometimes that is fine. Sometimes it is a compensation discussion, or a manager working through a performance problem out loud, or two founders arguing about whether to fire a customer.

By then the decision is much harder than it needed to be. Hundreds of meetings are already captured under an assumption nobody stated. Whatever rule gets written now applies backwards to conversations that happened under a different understanding, and none of the people in those rooms were asked.

Two ways to get this wrong, neither of which looks wrong

Open by default is where most teams start, usually because it matches how they already treat docs. Every captured meeting is readable by everyone in the workspace. On paper the archive stays complete and the search results stay useful.

What actually happens is that the sensitive part of the conversation relocates. It moves to a direct message, a walk, a call nobody captures. The archive stays complete in the sense that every meeting is in it, and gets steadily thinner in the sense that the meetings stop containing the real discussion. You cannot notice this by looking, because there is no way to search for a sentence that was never said.

Locked down by default with a request process is the other version. Access exists, it just has to be asked for. In practice almost nobody asks. Filing a request and waiting a day is slower than pinging the person who probably knows, so the question lands on whoever has been there longest and answers fastest. That puts the team back in the interruption pattern the tool was supposed to reduce.

Both failure modes look healthy from an admin view. The first shows rising usage. The second shows almost no access complaints. Neither number is measuring the thing that broke.

The decision belongs at capture, not at retrieval

The person sitting in a meeting knows what kind of meeting it is. They know whether they are running a weekly project sync or telling a colleague their role is being restructured. That knowledge is available for free, in the room, at the moment of capture.

A search index six months later knows none of it. It has a transcript, a date, and a list of attendees. Any classification you try to apply at that point is a guess made by someone who was not there, usually under time pressure, usually while trying to answer a different question.

So put the boundary where the knowledge is. Give every recurring meeting on the calendar a tier before it is ever captured, and make the tier a property of the meeting series rather than of each note it produces. A weekly engineering sync is shared with the team, permanently, and nobody has to decide again each week. A monthly comp review is restricted, permanently, for the same reason.

One-off meetings need a default too, and the honest default is the narrower one. A meeting that does not belong to a series is the one most likely to be unusual, and unusual is the case where a wrong guess costs the most.

Why per-note sharing stops working around the time it starts mattering

The obvious model is to share each note with the people who should see it. It works beautifully for the first fifty notes and then quietly stops.

NIST's work on role-based access control names the reason. The model became predominant, in NIST's framing, because it reduces the cost of security administration in large networks: each user is assigned one or more roles, and each role is assigned one or more privileges permitted to users in that role. Administration then becomes a question of working out which operations people in particular jobs need to perform, and putting employees in the right roles.

A meeting archive is a bad fit for per-object permissions specifically because it never stops growing. Every week adds more objects, each needing a decision, and the decisions are made by whoever created the note rather than by whoever owns the policy. Six months in, the effective access rules of the archive are the accumulated improvisation of everyone who ever clicked share, and no single person can describe them.

Roles are bounded by headcount and job function, which change slowly. That is the whole advantage. The set of things you have to keep in your head stays roughly the same size while the archive grows without limit.

Closed by default, and simple enough that people actually follow it

Saltzer and Schroeder wrote down the design principles for this in 1975, and three of them apply almost directly to a meeting archive.

Fail-safe defaults: "Base access decisions on permission rather than exclusion." The default is no access, and access is granted, rather than the default being access with exceptions carved out. Applied here, a captured meeting is private until something explicitly makes it shared, so a meeting nobody classified fails closed instead of failing open.

Least privilege: "Every program and every user of the system should operate using the least set of privileges necessary to complete the job." A support lead needs the customer calls for the accounts they cover and has no particular need for the fundraising ones. Reaching that conclusion requires no argument about trust, which is worth saying out loud, because access conversations tend to get read as trust conversations and then get avoided for the wrong reason.

The third one is where meeting archives usually fail. Psychological acceptability: "It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly." A permission model people cannot apply without stopping to think gets applied wrong, and gets bypassed silently by people who assume they are being careful.

There is a cheap test for this. Ask someone in the middle of a meeting who will be able to read this later. If they can answer immediately, without opening a settings page, the model is workable. If they have to check, it will be routed around, and you will not find out for months.

Four cases worth settling before they happen

Someone joins. Do they get retroactive search across everything the team ever captured? A new person handed six months of history gets to read conversations that happened when the room was smaller and people spoke accordingly. Scope it by relevance to the work rather than by seniority or tenure, and decide it before their first day.

Someone leaves. Their private notes are usually the only record of a set of conversations, and the moment they are gone is the moment somebody needs one. Decide in advance whether those notes transfer to a manager, transfer to a successor, or are deleted, and tell people the rule while they still work there rather than after they hand in notice.

A manager asks for a direct report's notes. This one is worth a written answer because it will be asked eventually, usually with a reasonable justification attached. The defensible position is that private notes stay private and shared material is shared, so that the boundary does not move based on who is asking.

A dispute or investigation. Say plainly who can authorise an exception, and that any exception is recorded. An access model with no exception path gets broken under pressure, and a broken model teaches everyone that the rules are advisory.

What to ask a vendor before you buy

Most evaluations of a meeting notes tool test capture quality and search quality, which are the things a demo shows well. Access behaviour is harder to see in a demo and much harder to change after a year of use, so it is worth a set of direct questions.

Is a new note private or shared by default? Can a workspace admin read a note the author never shared? Is sharing done per note, per folder, or per meeting series? What happens to a person's notes when their account is removed? Is there any record of who opened what? And when an account is deleted, what is actually deleted and how long does it take?

The answers matter less than whether the vendor can give them without checking. A product that has thought about access control will answer these quickly, because the answers are design decisions somebody made deliberately. A product that has not will describe a roadmap.

Where Driffle sits, and what it leaves to you

Driffle's default is private. Your notes are visible only to you until you explicitly share them, and workspace admins do not see private notes, only what has been shared into shared folders. That is the fail-safe direction, so an unclassified meeting stays with the person who captured it rather than landing in a company-wide index.

Nothing runs on its own. Driffle does not auto-join meetings, does not auto-record, and does not run in the background, so a meeting enters the archive because somebody chose to put it there. Audio is transcribed in real time and discarded, and the text is what is retained. Individual notes can be removed immediately, and full account deletion clears the data within thirty days, backups included.

What the product does not do is decide your boundaries. It cannot tell you which meeting series should be shared with the team, who resolves an ambiguous case, or what should happen to a leaver's notes. Those are policy calls, and a good default is a starting point for them rather than a replacement.

Two limits worth stating plainly. Capturing quietly, with no bot in the call and no notification going out to other participants, does not remove any obligation to be clear with people about what is being recorded. And none of the above is a security certification or legal advice about your own recordkeeping duties.

How to tell whether the boundary is holding

Ask three or four people to state the access rule from memory. If they give you three or four different answers, the model has already failed the acceptability test and the archive is being managed by guesswork.

Look for shared folders nobody has opened in two months. That is usually a sign of over-sharing rather than under-use: material got pushed into a shared space because sharing was the path of least resistance, and now the shared space is mostly noise that nobody trusts enough to search.

Watch for questions that the archive already answers still landing on people. When someone asks a colleague something the shared record holds, either they did not know they could search for it or they did not have access. Both are worth chasing, and the second one is the one that will not surface on its own.

The goal here is an archive people are still willing to talk honestly in front of. A record of guarded conversations is worth less than no record at all, which is why the tighter model is not automatically the safer one.