Policies
Rules your company intends to hold to, written as subject, condition, and expectation — recorded, not enforced.
A policy is a rule you intend to hold to, written down in a shape something can reason about later.
Recorded, not enforced
Read this first: a policy here does not enforce anything. Nothing blocks a quote, stops a send, or fires an alert because a policy exists. It is a governance record — the written statement of intent, and the thing an auditor or a future agent can point at.
If you need a rule that actually gates behavior, that's automations and workflows, not this page.
The rule shape
A policy needs a name, a status, and all three parts of its rule:
- Rule subject — what the rule is about, e.g.
quote. - Rule condition — when it applies, e.g.
discount > 20%. - Rule expectation — what should happen, e.g.
Manager approval before customer send.
Splitting it into three parts rather than one sentence is what makes the rule comparable across policies and readable by something other than a person.
An owner is optional here, unlike on risks — a policy with none shows as Unowned in the list. Set one anyway when the rule belongs to someone in particular.
Three statuses
- Draft — being written, not yet in force.
- Active — the rule you intend to hold to.
- Archived — no longer guiding intended state.
Archiving is the terminal action, from Archive policy on the detail page. There is no delete: an archived policy stays on the record, which is the point of writing it down. The landing page counts only active policies.
Fields that take JSON
Affected entities and external references on this form are entered as
raw JSON arrays, following the placeholder shown in the field — for
example [{"entityType":"account","entityId":"acct-1"}]. Both are
optional. If the form rejects what you typed, it's the JSON, not the
content.