Conversations permissions and states

Conversations uses two authorization layers. The workspace gate requires a current non-guest organization membership. The meeting policy then decides which records that member can read and which meeting-level actions they can perform. An organization-admin role does not bypass the second layer.

Workspace access

Organization relationship	Conversations workspace
Current member	Available.
Current administrator	Available. Administrator standing does not grant general private-meeting access, except for the strict orphan recovery below.
Guest	Not available for that organization.
Former member or no membership	Not available for that organization.

With one available workspace, Conversations selects it automatically. With more than one, the root route requires Select an organization. An explicit organization slug is accepted only when it matches an available workspace.

Meeting read access

Every row starts with current workspace access. Conversations then permits the meeting when at least one condition is true:

Read access can come from Org-visible state, a current owner, a current member attendee, or an explicit share. An administrator does not receive every private meeting.

Access basis	Result
Org-visible meeting	Every current non-guest member can open it.
Current owner	The owner can open it while they remain a current non-guest member.
Organization-member attendance	A participant row records that the person attended as a member. They can open it while currently in the organization.
Explicit share	The current non-guest recipient can open the whole meeting.
Strict administrator orphan recovery	An administrator can open it only when it has no owner and no attendee was ever an organization member. The access filter classifies this as Unassigned.
Administrator standing alone	No access to somebody else’s private meeting.
External attendance alone	No Conversations workspace or meeting access.

Attendance history is sticky, but workspace membership is live. Former attendance does not preserve meeting access without current membership. Someone who leaves the organization loses access; if they later rejoin, their recorded member attendance can grant access again. A departed attendee still prevents that meeting from being classified as a strict orphan, so another administrator does not inherit it merely because the attendee left.

Content and management authority

Viewer relationship	Meeting content actions	Visibility, shares, and deletion	Resolve access requests
Current owner	Yes	Yes	Yes
Current organization-member attendee	Yes	Yes	Yes
Explicit-share recipient only	Yes	No	No
Organization-visibility viewer only	Yes	No	No
Administrator with no other relationship	Only when the strict read-orphan rule applies	No	Only under the stranded-request fallback

Meeting content actions include star, tags, notes, Summarize, and add, extract, toggle, or delete action items. These values are shared meeting state. The explicit share grants the meeting, not a management role; the current interface does not apply its stored share level as a separate content-editor restriction.

Access-request resolution has a deliberately separate fallback when no current owner remains and no current member attendee remains. An administrator can then approve or reject without gaining transcript or summary access. This administrator fallback does not grant share, visibility, deletion, or other meeting-management authority. Nobody can resolve their own request.

Access and visibility states

Access filter classifications use first-match precedence:

Access classification	Derived condition
Yours	Viewer is the owner or recorded organization-member attendee.
Org	Meeting is Org-visible, unless Yours matched first.
Shared	An explicit share exists, unless Yours or Org matched first.
Unassigned	The strict administrator orphan-recovery condition matched.

At the reviewed revision, the meetings table prints Yours in the Access cell when it applies. Cells for Org, Shared, and Unassigned remain blank; those values are available as filters rather than visible row labels.

Visibility is independent:

Visibility	Who can open it
Private	Current owner, current member attendees, explicit-share recipients, and any strict orphan-recovery administrator.
Org-visible	Every current non-guest organization member, in addition to the more specific paths above.

Meetings begin Private. Automatic publication occurs only when at least one genuine outside attendee matches a current, non-archived CRM Entity for the organization. An attendee who has ever held any membership in that organization, including guest membership, does not qualify as that outsider. Automation can publish a private, unpinned meeting; it never automatically makes an organization-visible meeting private.

A current owner or current member attendee can select Share with org or Make private. A human Make private choice creates a manual pin, so automation cannot republish the pinned meeting. Automatic visibility can promote other eligible meetings but does not demote them. A real manual visibility change schedules one eventual email and in-app notification describing the final state for current internal recipients; backfill operations suppress those notifications.

Explicit shares and access requests

An explicit share can target only a current non-guest member of the same organization. It grants access to the whole meeting but does not transfer ownership or management authority over shares, visibility, or deletion. A genuinely new share creates an in-app notification for the recipient; updating an existing share does not create another one. Revocation removes only the share basis.

A member without meeting access receives a separate masked page. It renders the title, date, duration, participant labels, and the viewer’s request state without rendering the transcript, utterances, summary, notes, or action items. Under the narrow administrator resolution fallback, it can also render access-request management without revealing that meeting content.

Request state	Behavior
No request	Message accepts an optional message of at most 2,000 characters; Request access creates a pending request.
Pending	Access requested replaces the form. A second pending request for the same requester and meeting is refused.
Approved	Approval atomically creates an explicit share and resolves the request. Both writes succeed or neither does.
Rejected	No share is created. Your last request was declined. You can ask again. appears, and another request is permitted.

Requests do not expire and have no cooldown. Creating one sends email and an in-app notification to current member attendees and the current owner, excluding the requester. When that set is empty, current administrators receive it. Approval or rejection sends email and an in-app notification to the requester if they remain a current member.

Summary and action-item states

Surface	State and boundary
Provider summary	Krisp note_generated or a completed Granola note can supply a summary during ingestion.
No summary yet.	No current summary is stored.
Summarize	Enqueues AI work only when AI features are enabled and transcript text exists. It does not complete inline.
Generating…	The summary job is in progress.
Updated the summary	The job completed and the page reloaded the stored summary. Regeneration replaces the prior summary.
Summary failure	Could not generate a summary right now leaves the page out of the generating state.

