How to build an employee handbook in Confluence

What to include in an employee handbook in Confluence

An employee handbook in Confluence works well for the same reason a wiki does: everyone can find it, it links to everything else you already keep there, and updating a page is quicker than reissuing a PDF. The risk is the same too: without structure and owners, it fills up with pages nobody trusts.

Start with the content. Most company handbooks cover four broad areas. Treat the list below as a starting point, not a legal checklist: employment rules differ by country, state and sometimes city, so have anything about pay, leave, working time or termination checked by someone who knows the law where your people work.

Keep each page short and practical. Answer "what do I do?" in the first paragraph. Where a contract or a provider's documents govern a benefit, summarize it and link to the authoritative version.

Structure the company handbook in Confluence as a page tree

Confluence organizes pages in a space as a tree: every page can have child pages, the tree shows in the space sidebar, and you can drag pages to reorder them or move a page (with all its children) under a new parent. Use that hierarchy for the handbook instead of one long page.

A dedicated handbook space usually works best. It gets its own front door, blog and permissions, and team notes don't drift in. An example tree:

• Employee Handbook (the space overview)
  • Start here: your first week
  • About us: mission, values, how we're organized
  • How we work: hours, remote work, meetings, tools, expenses
  • Time off and benefits: holidays, sick leave, parental leave, benefits
  • Conduct and security: code of conduct, acceptable use, security basics, reporting concerns
  • Handbook change log

Two levels is usually enough. A section that needs a third is probably a separate guide.

For a consistent look, a space admin can create a space template for handbook pages, for example with headings for "Summary", "Details", "Who to ask" and "Last reviewed", plus placeholder text that only shows while editing. Templates can also add labels automatically, which helps with the next step. Only space admins can create or edit templates.

Make the HR handbook wiki findable

People don't browse a handbook. They search for the one thing they need. Make that easy:

• Use the space overview as the front door. Every space has an overview page, the first page people see. Say in one or two sentences what the handbook is and who keeps it current, link to the main sections and the most-asked pages, and consider the Live Search macro to put a search box right there.
• Title pages the way people search. "Parental leave" beats "Section 3.4: Family" or "Policy LV-02". Confluence search can be limited to page titles, so a plain, specific title is often the fastest way in.
• Add labels. Labels are lowercase with no spaces (for example time-off, benefits, onboarding). Advanced search can filter by label, and the Filter by label macro lets you build a list of labeled pages on the overview.
• Search within the handbook. Advanced search can be narrowed to one space, or to pages under a given page.

Give every handbook section an owner

A handbook goes stale when everyone can edit it and nobody is responsible for it. Name an owner for each section, a person rather than a team, and write the name on the section's top page.

Confluence Cloud helps here: each page has an owner, shown in the byline under the title. The creator is the owner by default, and ownership can be transferred to someone who has access to the space and can edit the page. Transfer pages to their section owners so the byline tells readers who to ask.

Then decide who can edit. On Confluence Standard and above, you can set space permissions and restrict individual pages, so the handbook can be readable by everyone and editable by its owners. On Confluence Free, permissions can't be customized and everyone who can log in can edit everything, so ownership there is a convention rather than a control.

Keep it current with a review cadence

Pick a review cadence per section and put the next review date on the page. A reasonable default:

• Every year: values, how we work, code of conduct, acceptable use and security pages.
• When the plan or provider changes, and at least yearly: benefits and time off.
• Every time you hire: the "Start here" page. Ask each new joiner what was missing.

Confluence keeps every version of a page. Version history lets you compare two versions side by side and restore an older one, which creates a new version rather than deleting anything. That makes edits low-risk, but nothing tells owners a review is due, so put the dates in their calendars or a shared tracker.

When a page is no longer true, archive it rather than leaving it in the tree. Archived pages leave the page tree and quick search, and links to them still work with an "Archived" badge.

Tell people when something changes

A quiet edit is fine for a typo. A change people need to act on, such as a new leave rule, needs announcing.

