Create and edit policies

The policy editor is where most of the day-to-day work happens. This page walks through every field on the form, plus the things that have tripped people up before.

Opening the editor

• New policy: from the policies list, click Add Policy (top-right).
• Edit existing: from a policy’s detail view, click Edit policy (top-right). You must have the EDIT_POLICIES permission (Policy Editor, Policy Lead, or Admin).

The editor body

InPolicy uses a TipTap rich-text editor, not Markdown. The toolbar covers:

• Text formatting: bold, italic, underline
• Block type: a Paragraph dropdown that switches between paragraph and heading levels
• Lists: bulleted, numbered
• Blockquote
• Links: the link button or ⌘K / Ctrl+K

If you paste from Google Docs, Word, or a webpage, most formatting carries over. If you paste plain text, it’s inserted as a plain paragraph.

There is no Markdown syntax input — typing ## heading will not convert. Use the toolbar.

Minimum length: 10 characters of body text. Shorter bodies can’t be saved.

Maximum length: No hard cap. Very long policies (>50KB of body text) will save fine but may slow violation detection — consider splitting into multiple related policies in the same Policy Area.

Metadata fields

Title

A short, specific name. Shown everywhere a policy is referenced. If left blank on save, InPolicy auto-extracts the first sentence of the body (truncated to 80 characters) as the title. You can edit this later.

Severity (1–5)

Drives the visual treatment in the extension and analytics:

• 1–3 (Low) — yellow underline, no dismissal required
• 4–7 (Medium) — orange treatment (used by analytics; per-policy severity is 1–5)
• 8–10 (High/Critical) — red treatment, always surfaces a card

The editor itself only goes 1–5. Analytics buckets up to 10 because we left ourselves room to expand the scale later without a migration.

Confidence threshold

Controls how certain PolicyBot must be before flagging a violation. The slider goes 0–100% in 10-percent steps. Default is 80%.

• Higher (90–100%): fewer flags, near-zero false positives. Right for broad “don’t share customer data” policies.
• Lower (50–70%): more flags. Right for narrow, keyword-driven policies where you’d rather err on the side of a warning.

Policy Area

Every policy belongs to a Policy Area. Areas are managed by Policy Leads and Admins under Settings → Policy Areas. If the Area you want doesn’t exist, create it first.

Scope

Two optional dimensions that narrow which users the policy is enforced against.

Countries applicable

Use the dropdown to add countries one at a time. Each selected country appears as a chip; click × on a chip to remove it. Leaving the list empty means the policy applies to all countries — the hint text “No countries selected — policy applies to all countries” confirms this.

When at least one country is selected, enforcement is narrowed: users whose detected country matches a selected country will have the policy applied; users in other countries will not see violations from it.

Teams

An optional list of team names. Works the same way as countries — leaving it empty means all teams.

Leaving both fields blank means the policy applies to everyone on the tenant.

Effective and expiry dates

Optional. If set, the extension will only flag violations for this policy during the effective window. Outside the window, the policy remains published (searchable, viewable) but is not enforced.

Rationale

A note to other editors about why this policy exists. Only visible to users with VIEW_POLICY_RATIONALE (every editor role by default). The rationale never appears in the extension — it’s purely internal.

Tags

Free-text list. Used for filtering in the policies list and in CSV exports. Not surfaced to end users in the extension.

Enforcement level

Stored on each policy as one of three values: Fix, Warning, or Audit. The data model and downstream surfaces (the extension) honour the distinction:

• Fix — when a violation is flagged, the user sees a suggested rewrite they can apply in place.
• Warning — the user sees a card explaining the conflict, no rewrite offered. The most common default.
• Audit — the violation is logged for analytics but nothing is shown to the user. Used for silent compliance monitoring.

In the current editor, this field isn’t always exposed in the form UI; new policies default to Warning. Reach out to support if you need to set Audit on a specific policy.

Saving

The buttons differ depending on whether you’re creating a new policy or editing an existing one.

