Skip to main content
When an appraisal is finished and the outcome is good, you usually want to do something about it — pay a one-off bonus, bump someone’s base salary, or both. Appraisal rewards are how Hitaji 360 turns a completed appraisal into real compensation, but it never does so quietly or automatically. A performance appraisal on its own moves no money: submitting an appraisal changes nobody’s pay. A reward only reaches payroll through an explicit, two-person maker-checker flow — one person proposes the reward, a different person approves it, and only on approval is anything created in payroll. This page covers proposing a reward off an appraisal, the bonus and increment legs, who can approve, and the important fact that an issued reward locks the appraisal (and its cycle) against deletion until it is reversed. You’ll find this at: there is no standalone “Rewards” route. Rewards live on the Rewards section of an appraisal’s detail page — open an appraisal at /hr/performance/appraisals/:id and use the Rewards panel (tab rewards).
📷 Screenshot: the Rewards panel on an appraisal detail page, showing the “Propose” button and an existing proposal card — to be added.
Hitaji 360 is multi-business. A reward is stamped with the appraisal’s business and can only be seen, proposed, approved or rejected from within that same business. Make sure the correct business is selected in the switcher before you start — a caller from another business is refused (404) before any pay artefact is created.

​
Before you start

  • The appraisal must be submitted (finalised). A reward can only be proposed off an appraisal whose document status is submitted (docstatus 1). A draft or pending-review appraisal can still have its scores changed, so the system refuses to reward it — you’ll get a message that the appraisal must be submitted first. See Appraisals.
  • The employee needs an active employment contract. The reward is tied to the employee’s current contract; the Propose button is disabled (with a “No active employment contract” tooltip) until one is found.
  • A bonus needs an earning pay component. If you intend to pay a bonus, your business must have at least one active earning salary component to post it against. See Salary components.

​
What a reward can do (the two legs)

A reward has a type, which decides which “legs” it carries:

​
The bonus leg

A bonus needs: On approval, the system creates a submitted Additional Salary for the contract, in the contract’s pay currency (UGX if none is set), dated to the reward’s effective date (or today if none was given). The next payroll run for that employee then picks it up. See Running payroll.

​
The increment leg

An increment needs: How the new base is worked out:
  • ABSOLUTE — the value is the new base salary.
  • PERCENT — the value is added as a percentage on top of the current active base. The system reads the active salary-structure assignment as at the effective date and applies current base × (1 + N/100). If the contract has no active assignment with a base salary on that date, the increment is refused with a message asking you to use an ABSOLUTE increment instead.
On approval the increment is materialised as a submitted Employee Promotion carrying the new base. See Promotions. You can add an optional Reason (up to 1,000 characters) on any reward; it flows through to the bonus / promotion record so payroll can see why.

​
Proposing a reward (the maker step)

  1. Open the submitted appraisal and go to the Rewards panel.
  2. Choose Propose.
  3. Pick the reward type (Bonus, Increment, or Both) and fill the leg(s) — the form only shows and validates the legs your chosen type needs.
  4. Add an optional reason.
  5. Choose Propose.
📷 Screenshot: the “Propose Reward” modal with the Bonus leg and Increment leg sections — to be added.
The proposal is saved as Proposed. No pay change happens yet. As the modal reminds you, a different approver must approve this proposal before the bonus and/or increment is created. Proposing requires the hr-performance:write permission.

​
Approving or rejecting (the checker step)

A pending (Proposed) reward shows Approve and Reject buttons to anyone with approval rights.
  • Approve & Apply — creates and submits the bonus and/or the salary increment, then marks the reward Applied.
  • Reject — marks the reward Rejected. No pay change is made. You can add a reason.
Approving / rejecting requires the hr-performance:approve permission.

​
Segregation of duties

The person who approves a reward must not be the person who proposed it. If the proposer tries to approve their own reward, the system refuses with a segregation-of-duties error. This two-person rule is enforced in the service itself, not just by the permission split, so it cannot be bypassed by a role that happens to hold both permissions.

​
Safe to double-click

Approval is idempotent and runs under a row lock. If a reward is already Applied, re-approving simply returns it unchanged. Two simultaneous approvals (or an impatient double-click) serialise — the second waits for the first to finish, sees the reward is already Applied, and does nothing. A reward can therefore never create duplicate pay.

​
Reward statuses

​
Permissions

All actions are tenant- and business-scoped: a reward belonging to another business — or to a different appraisal accessed through the wrong URL — is treated as not found.

​
Rewards block deletion of the appraisal and cycle

This is the most important thing to understand before you issue a reward. Once a reward has been issued — that is, it is Approved/Applied, or it has stamped a downstream Additional Salary or Employee Promotion — the parent appraisal can no longer be deleted, and because of that the parent appraisal cycle can no longer be deleted either. The reward has put real money into the payroll pipeline, so the appraisal it came from must stay on the record. If you genuinely need to remove such an appraisal or cycle, the issued reward has to be reversed through payroll first (back out the Additional Salary / Promotion it created), after which the appraisal is free to delete again. See Appraisals and Appraisal cycles for how the deletion guard surfaces there.
A reward that is only Proposed (never approved) has not touched payroll and does not block deletion — reject it (or delete the appraisal will simply leave a Proposed row that never materialised).

​
Behind the scenes

When a reward is approved:
  1. Bonus leg → an Additional Salary is created against the employee’s contract for the bonus amount and component, then submitted, dated to the effective date (or today). The next payroll run includes it.
  2. Increment leg → the current active base salary is resolved (for PERCENT) or taken outright (for ABSOLUTE), and an Employee Promotion carrying the new base is created and submitted, effective-dated.
  3. The reward is stamped with the IDs of the artefacts it created and flipped to Applied.
Everything above runs inside one transaction under a lock on the reward row, so a reward either creates all its pay artefacts and applies, or none of them.
  • Appraisals — the appraisal a reward is proposed against; deletion is blocked once a reward is issued
  • Appraisal cycles — the cycle that holds the appraisals; cannot be deleted while an issued reward exists
  • Performance overview — how performance fits together
  • Running payroll — where the bonus Additional Salary is picked up
  • Salary components — the earning component a bonus posts against
  • Promotions — the Employee Promotion an increment creates