• Post on the space blog. Confluence blog posts sit outside the page tree, ordered by date, which suits announcements. People can choose to watch new blog posts in a space from its overview page and get a notification for each new post.
• Keep a change log page. One page with a table of date, page, what changed and what people need to do.
• Say what to do. "The home office allowance is now paid quarterly; submit receipts by the 5th of the following month" is better than "updated the remote work page".

Onboard new joiners with the handbook

The handbook earns its keep in someone's first week. Make the "Start here" page a short reading path rather than a link to the whole tree:

1. Day one: welcome, values, who's who, tools and accounts.
2. First week: how we work, time off and benefits, expenses.
3. Before they get access to production systems or customer data: code of conduct, acceptable use and security basics.

For the practical steps, give each new hire an onboarding checklist page made from a template. Confluence tasks can be assigned with an @mention and given a due date, and the assignee is notified, so the manager, IT and the new joiner each see their own items.

Which handbook sections are really policies

Most of a handbook is information: how to book leave, where the expense tool is. A few sections are different. The code of conduct, the acceptable use rules and the security expectations are commitments every employee has to accept, and you may need to prove they did. If you're preparing for a SOC 2 audit, the auditor will typically ask for exactly that: who accepted which version of these policies, and when. See which SOC 2 policies you need for the full set.

Those sections need more than a wiki page:

• an owner and an approval of each version before it applies;
• a record that each person accepted a specific version, not just that they opened the page;
• a fresh round of acceptance when a change matters, but not for a typo fix;
• new joiners asked automatically, with reminders for anyone outstanding.

Page views, likes and comments don't give you that record: Confluence read confirmation explains why, and policy acknowledgement tracking covers what auditors look for.

Handling the policy sections with Compliance in a Box

Compliance in a Box is a Confluence Cloud app that runs a compliance program in one Confluence space it creates. Your handbook stays ordinary Confluence pages in its own space. The app takes over only the parts that have to be policies.

Policies with owners, approvals and reviews

The SOC 2 policy set the app provides includes a Code of Conduct, an Acceptable Use Policy and an Information Security Policy, each with employee acknowledgement switched on. Every policy has an owner and one to ten approvers, set under Settings, Owners & approvers. Each new version is approved against the exact Confluence page version, and the page is locked so only its owner and Compliance Admins can edit it. Policies come up for review yearly. See assigning owners and approvers.

Bring your handbook text in

If your handbook already has a code of conduct or acceptable use page, a Compliance Admin can copy its text into the matching policy with the import wizard. For a section the framework has no template for, such as a remote work policy, map the page to New custom policy. The Employees must acknowledge it once approved option is ticked by default. The source page is never changed, and imported text is a new, unapproved version: the owner reviews it and clicks Submit for approval as usual. The wizard warns about content that won't copy cleanly, such as attachments and macros that pull in other pages. See custom policies.

Once a section lives as a managed policy, replace the handbook copy with a short summary and a link to the policy page, so there is only one text to keep current.

Click-through acknowledgements, including new joiners

When a policy is approved, everyone in its audience (all employees by default, or specific groups) is asked to acknowledge it within 30 days, from My Tasks or from the policy page itself. Each acknowledgement records the person, the approved version and the time. Owners decide whether a new version is a Material change; only material changes ask people again. Once a day the app picks up joiners, such as new hires added to your employee groups, and asks them to acknowledge the current version, due 30 days from that day. With reminders switched on (the default), reminders arrive as Confluence tasks, so people get Confluence's own notifications. See people who join or leave the audience.

FAQ

Should the employee handbook have its own Confluence space?

Usually, yes. A dedicated space gives it its own overview page, blog, permissions and search scope. A section of a general company space works for a very small team but gets crowded as you grow.

Do employees need to sign the handbook?

It depends on where you operate and what the handbook says, so ask local counsel about the employment parts. For the policy sections, many companies use a click-through acknowledgement that records the person, the version and the date. SOC 2 itself doesn't require a signature, but your auditor decides what evidence they accept.

How often should an employee handbook be updated?

Review each section at least once a year, update benefits pages when a plan changes, and refresh the onboarding pages whenever someone new points out a gap. Record each change people need to know about in a change log.

← All articles