Employment History & Compensation

Introduction

Every employee profile in Brainy HR keeps a record of how their role and pay have changed over time. This lives in two places on the profile: the Employment History tab (position, department, office, level, manager, employment status and probation changes) and the Compensation tab (salary history). Both are sensitive, so both are controlled by a scope-based permission model — you decide who can see their own record, their team's records, or everyone's. This guide explains how each history is built, how to work with it, and exactly who can see what.

Table of contents

1. Overview — two histories on every profile
2. Employment History — what it records
3. How an Employment History entry is created
4. Reading the Employment History tab
5. Compensation — salary history
6. Adding, editing and deleting salary records
7. How "current salary" is determined
8. Permissions & visibility — the scope model
9. What employees see on their own profile
10. Frequently asked questions

1. Overview — two histories on every profile

Brainy HR tracks an employee's working life along two independent timelines:

• Employment History — a chronological log of changes to the job itself: position, department, office, employment level, direct manager, employment status, and probation dates. Every change is stamped with an effective date, a reason, an optional note, and who made it.
• Compensation — a chronological log of salary changes: amount, currency, pay period, effective date, reason, and note.

They are kept separate on purpose. Employment History is an automatic audit trail — it is written for you whenever an administrator changes the employee's job details. Compensation is a managed list — an authorised person adds each salary change explicitly. Both are visible as their own tab on the employee profile.

Where to find them

Each tab appears when the viewer has permission to see that history. The Compensation tab stays visible even when it is empty, so an authorised person can add the first record. The Employment History tab always has at least the automatic Hire entry to show. Without the matching permission, the tab is hidden entirely (see Permissions & visibility).

2. Employment History — what it records

The Employment History tab combines two audit trails into a single view:

• Job changes — any change to the audited job fields listed below.
• Hire-date changes — every time an employee's official hire date is corrected, along with how the time-off balance was recalculated as a result.

Audited job fields

A new Employment History entry is created whenever any of these fields changes:

• Position
• Department
• Office
• Employment Level
• Direct Manager
• Employment Status
• Probation start / Probation end dates

"Position" is the employee's job title on the Job section. The access-control Role (a permission setting) is changed elsewhere in Brainy HR and is not part of this audit trail.

Change reasons

Each entry carries a reason so the history reads as a story, not just a list of field edits:

The starting point

Every employee's history begins with a Hire entry that captures their job details as of their start date. For employees who already existed before this feature was introduced, that initial Hire entry was created automatically, so no one starts with a blank history.

3. How an Employment History entry is created

Employment History is written automatically. You never add an entry by hand — you simply edit the employee's job, and Brainy HR records the change for you.

The change-reason dialog

When you edit an employee's Job section and any audited field has actually changed, Brainy HR shows a short dialog before saving. It asks for:

• Effective date — the date the change is recorded as taking effect. It defaults to today and can be back-dated to record a change that already happened. A job change is applied to the profile immediately — unlike compensation, it is not scheduled — so a future date is not allowed.
• Change reason — one of the reasons from the table above.
• Notes — free text. Optional for most reasons, but required when the reason is Other (the dialog will not save without it).

