Meeting information, exports and deletion¶
Meeting information includes the saved plan, invited people, session records, decisions, actions, recordings and transcripts. These records do not all have the same owner or lifecycle. Understanding that distinction helps a workspace administrator request the right information and helps participants understand what a removal confirmation actually covers.
Availability: this draft explains meeting information included in workspace export and deletion processing. Screen controls are still being completed, and a working request from start to finish has not been verified here. Use the workspace administration or support process available in your environment.
Separate a meeting action from a workspace request¶
| Action or result | What it concerns | What it does not establish |
|---|---|---|
| Withdraw a meeting plan | Its publication state. | That a live room ended, invitations disappeared or saved files were erased. |
| End a session | The saved session's lifecycle. | That every participant disconnected, capture stopped or existing access links were revoked. |
| Remove a meeting plan through an available plan action | That particular saved plan and the behavior of its removal operation. | Workspace-wide erasure, provider cleanup or deletion of all related activity and files. |
| Export workspace information | A coordinated request in which Meetings supplies its owned database records. | A playable copy of each recording, a complete transcript download or proof that every other service contributed. |
| Delete workspace information | A coordinated request in which Meetings removes its configured database records. | Erasure of downloaded copies, every stored object, live rooms, backups or information held by another workspace. |
Use create and manage a meeting, join and host a meeting and recordings and transcripts for the respective product actions. Do not use an ordinary meeting action as a substitute for an organization-wide information request.
Understand the Meetings export¶
The Meetings contribution includes the following categories of saved information:
| Category | Examples and interpretation |
|---|---|
| Meeting plans and invited people | Titles, scheduling and policy information, organizer and participant records. An invitation is not proof of attendance. |
| Sessions and their people | Saved session state, participant roles, admission and recorded join/leave information. These records are not a complete provider connection history. |
| Decisions, actions and follow-up | Recorded outcomes, responsibilities, follow-up and independent facilitation checks. Read the actual state and evidence; a record's presence does not mean the work is complete. |
| Saved-file descriptions | Recording/transcript metadata, ownership and storage references. A description is not the file's contents. |
| Related-work and access information | Local meeting context, membership/access, advanced-seat capacity, linked-workspace policy and storage summaries. These are local copies used by Meetings and can lag their owning systems. |
| Contribution evidence | Saved meeting evidence and the history of when it was prepared for other parts of the platform. Sharing that evidence does not prove every recipient has received and accepted it. |
The current contribution is structured data assembled from 17 Meetings database tables. It is not a human-readable meeting-minutes document. One event, meeting or person can have several related records. A reported record count therefore cannot be read as a meeting count, participant count or count of successfully delivered files.
The export reads the current saved records table by table. It does not establish one simultaneous snapshot across every Meetings table and other platform services. A meeting that changes while an export is assembled may require reconciliation. An empty category can mean there were no matching saved rows; it does not, by itself, prove there are no recordings, external copies or related information elsewhere.
Prepare an information request¶
An authorized workspace administrator should first establish the scope with the people responsible for the request. Use the supported workspace administration or support process available in the environment.
- Identify the workspace and whether the request concerns an individual meeting, the workspace's meeting records or a wider platform export/deletion.
- Identify the needed outcomes separately: saved meeting information, recordings/transcripts, related work, activity history and copies shared with other workspaces.
- Confirm who is authorized to receive the information or request removal. A meeting host role alone does not establish authority for a whole-workspace request.
- Record the request reference and the expected scope supplied by the responsible administrator or support team. Keep an existing reference when following up on an uncertain result.
- Arrange how the result will be reviewed. Information exports can contain participant and work details; use the organization's approved destination and access process.
If recordings or transcripts are required, state that explicitly. A returned file description or temporary viewing link is insufficient evidence that the actual file is included in an export. Use the saved-file guide to understand file readiness and access, while the administrator verifies the wider export's file-handling scope.
Check a deletion result carefully¶
Meetings' current workspace-deletion contribution removes records from the same 17 database tables used for its export. Within that contribution, the configured operation is deletion rather than anonymization. The local result reports deleted, anonymized and retained record counts, but these counts apply to its database operation.
There is no per-record retention or legal-hold decision in the inspected Meetings deletion path. A saved retention date on a file description does not, by itself, protect that row from this operation. Administrators must resolve applicable retention requirements through the platform's responsible governance process before interpreting this implementation as a complete retention policy.
The Meetings result does not establish removal of the underlying recording or transcript object. It also does not independently end a live provider room, revoke a previously issued access grant, erase another person's downloaded copy or remove another service's notifications, activity history and derived information. A linked workspace may hold information under its own responsibility. Whole-request completion needs the owning systems' results.
Deletion also removes Meetings' saved contribution evidence and its sharing history. The original evidence may then be unavailable for a later investigation or for sending the same information again. Agree on the required evidence and retention outcome before proceeding; do not assume a deletion receipt is also a recoverable archive.
Recover when the result is uncertain¶
| Situation | What to establish next |
|---|---|
| The request has no result yet | Keep its reference and ask which owning service is still pending or failed. Silence is not confirmation of success. |
| Meetings completed but the wider request is unfinished | Check the remaining service and file results. A local completion cannot close the whole request. |
| The export contains descriptions but no playable files | Ask whether object contents were included by the owning export process and whether the intended recipient has access. Do not repeatedly recreate recordings. |
| A later result reports zero deleted records | Reconcile the original attempt. The records may already have been removed; zero alone cannot explain the earlier outcome. |
| Saved records disappeared but a room, link or copy still works | Identify the separate provider, grant or copy owner and request the appropriate follow-up. Database deletion alone does not establish those effects. |
| Counts disagree with what a user remembers | Compare categories and request timing. Invited people, sessions, evidence rows and files are different units. |
For support, provide the workspace, request reference, approximate time, affected meeting or session, visible result and the missing outcome. Avoid sharing meeting access tokens, temporary file URLs or unnecessary participant content. An interrupted or repeated request should be reconciled by its existing identity before a new request is created.
What managers and executives can conclude¶
The implemented lifecycle contribution makes Meetings an explicit participant in workspace information handling. It does not establish a compliance certification, a guaranteed completion time or full erasure on its own. Meaningful completion reporting should distinguish database records, file contents, live-provider state and the responses of other owners.
Meeting availability also has several parts. A service can answer a status check while a particular room, file, authorization check or downstream delivery is unavailable. Judge a business outcome by the relevant completed operation and its intended result, not a general green status or the existence of a meeting record.