Policies module guide

This Policies module guide covers the internal policies your organization authors and maintains, not insurance policies, which belong to the Insurance module. Typical records are a code of conduct, a compliance policy, an HR policy, or an IT security policy. Each policy is a single record, tracked by title, with its own document history and its own record of which entities have adopted it.

What the Policies Module Tracks

A policy record is the anchor for everything that hangs off it: the documents that make it up, and the entities that have adopted it.

The Policy Record

Each policy carries:

• Category — the type of policy (code of conduct, compliance, HR, IT security, or another category your account defines).
• Effective date and retired date — when the policy took effect, and when it was superseded.
• Next review date and last reviewed date — the review cycle.
• Acknowledgment required (yes/no) and acknowledgment reference — whether sign-off is required, and a pointer to where that evidence lives, such as an LMS or HR system, rather than a duplicate of it.
• Notes — the reasoning behind a change, for a reviewer who wasn’t there when it was made.

Policy Status and Lifecycle

A policy’s status is derived, not set by hand. An Adopted or Restated timeline event makes it Active; a Retired event makes it Inactive. Restating a policy doesn’t overwrite the record — it adds a new document and a new timeline entry, and the status follows from there.

The Policy Document Register

Policy Document is the module’s core content type: a register of every standalone instrument under the policy, each its own row recorded by document type and effective date. The original policy is always the first, mandatory row. Amendments, restatements, and translations each get their own row after it. Custom fields on a Policy Document are Summary and Notes.

Other modules use the same document-register pattern. Legal Entities keeps Business Registration filings the same way, alongside Insurance, IP Licenses, Treasury, and Real Estate. Every version is a dated row rather than an overwritten file, so finding which document was in effect on a given date is a lookup, not a search.

The Policy Adoption Register

The Policy Adoption register records one row per group organization that has adopted or is covered by the policy, with an adoption date. Custom fields on a Policy Adoption are Adopted date and Notes.

An empty register reads as group-wide adoption. Add rows only where adoption is scoped to specific entities — not every subsidiary needs its own row unless the policy actually varies by entity.

Adding and Reviewing a Policy

Creating or editing a policy, its documents, or its adoption rows requires Editor access to the Policies module.

Creating a Policy

1. From the Policies list, click New.
2. Enter the policy’s name, category, and effective date, then click Save.
3. Open the record and add its original Policy Document row — this first entry is mandatory before any amendment or restatement.
4. Add Policy Adoption rows for any entity where adoption is scoped; leave the register empty for a group-wide policy.

Scheduling the Next Review

Set a policy’s next review date to get a reminder ahead of it. Policies ships without a pre-built workflow template, since review cadence and sign-off chains vary by account. Build your own review-and-approval workflow with the same checklist and audit-trail tools every other module uses.

Who Can Access Policies

• Viewing a policy requires access to the Policies module.
• Creating or editing a policy, its documents, or its adoption rows requires Editor access.
• Sharing follows the policy itself, not the organization or person it applies to — the same deliberate exception as Matters. Sharing a policy shares every record under it, including its Policy Document and Policy Adoption rows.

On plans with Enterprise access groups, a group-scoped person sees only policies shared with a group they belong to. Every record under those policies comes along with them.