Trash (deleted records)
It is possible to access previously deleted records in the "Trash" section. Ended executions are automatically moved to the trash after a configurable timeout and are subsequently permanently deleted after another configurable timeout.
Unless configured otherwise, ended executions are moved to the trash after two weeks by default. Trashed executions will remain in the trash for another two weeks before being permanently deleted from the Engine database.
Trashing and deleting are done asynchronously. Therefore, records may still exist after being deleted.
Configuration
This behavior can be configured using the Workspace Configuration. Please refer to Trash for configuration options.
Moving records to trash
Moving a project to trash will also trash all records of that project.
Via the User-Interface
Moving individual records to trash
Open the record and click on "Move to trash" in the "More Actions" popover.
The "Move to Trash" action in the "More Actions" popover
When a record is moved to trash it gets a "Pending Move to Trash" badge. If the trashing operation is succesful the badge is updated to "In Trash". When the move to trash fails, a log entry is created on the record and it stays in the "Pending Move to Trash" status.
The "Pending Move to Trash" badge
The "In Trash" badge
Records in trash cannot be modified and all actions are disabled, except "Delete permanently" and "Restore".
Move to trash as bulk action
Open the workspace dashboard, project dashboard, or execution live monitor. In the resources list check the records and click on "Move to trash" in the "More Actions" popover.
The bulk-move-to-trash action in the more actions popover
The records will be moved to the "Trash" section.
Via the Flow-API
Use the delete method on any record.
Moving a setting to trash.
import flow_api
def handler(system: flow_api.System, this: flow_api.Execution, inputs: dict):
system.setting('the-setting').delete()
return this.success('all done')
Via the REST-API
Make a HTTP DELETE request.
Trash a setting
curl -X DELETE https://your-workspace-name.cloudomation.com/api/latest/setting/the-setting?by=name
Permanently deleting records
Permanently deleting a record is permanent. The record cannot be restored afterwards!
Permanently deleting a project will also permanently delete all records of that project.
Via the User-Interface
Permanently deleting individual records
Open the record and click "Delete Permanently" in the "More Actions" popover. This action moves the record to the Pending Delete state, and it will be permanently deleted once the operation completes successfully.
The delete permanently action in the more actions popover
During the permanent delete operation a "Pending Delete" badge will be displayed
Pending delete badge
Permanently delete multiple records as a bulk action
Open the workspace dashboard, project dashboard, advanced search or execution live monitor. In the resoures list, check the records and click on "Delete Permanently" in the "More Actions" popover.
The bulk-delete-permanently action in the more actions popover
Via the Flow-API
Use the delete method with the permanently=True argument on any record.
Permanently delete a setting.
import flow_api
def handler(system: flow_api.System, this: flow_api.Execution, inputs: dict):
system.setting('the-setting').delete(permanently=True)
return this.success('all done')
Via the REST-API
Make a HTTP DELETE request.
Permanently delete a setting
curl -X DELETE https://your-workspace-name.cloudomation.com/api/latest/setting/the-setting?by=name\&permanently=true
Accessing records in trash
Via the User-Interface
List records in trash
All types of records, except executions, that have been moved to the trash can be accessed by navigating to the Trash section located at the bottom of the left-hand navigation panel or by using the Advanced search feature, which allows filtering for trashed records. For more details, refer to Advanced Search.
The Advanced search supports searching and filtering for all types of records in the trash and allows you to apply bulk actions to them.
Trashed executions are currently not shown in the Trash section. They can only be accessed by using the "Show in trash" filter via the execution live monitor or the advanced search.
List executions in trash
Using the execution live monitor
It is possible to access trashed executions in the Execution live monitor, using the "Show in trash" filter.
Execution live monitor show in trash filter
Using the advanced search
Additionally, trashed executions can be accessed from the Executions tab under the Advanced search using the "Show in trash" filter.
Advanced search show in trash filter
Via the Flow-API
List records in trash
Listing methods can be configured to access records in trash. To include records in trash in the listing the allow_deleted argument must be set to True.
List all settings in Trash.
import flow_api
def handler(system: flow_api.System, this: flow_api.Execution, inputs: dict):
for setting in system.settings(
# do not include "Normal" (not deleted) records in the lising
allow_normal=False,
allow_deleted=True,
):
this.log(setting.get_dict('name', 'deleted_at'))
return this.success('all done')
Access individual records in trash
Individual records in trash can be accessed using the Flow-API. The allow_deleted argument must be set to True.
Read value of a setting in trash.
import flow_api
def handler(system: flow_api.System, this: flow_api.Execution, inputs: dict):
value = system.setting(
'the-deleted-setting',
allow_deleted=True,
).get('value')
this.log(value=value)
return this.success('all done')
Attempting to access trashed records without the allow_deleted flag will result in a PermissionDeniedError:
Traceback (most recent call last):
File "example-read-deleted-with-permission-error (4c886cf9-61cc-41ab-b3a2-c6fdad5a334c)", line 4, in handler
flow_api.exceptions.PermissionDenied: {"operation": "read", "by": "name", "ids": ["the-deleted-setting"], "table": "setting", "message": "No permission to read setting in project 239dface-c437-488f-9390-42c70483c3b6 with name(s) {'the-deleted-setting'}: Cannot access deleted record without `allow_deleted` flag.", "reason": "Cannot access deleted record without `allow_deleted` flag."}
Via the REST-API
List records in trash
Use the allow_deleted flag with any listing request.
List only settings in trash.
curl https://your-workspace-name.cloudomation.com/api/latest/setting?allow_normal=false\&allow_deleted=true
Please refer to Accessing and Manipulating Records for details on how to use the REST API.
Access records in trash
Use the allow_deleted flag.
Access a setting in trash.
curl https://your-workspace-name.cloudomation.com/api/latest/setting/the-deleted-setting?by=name\&allow_deleted=true
Restoring records
Restoring a project also restores all records associated with it.
Via the User-Interface
Restoring individual records
Open a record from the "Trash" section and click on "Restore" in the "More Actions" popover.
The restore action in the more actions popover
The record will first move to the Pending Restore state and, once the operation completes successfully, it will be restored and returned to its associated project.
Restore records as bulk action
Open the "Trash" section. In the list check the records and click on "Restore".
The bulk-restore action
The records will be restored and moved to the projects they are associated with.
Via the Flow-API
Use the restore method on any record.
To be able to access a record which is in trash the allow_deleted argument must be used.
Restore a setting.
import flow_api
def handler(system: flow_api.System, this: flow_api.Execution, inputs: dict):
system.setting('the-deleted-setting', allow_deleted=True).restore()
return this.success('all done')
Via the REST-API
Make a HTTP PATCH request to restore.
Restore a setting
curl -X PATCH https://your-workspace-name.cloudomation.com/api/latest/setting/the-deleted-setting/restore?by=name\&allow_deleted=true
Trash behavior and retention
Automatic trashing of executions
Executions are automatically moved to the trash after a configurable expiry period. This setting can be adjusted in the workspace settings. By default, executions are moved to the trash 2 weeks after their creation or completion. This period can be customized using the Workspace Configuration. Please refer to TRASH_ACTIVITY_EXPIRY_TIME_MINUTES option in Trash for configuration.
Permanent deletion of trashed records
All records placed in the trash (including executions and other types) are permanently deleted after a configurable expiry period. Once the default period of 2 weeks ends, deletion is irreversible. This retention period can also be customized using Workspace Configuration. Please refer to TRASH_RETENTION_TIME_RESOURCES_MINUTES and TRASH_RETENTION_TIME_ACTIVITIES_MINUTES options in Trash for configuration.
Capabilities and limitation of trashed records
- Records that have been moved to the trash are read-only.
- They can still be read and referenced by other components. For example, a setting or file in trash can still be accessed by an execution by setting the
allow_deletedargument to True. - However, trashed records cannot be edited.
- Flows in the trash can not be executed.
Asynchronous behavior
Moving records to the trash or deleting them permanently are both asynchronous operations. This means the record may continue to exist temporarily even after the action has been triggered or the method has returned.
Move to trash
- When a record is moved to the trash, it receives a "Pending Move to Trash" badge.
- Once the move is successful, this badge is updated to "In trash".
- If the move fails, a log entry is added to the record, and the record remains in the "Pending Move to Trash" state. System automatically retries move to trash once in a minute by default. This period can be configured using Workspace Configuration. Please refer to
BACKGROUND_TRASH_INTERVAL_MINUTESoption in Trash for configuration. - In the case of failure, manual retry is also possible via "Move to Trash" button.
- Records that are moved to trash are permanently deleted after a configurable time out that is 2 weeks in default. This behavior can be customized using Workspace Configuration. Depending on the category of your record please refer to
TRASH_RETENTION_TIME_RESOURCES_MINUTESorTRASH_RETENTION_TIME_ACTIVITIES_MINUTESoptions in Trash for configuration.
Permanent delete
- When a record is scheduled for permanent deletion, it receives a "Pending Delete" badge.
- If deletion fails, a log entry is added to the record and the record remains in "Pending Delete" state. System automatically retries deletion once in a minute by default. This period can be configured using Workspace Configuration. Please refer to
BACKGROUND_DELETE_INTERVAL_MINUTESoption in Trash for configuration. - In the case of failure, manual retry is also possible via "Delete Permanantly" button.
Pending states
- A record marked as "Pending Move to Trash" remains in its original state. It can be viewed, edited, and used just like any other active record.
- A record marked as "Pending Delete" also remains accessible until the deletion operation completes.
- In both cases, the record's functionality is not restricted until the operation finishes successfully.
- Both "Pending Move to Trash" and "Pending Delete" states can be cleared, which cancels the scheduled operation.
- Clearing these states prevents the record from being trashed or deleted.
The "Clear Delete" action
Accessing failed trashing and deletion operation logs
When an attempt to move a record to the trash fails, the system logs the failure on the record and leaves it in the "Pending Move to Trash" state. This status indicates the operation did not complete and may require manual retry.
Similarly, if a record fails to be permanently deleted, a log entry is created on the record to capture the failure. The record will remain in the "Pending Delete" state unless the operation is retried or cleared.
In both cases, the log entries can be viewed in the Workspace Logs.This helps in troubleshooting and allows users to take corrective actions.
Workspace logs showing a failed permanent delete operation