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 New Policy (top-right).
Edit existing: from a policy’s detail view, click Edit (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, the Mac app, 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

Three optional dimensions:

Audience — which employee groups this policy applies to
Countries — list of country codes (ISO-3166 alpha-2). Blank = all countries.
Teams — list of team names (free-text array).

Leaving all three blank means the policy applies to everyone on the tenant.

Effective and expiry dates

Optional. If set, the extension and Mac app 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 or the Mac app — it’s purely internal.

Enforcement level

Stored on each policy as one of three values: Fix, Warning, or Audit. The data model and downstream surfaces (extension, Mac app) 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 User role, ignored by the extension and Mac app. 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 and Mac app pick 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.

Who can do what

Action	Admin	Policy Lead	Policy Editor	User
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.