Deleting and restoring
Runbooks, workflows, schedules, tested patch sets, event rules, states, projects, and secrets are deleted the same way.
Who can delete
#Each page keeps its own rule: admins delete these, and anyone who may build workflows may ask to delete one.
When a second person must approve
#Under Settings > Approvals and change control, Changes from the console wait for a second person decides it:
- With it set so that every change waits, a delete is a request. It shows at the top of the page's Deleted list, and stays there until another admin or approver chooses Approve the delete or Keep it. The person who asked cannot decide it, but can Withdraw it. Until it is decided, nothing changes. A workflow waiting to be deleted cannot run.
- Otherwise an admin's delete happens at once.
Restore
#What was deleted is kept, and admins bring it back from the Deleted list at the bottom of its page with Restore:
| What | Comes back |
|---|---|
| Runbook | As it was. Schedules that were paused when it was deleted stay paused until you turn them on. |
| Workflow | As it was. |
| Schedule | Turned off, so it does not run before you check it. |
| Tested patch set | As it was. |
| Event rule | As it was, and it starts acting again at once. |
| State | Saved again with the content it had, and checked like any save. |
Projects and secrets cannot be restored: a project's files go with it, and a deleted secret must really be gone. A restore never replaces something that has the same name now.
The last 500 deletes are kept.
In the audit log
#Every request, approval, refusal, withdrawal, delete, and restore is recorded, for example runbook.delete_requested, runbook.delete_approved, runbook.deleted, and runbook.restored.