What Deleting a Scene, Shot, or Take Removes

Deletion inside a project does not have one single meaning. Along the episode, scene, shot, and take hierarchy, deletion is cascading: when a parent record is removed, downstream records under it enter the deletion scope; a shooting day behaves differently, because deleting the day only removes scheduling ownership, while the scenes and takes remain in the project and are no longer attached to that day.

To understand a deletion, first determine whether it sits in the “episode → scene → shot → take” hierarchy or in the separate shooting-day scheduling relationship.

Which levels carry deletion downstream

Deleting an episode carries its scenes, deleting a scene carries its shots, deleting a shot carries its takes, and deleting a take carries the camera snapshots and continuity media attached under that take. Continuity media attached directly to the shot also enters the shot’s deletion scope, and deleting a scene also removes the script-body items belonging to that scene.

A shooting day does not delete downward through that hierarchy. When a shooting day is deleted, the scenes and takes that were scheduled there only lose their ownership by that day and remain in the project; the confirmation text says that deletion will remove the scheduling association for scenes linked to that shooting day and that the action cannot be undone. That prompt describes the scheduling relationship and should not be expanded into a claim that the scene records themselves are also deleted.

Moving a scene to another day requires unscheduling first

A scene can belong to only one shooting day at a time, so moving it to another day requires removing the existing day relationship before scheduling it onto the target day. This article uses that constraint only to explain why deleting a shooting day means removing ownership rather than deleting the scene; the scheduling workflow itself should be checked against the current interface.

After deletion, the interface does not present an Undo entry, and the record does not move into a user-facing recovery location. “Cannot be undone” here describes the record operation itself and should not be extended into a prediction about what every related file must do, because database records and media files on the device follow a separate cleanup step.

Record deletion and file cleanup are two steps

When episodes, scenes, shots, or takes go through the full deletion sequence, the process first freezes a list of file paths to be handled, then marks the records for deletion, commits the record changes, and processes files from that frozen list. If an earlier step fails, the record change is rolled back and the pending list remains for a later retry; project-level deletion has its own commit phases, and when the database has already committed but file cleanup is incomplete, a later launch can continue from that committed fact.

Shooting-day deletion does not enter this file-cleanup path, so deleting a shooting day does not by itself establish what happened to files on disk. The reverse is also important: when record deletion uses the cleanup sequence, it should not be simplified into “the record disappears and every related file disappears at the same instant”; whether a file remains on the device should be checked against the actual project directory.

The receiver should verify whether deletion at this level cascades into downstream records and should check the actual project directory for the state of related files on the device.

Check the hierarchy before deleting, not the appearance of the button

Before removing a mistakenly created scene, inspect the shots, takes, and continuity evidence under that scene to see what the record actually carries. If the goal is only to remove one day from the schedule, read the action as removing shooting-day ownership; project-level deletion is a separate axis described in What Sign-Out, Account Deletion, and Project Deletion Actually Remove, and should not be merged with deletion inside the project hierarchy.

Before deletion, also confirm that the target record is not being used by another person as a current work reference at the same time. This article does not decide which records the crew should preserve; it describes the structure that can be checked after the action, and the receiver or operator should independently confirm whether the selected action is cascading deletion or only removal of scheduling ownership.

FAQ

What downstream records enter scope when a scene is deleted?

The scene’s shots, the takes under those shots, related camera snapshots and continuity media, and the script-body items belonging to that scene enter the cascading deletion scope.

Does deleting a shooting day delete the scenes scheduled on it?

Deleting a shooting day only removes the day relationship from those scenes and takes, which remain in the project; the confirmation text describes removal of scheduling associations.

Can a completed deletion be restored from an Undo entry?

After deletion, the interface does not provide an Undo entry or a user-facing recovery location; the record operation and the state of files on the device should be checked separately.

What state are media files guaranteed to be in after record deletion?

Do not conclude from the record state alone; the full deletion sequence processes files from a frozen list, but the receiver should still verify the file state in the actual project directory.

Axiom One LLC — SlateX. Figures current as of 24 September 2026.