The dialog also shows a "what changed" summary (each field's before → after) so you can confirm you're recording the right change. If nothing audited changed — for example you only edited a field that isn't tracked — no dialog appears and no history entry is written.

Changes made outside the dialog (API / integrations). In the app a change reason is always required. An external integration that updates the Job section through the API may leave it out — the change is still recorded rather than dropped, and its history row is labelled Not specified. (A reason that is sent but left blank is rejected, so a form can never save an empty reason by accident.)

Who is recorded as the author

The person who saves the change is stored as "Changed by" on the entry, giving you a complete accountability trail.

Hire-date changes

Correcting an employee's hire date is recorded on the same tab, in a separate "Hire date history" section. Because the hire date can affect time-off accrual, each hire-date entry also shows how the balance was recalculated (the recalculation mode and its result). This section only appears once a hire date has been corrected at least once — until then there is nothing to show, so it stays hidden.

4. Reading the Employment History tab

The tab lists entries newest-first. Each row shows:

A quick link under Employment Details on the profile jumps straight to this tab. Its counter (e.g. "Employment History (4)") counts only actual changes — the initial Hire snapshot is not counted, and hire-date corrections are — and the number is shown only when there is at least one change.

Employment History is read-only

Entries cannot be edited or deleted from the tab — it is an audit trail, and its value comes from being tamper-proof. If a past entry is wrong, record a new change with the Correction reason and a note explaining it; the timeline stays intact and honest. Each row always keeps the exact change that was confirmed in its own dialog, even after a later back-dated entry is added.

Example. Suppose someone's department was set to Sales by mistake and should have been Marketing. You don't erase the wrong row — you add a new one:

• Transfer — Department: Operations → Sales — the original (wrong) change.
• Correction — Department: Sales → Marketing — note: "Wrong department entered on the previous line; corrected."

Both rows remain visible, so anyone reading the history can see what happened and that it was put right.

5. Compensation — salary history

The Compensation tab holds the employee's salary history as a list of dated records. Each record describes what the employee was paid from a given date:

Unlike Employment History, Compensation is a managed list: an authorised person adds each record deliberately. This makes sense because salary decisions are made outside the system and then entered as a record of what was agreed.

Compensation is never included in the employee CSV exports (neither the standard Employees export nor the former-employees export). Salary data can only be seen on the Compensation tab, by users who hold the right permission — it is deliberately kept out of bulk export files.

6. Adding, editing and deleting salary records

On the Compensation tab of an employee's profile, users with a manage permission (see Permissions) see controls to maintain the list.

Add a salary change

1. Open the employee's Compensation tab and choose Add salary change.
2. Enter the amount, currency, and pay period.
3. Set the effective date — the date the new pay applies from.
4. Pick a reason and, optionally, add a note.
5. Save. The new record appears in the list and, if its effective date is today or earlier, becomes the current salary.

Edit or delete

Each record can be edited (to fix a typo in the amount, date, or reason) or deleted. Deletion asks for confirmation, because removing a record changes the salary timeline. Prefer editing over deleting when you are correcting a value; delete only when a record should never have existed.

Managing your own salary

No one can add, edit or delete their own compensation — even users who can manage everyone else's. Pay changes are always recorded by someone else (HR or a manager), which keeps the record trustworthy. See Permissions.

7. How "current salary" is determined

Brainy HR does not store a separate "current salary" value that can drift out of sync. Instead, the current salary is always the most recent record whose effective date is today or in the past.

This has two useful consequences:

• Future raises can be entered in advance. Add a record with a future effective date and it will automatically become the current salary on that date — no reminder needed.
• History is never rewritten. Adding a new record never changes older ones; the timeline simply grows, and "what did this person earn on date X?" always has a correct answer.

8. Permissions & visibility — the scope model

Both histories are sensitive, so both use the same idea: a permission is not just "can see history" — it is "can see whose history". This is the scope.

The three scopes

Employment History permissions (view only)

Employment History is an audit trail, so there is nothing to "manage" — only to view. Three permissions, one per scope:

• View own employment history
• View employment history of direct reports
• View employment history of anyone

Compensation permissions (view and manage)

Compensation adds the ability to record changes, so it has view and manage permissions:

• View own compensation
• View compensation of direct reports
• View compensation of anyone
• Manage compensation of direct reports
• Manage compensation of anyone

There is deliberately no "manage own compensation" — see the note in section 6.

How the scopes stack

Broader scopes automatically include narrower ones, and managing implies viewing:

• "Anyone" includes direct reports and self;
• "Direct reports" includes viewing those reports (a manager who can manage a report's pay can also see it);
• The workspace Owner can view both histories for everyone — with one exception that applies to everyone: no one may manage their own compensation, not even the Owner (the Owner can still see their own pay history, just not edit it);
• Users from a different company never see anything.

Nothing is granted by default

Important: none of these permissions are turned on out of the box. Until you assign them to a role, the Employment History and Compensation tabs are hidden for everyone except the workspace Owner. Grant them in Settings → Permissions by editing the relevant role and enabling the scopes that role should have.

Recommended starting point

Visibility follows permission exactly

If a viewer has no matching scope for the person they are looking at, the tab and its quick-link are hidden and the underlying data is never loaded — there is no way to reach it by guessing a URL. Grant a scope and the tab appears; revoke it and the tab disappears.

9. What employees see on their own profile

When an employee has an "own" view permission, matching tabs appear on their own profile. These "own" permissions are off by default — until you grant "View own employment history" / "View own compensation" to the employee's role, they see neither tab on their own profile.

With the permission granted, they get:

• Employment History — a read-only view of their own job-change and hire-date history.
• Compensation — a read-only view of their own salary history.

Both are strictly read-only on the self-profile. Employees can see their own record for transparency, but they can never edit it — pay and job changes are always recorded by HR or a manager. If you prefer employees not to see their own pay history at all, simply leave the "View own compensation" permission off for their role.

10. Frequently asked questions

Q. Why don't I see the Employment History or Compensation tab on an employee?
A. Your role has no scope that covers that employee. These permissions are off by default — ask an administrator to grant the appropriate scope in Settings → Permissions. (The tab does not depend on there being records: Compensation shows even when empty so the first record can be added, and Employment History always has the automatic Hire entry.)

Q. I changed a job field but no history entry was created. Why?
A. Only specific fields are audited (position, department, office, level, direct manager, employment status, probation dates). Editing a non-audited field — including the access-control role — does not create an entry. If you did change an audited field, make sure you completed the change-reason dialog when saving.

Q. Can I edit or delete an Employment History entry?
A. No — it is a tamper-proof audit trail. To correct a mistake, record a new change with the Correction reason and a note. Compensation records, by contrast, can be edited or deleted by someone with a manage permission.

Q. Can a manager set their own salary?
A. No. No one can add, edit or delete their own compensation, regardless of permissions — this includes a user with "Manage compensation of anyone" and the workspace Owner. Someone else records it for them; each person can still view their own pay history. This keeps pay records trustworthy.

Q. I entered a future effective date on a salary record. What happens now?
A. The record is stored but does not become the "current" salary until its effective date arrives. On that date it takes over automatically. This is the recommended way to schedule a raise in advance.

Q. Does changing someone's salary rewrite the old figure?
A. No. Every salary change is a new record. Old records are never altered, so the full history — and the answer to "what did they earn on any given date?" — stays accurate.

Q. Who is recorded as making a change?
A. The signed-in user who saves the change is stored as "Changed by" on both Employment History entries and Compensation records.