On a new policy the bottom row shows Cancel, Save as Draft, and Add Policy. Save as Draft writes the policy in DRAFT status — invisible to the Viewer role, ignored by the extension. Add Policy publishes immediately and is only enabled if you have APPROVE_POLICIES (Policy Lead or Admin); otherwise the form ends at Save as Draft.

On an existing policy the row shows Cancel, Save changes, and Save & publish. Save changes writes a new revision but keeps the current status. Save & publish writes a PUBLISHED revision and is again gated on APPROVE_POLICIES.

Publishing in either case kicks off an embedding regeneration job. The extension picks up the new policy within roughly 30 seconds.

Each save creates a new revision in history. See Revision history for how that works, and Policy lifecycle for how policies move between draft, published, and retired states.

Source document

Every policy on the detail page shows where its content came from, directly below the settings fields. The section varies by how the policy was imported:

• URL source — shows the domain of the original webpage (e.g. company.notion.site), an Open ↗ link to visit it, and the date the content was first imported. Use this to verify the policy is still current and re-import if the source has changed.
• File source — shows the original filename and the import date. The file was uploaded to InPolicy’s secure storage and is not publicly accessible.
• Pasted text — no source section appears, because there is no canonical external document.

For policies created from scratch (typed directly in the editor), no source section appears either.

Source paragraph

Directly below the Source document section, InPolicy shows a Source paragraph blockquote — the exact sentence or passage PolicyBot read from the source document when it extracted this rule.

For example, if your handbook said “Employees must not use personal email accounts to send or receive work documents”, and PolicyBot extracted a policy from that line, you’ll see that sentence quoted verbatim in the Source paragraph block.

A few things to know:

• It only appears for policies created after this feature was enabled. Policies imported before then were stored without a source paragraph and show nothing — that’s expected.
• It only appears when PolicyBot could point to a single representative passage. When a rule is synthesised from several scattered sentences with no obvious representative quote, InPolicy stores nothing rather than show a misleading snippet.
• The passage is validated programmatically. InPolicy checks that the quoted text is an exact substring of the original content before storing it. If the model paraphrases instead of quoting, the field is silently discarded.

Policy basis on violation cards

When you use the Check policy sidebar embedded in the policy editor (the panel that runs live violation detection as you draft), each violation card now includes a Policy basis section between the explanation and the suggestion.

The Policy basis block shows:

• The exact rule text from the policy that triggered the violation, as a blockquote. This is the verbatim paragraph InPolicy is enforcing — useful for confirming whether the match is legitimate or a false positive.
• View policy — a link that opens the source policy in a new tab, so you can read the full context, rationale, and any related rules.
• Source document — shown only for violations grounded in a URL-sourced policy. Links to the external source from which the policy was originally extracted. If the rule came from an uploaded file or pasted text, no source document link appears.

Who can do what

Action	Admin	Policy Lead	Policy Editor	Viewer
Create a draft	✓	✓	✓	—
Edit a draft	✓	✓	✓	—
Edit a published policy	✓	✓	✓	—
Publish / unpublish	✓	✓	—	—
Delete a policy	✓	✓	✓	—
View policy rationale	✓	✓	✓	—

Policy Editors can edit drafts and published policies but cannot change publish status — a Lead or Admin has to flip that switch.

Gotchas

• The confidence slider is shown as a percentage in the UI but stored under the hood as a 0.0–1.0 decimal. Don’t be alarmed if a CSV export says 0.8 for a policy whose UI showed 80% — same thing.
• Editing a published policy keeps it published. There’s no “unpublish and re-review” flow.
• Embeddings regenerate on every publish. Rapid publish/edit/publish cycles may briefly cause the extension to miss violations while the new embedding is in flight.
• Auto-extracted titles can be awkward. If you let InPolicy generate a title from a body that starts with “Introduction.” or “Overview.”, that becomes the title. Set one manually for anything important.
• Pasted rich text can carry over color styles you don’t want. The easiest cleanup: select all → click the Clear formatting button (eraser icon) → re-bold anything you wanted bold.