Safety Policies — Overview
Org and project rules that tune every safety workflow — talk cascades, walk escalation, permit behaviour, and incident close-out gates.
Safety Policies are the rules that shape how each safety workflow behaves on your project. They're found under Admin → Safety → Policies and resolve in a chain: system defaults → organization → project, so a project can override the org, and the org can override the built-in defaults.
Safety is in beta
Safety Policies are part of the Safety module, which is in beta — in production and usable, but not yet part of a versioned release of its own.
How Scopes Resolve
| Scope | Role |
|---|---|
| System defaults | The built-in starting point the form pre-fills from — not a scope you edit |
| Organization | Defaults for every project in the org |
| Project | Overrides that win for this project only |
Set once, override where needed
Set your standards at the organization level so every new project inherits them. Only override at the project level when a specific job needs different rules.
Toolbox Talk Policies
| Policy | What It Controls |
|---|---|
| Cascade Roles (in order) | The ordered roles a talk routes through (default: deliverer → Project Manager → Safety Officer) |
| Final Step Mode | Whether the last role acknowledges (confirms seen) or approves (formally signs off) |
| Allow Return | Whether reviewers can send a talk back for changes |
Safety Walk Policies
| Policy | What It Controls |
|---|---|
| Auto-Create Safety Issues | Automatically raise a safety issue when an observation above good practice is logged |
| Escalate to Incident at Severity | Auto-escalate to an incident when an observation is at or above a chosen severity (or Never) |
Permit Policies
| Policy | What It Controls |
|---|---|
| Auto-create Safety Issue on Rejection | Raise a safety issue for the requester when a permit is rejected |
| Raise a safety issue when a permit item fails | On by default. A requirement answered Fail opens a safety issue for the requester at the item's Severity if failed from the template. Off, a failed item still blocks the permit but no issue is raised and that severity is not used |
| Block Work Area Without Active Permit | Signal that an area shouldn't be worked without an active permit |
| Allow Extension | Whether a live permit's validity window can be extended (by anyone with safety update access) before it expires |
Incident Policies
| Policy | What It Controls |
|---|---|
| Require Root Cause Before Close | Require a root cause to be filled before an incident can close |
| Require Corrective Actions Before Close | Require every corrective action to be marked done before an incident can close |
Close-out gates are strict
When the incident close-out gates are on, the close button stays blocked until every requirement is met — and the outstanding items are shown. This keeps investigations from being closed prematurely.
Next Steps
- Toolbox Talks — the cascade these policies drive
- Safety Walks — issue creation and escalation
- Incidents — the close-out these gates protect
Questions
Do policy changes affect talks already under way?
A talk keeps the sign-off chain and final-step mode it had when it was logged. Everything else applies from the next action: the next return, extension, observation or incident close.
What do I type in Cascade Roles?
Role keys separated by commas, for example pm, safety_officer. They name the steps. The people with a step's role are notified when a talk reaches their step. If nobody on the project holds that role, everyone whose role can approve Safety records is notified instead.
What does Block Work Area Without Active Permit do?
Nothing yet. The setting is saved, but nothing in the app checks it, so work areas aren't blocked either way.