Private or public: what my folder choice actually changes

Folder visibility looks like a sharing preference. It is really the setting that decides what the rest of Claap can do with a recording, and the consequences show up in places that have nothing to do with sharing. Worth understanding before you organise a workspace rather than after.

A recording inherits the access rights of the folder it sits in, and the direction matters.

When a folder is public to the workspace, every recording inside it is public too, and you cannot override that on an individual recording. When a folder is private, you are free to make any individual recording inside it public and set its own sharing options.

So far so predictable. Here is the part that catches almost everyone.

Making a folder private to your workspace and turning off its public link are two separate things, and it is the public link that governs the sharing options on the recordings inside.

This is why moving a recording into a private folder does not always unlock its options. If that folder has a public link of its own switched on, the recordings inside still inherit their sharing settings from it, and the download permission stays greyed out however private the folder is to your team.

When this happens you get a short message on the setting, naming the folder it comes from and saying you cannot change it there. That message tells you which folder to go and look at, which is the useful part, but not which setting on it is responsible.

So the fix is on the folder, not the recording. Open the folder named in the message, click Share, go to Share public link, and turn it off there. The options on the recordings inside unlock straight away, and you can then enable a public link on the specific recording you want to send out, with download switched off.

Moving a recording also changes its permissions, because it takes on those of wherever it lands. Anyone holding a link to it may lose access.

This is the part that catches teams out, usually weeks later.

CRM sync. Private recordings are not synced to your CRM. No notes pushed, no deal association.

Webhooks. Private recordings do not trigger recording_added or recording_updated. An automation that was working will simply go quiet, with no error anywhere.

API and MCP. API requests do not impersonate a user, so private recordings cannot be retrieved through the API at all. The same applies to MCP search from an AI tool, which is why a colleague can be certain a recording exists while their tool insists it doesn't.

None of these produce a warning. They just stop happening, which makes the cause very hard to find after the fact.

Ask what has to happen to the recording after the call, not who should see it.

If it needs to reach your CRM, feed an automation, or be reachable by the API, it cannot be private. If it is genuinely sensitive, keep it private and accept that it stays inside Claap.

For most sales teams that means the default should be workspace visible, with private used deliberately for the exceptions. Teams that start the other way round end up debugging automations that were never going to fire.

And if you regularly send single recordings to customers, keep public links off at folder level and on at recording level. That way each link is a deliberate act with its own settings, rather than something inherited from wherever the file happened to land.

Two questions, both cheap now and expensive in six months: which folders are private, and who is allowed to change a folder's visibility. A single folder flipped to private can take a working automation down without anyone connecting the two events.