Action-item extraction is parse-first: structured provider data, then the outline, then action-item lines in the summary. If those sources yield nothing, current production extraction adds no item; its external AI fallback is disabled. It inserts only missing items, deduplicates by provider identity or normalized text, preserves manual items, and does not reset existing Open or Done statuses.

Krisp note_generated ingestion attempts action-item extraction without making the whole meeting ingest depend on extraction success. Users can also select Extract from meeting or add a manual item. The cross-meeting Action items browser lists and permits status changes only for items whose meetings the current viewer can open.

Connection authority

Scope	Attribution	Who can create and manage it
Team-wide	Provider meetings are attributed by matched participant.	Current organization administrators.
Personal	Provider meetings are attributed to the connection owner.	The current owner of that connection.

Connection scope controls attribution only. A team-wide connection does not make its meetings Org-visible; every new meeting still begins Private and follows the meeting visibility policy.

Other organization members can see the team-wide connection’s ordinary status, but they cannot rotate its secret, reveal its secret value, disable, enable, sync, or delete it. The current team card also renders the Krisp webhook URL to ordinary workspace members. That URL remains a capability credential and must never enter documentation, captures, or support evidence. Administrator standing does not grant management of another member’s personal connection.

Provider lifecycle

Provider	Setup and ingestion	Recovery boundary
Krisp	Add team connection or Add personal connection creates a webhook endpoint and secret. Krisp must send transcript_created and note_generated with the configured secret header.	Krisp does not retry. Rotation invalidates the old secret immediately and requires re-entering both provider fields. Disable rejects deliveries. Missed meetings must be resent from Krisp History. Delete destroys the endpoint and secret.
Granola	Connect Granola verifies a Business or Enterprise API key before saving it. The first poll covers the preceding 30 days; scheduled polls then use an overlapping incremental cursor.	Sync now attempts to enqueue a poll rather than completing it. The page can show success even if job insertion failed, and an inserted poll is ignored while disabled, so enable the connection first. Delete is irreversible; reconnecting with another verified key starts a new 30-day initial window.

When a team needs both Krisp and Granola, team Krisp must be added first. The current Add team connection control disappears after any team connection exists; the team Granola form remains available after Krisp is present.

Granola polls completed notes and can process up to 20 pages of 50 notes in one run before resuming later. A transient per-note failure is retried across polls up to its internal limit. Repeated observations are idempotent. Granola does not supply speaker diarization, so no speaker utterance rows are expected from that provider.

Connection health states

State	Meaning
Active	No current health error is recorded. A successful delivery or poll returns an unhealthy connection to this state. This is not the enabled/disabled switch.
Degraded	One or two consecutive recorded health failures occurred.
Error	At least three consecutive recorded health failures occurred.

Disabling a connection does not change its health label, so a disabled connection can still display Active; the Enable or Disable lifecycle control is the enabled-state indicator. Not every failed request changes health: unauthenticated, invalid-token, oversized, rate-limited, and Granola backpressure paths can retain the prior tag, and isolated Granola note failures can coexist with an overall Active poll. A later successful recorded delivery or poll returns either unhealthy health state to Active and clears the displayed last error. A personal connection owner receives one in-app notification for each recorded transition from Active to an unhealthy state. Worsening from Degraded to Error does not create another notification, but recovery to Active resets eligibility, so a later unhealthy episode notifies again. A team-wide connection has no owner notification.

Krisp shows Last received and Granola shows Last synced, but both timestamps also advance when an attempt records a health failure. Read the health tag, enabled-state control, and expected meeting together. Treat Last error as potentially sensitive and do not copy it before review and redaction; neither timestamp is independent success proof.

Mutation and side-effect boundaries

Trigger	Durable state	Notification or asynchronous effect
Star, tags, notes, or action-item change	Shared meeting record or dependent action-item rows	No personal copy is created.
Summarize	Queued summary job; stored summary changes only on success	Live status becomes generating, completed, or failed.
New attributed meeting	New meeting and owner attribution	A genuinely new insert attempts one in-app notification to its attributed owner. Unowned or unmatched team inserts do not send it.
Share	Explicit share row	A new share creates one in-app notification.
Request access	Pending request row	Email and in-app notifications go to eligible current approvers.
Approve	Explicit share and approved request in one transaction	Email and in-app notifications go to the current requester.
Reject	Rejected request, no share	Email and in-app notifications go to the current requester.
Manual visibility change	Visibility, manual source, actor, and time	Debounced email and in-app notifications go to current internal meeting people except the actor.
Delete meeting	Infra One meeting and dependent records removed; Contacts cleanup is attempted asynchronously. The provider source remains.	Best-effort email is attempted only for other current member attendees and the current owner, excluding external, former, and share-only viewers. The action is irreversible even if cleanup or email fails.
Sync now	Granola poll enqueue attempted	The success flash proves neither job insertion nor meeting ingestion.
Rotate, disable, or delete connection	Credential or connection state changes immediately	Provider recovery remains external; no automatic Krisp retry occurs.

Meeting deletion attempts email to the current owner and active current member attendees. External attendees, departed members, and share-only viewers are excluded and are not notified.

Related pages

• Conversations
• Manage meetings and provider connections
• Troubleshoot Conversations