Skip to main content
A goal is something you want an employee to achieve — “Close 20 deals this quarter”, “Reduce support response time to under an hour”, “Complete the onboarding redesign”. In Hitaji 360 a goal carries a progress figure from 0 to 100%, so as the work moves along you (or a line manager) nudge that number up and everyone can see where things stand. Goals are more than a to-do list. When you link a goal to a KRA (key result area) and an appraisal cycle, the goal’s progress feeds directly into the employee’s automated appraisal score for that cycle — so the day-to-day progress you record here becomes the evidence behind the formal review. Goals can also be nested: a big group goal can hold several sub-goals, and a parent’s progress rolls up automatically from its children. This page covers creating goals, recording progress, the tree view, archiving, and exactly how goals drive appraisal scores. You’ll find this at: /hr/performance/goals (the list) and /hr/performance/goals/:id (a single goal).
Hitaji 360 is multi-business: goals belong to the business selected in the switcher at the top of the app. A goal created under one business is invisible to another, and you cannot edit or bulk-update another business’s goals. Confirm the correct business is selected before you create or change anything.
📷 Screenshot: Goals list page with the List / Tree view toggle and the “New Goal” button — to be added.

​
How a goal fits together

A single goal record carries:
  • An employee it belongs to (required).
  • An optional KRA — the result area it contributes to. This is what makes the goal count towards an automated appraisal score (see How goals drive appraisal scores below).
  • An optional appraisal cycle — the review period the goal sits in.
  • An optional parent goal — set this to nest the goal under another, building a tree.
  • A progress figure (0–100%) and a status derived from it.
Because goals form a tree, the Goals area gives you two ways to look at them: a flat List and a hierarchical Tree.

​
Goal statuses

Every goal has a status. For ordinary live goals the status is set automatically from progress, so you rarely touch it by hand:
Archived and Closed are “terminal”. Once a goal is Archived or Closed it is frozen: changing its progress will not re-open it, and if it is a parent goal its progress no longer drifts when a child changes. To bring it back, set its status explicitly.

​
The two views

​
List view

The default. A paginated table of goals showing the goal name, employee, KRA, cycle, a progress bar, and status. Click any row to open the goal’s detail page. Use the filter bar to narrow by Employee, Cycle, or Status.

​
Tree view

Switch to Tree to see goals as a hierarchy — group goals expand to reveal their sub-goals, which can expand further. Each row shows the goal’s progress and, for groups, a “x of y completed” caption.
The tree only loads once you pick an employee or a cycle in the filters — without a filter it shows a prompt asking you to choose one. This keeps the tree scoped to one person or one review period rather than dumping every goal in the business.
📷 Screenshot: Tree view with an expanded group goal showing nested sub-goals — to be added.

​
Creating a goal

From the Goals list choose New Goal.
📷 Screenshot: New Goal modal — to be added.
A new goal starts at 0% progress unless you supply a starting figure, and its status is derived from that figure (so a fresh goal is Pending). Two rules the system enforces when you create a goal:
  • A KRA is required when you link a goal to an appraisal cycle. If you pick a cycle but no KRA (and the parent goal has none either), the save is rejected with “A KRA is required for goals linked to an appraisal cycle.” This is what guarantees cycle-linked goals can actually be scored.
  • Sub-goals must match their parent. A sub-goal’s employee, cycle, and KRA must match the parent goal’s. If you try to parent a goal under one belonging to a different employee, cycle, or KRA, the save is rejected. (Sub-goals created from the detail page inherit the parent’s employee, KRA, and cycle automatically, so this only bites if you set a conflicting parent by hand.)

​
Adding sub-goals (nesting)

Open a group goal (or any goal that already has children) and use Add Sub-goal in the Sub-goals card. The sub-goal automatically inherits the parent’s employee, KRA, and cycle — you just give it a name and, optionally, dates and a description. Adding the first sub-goal to a plain goal turns that goal into a group.
📷 Screenshot: Goal detail page Sub-goals card with the “Add Sub-goal” button — to be added.
Progress rolls up. A parent goal’s progress is the average of its non-archived children’s progress, recalculated automatically whenever a child changes — and this rolls all the way up a deep tree. So you don’t set a group goal’s progress directly; you move the children and the parent follows. (Archived children are excluded from the average. A terminal — Archived or Closed — parent is frozen and does not roll up.)

​
Recording progress

Progress is the heart of a goal. On the detail page, drag the progress slider or type a number (0–100) into the box next to it — the change is saved automatically. Status updates itself from the new figure: 0% → Pending, 1–99% → In Progress, 100% → Completed.
📷 Screenshot: Goal detail page progress slider — to be added.
For a parent (group) goal, you normally don’t edit progress directly — it is computed from the children. The detail page shows a “x of y sub-goals completed” caption so you can see the make-up.

​
Editing a goal

Open a goal and choose Edit to change its name, KRA, cycle, dates, or description. One guard applies: a sub-goal’s KRA must match its parent’s KRA — if you try to set a different KRA on a goal that has a parent, the save is rejected. Changing a group goal’s KRA cascades that KRA down to all its descendants automatically.

​
Archiving a goal

Choose Archive on a goal’s detail page to park it. Archived goals are hidden from active views and from the tree, and they no longer count towards a parent’s rolled-up progress or towards appraisal scores — but the record is kept. The Archive button disappears once a goal is already Archived. Archiving is a soft, reversible state (set the status back explicitly to revive it).

​
Bulk status update

The system supports updating the status of many goals at once (up to 500 in one call) — for example, to Close a batch of goals at the end of a cycle. Setting the batch to Completed also pushes each goal’s progress to 100%. The bulk action only touches goals in your own business (any IDs belonging to another business are silently skipped).
⚠️ Current state: Bulk status update is available in the API (PATCH /goals/bulk-status) and the status options exist on the list filter, but there is no dedicated multi-select “change status” button on the Goals list UI today. In the current screens you change status one goal at a time (via Edit, the Archive action, or by moving progress). Treat bulk update as an API-level capability until a list-page control is added.

​
Deleting a goal

A goal can be deleted (a soft delete — it is hidden, not erased) only when it has no sub-goals. If you try to delete a goal that still has children — including archived children, which are hidden from the tree but still count — the system refuses with “Cannot delete a goal that has sub-goals. Delete them first.” Remove or reparent the children first.
The Delete action exists on the API (DELETE /goals/:id). The detail page exposes Edit and Archive; for most day-to-day tidying, Archive is the right tool — it keeps the record and history.

​
How goals drive appraisal scores

This is the most important thing to understand about goals, because it affects what shows up in a formal review. When an appraisal cycle is set to score goals automatically, the cycle works out each KRA’s “goal completion” like this:
It takes the employee’s top-level goals (those with no parent), excludes archived ones, keeps only those that have a KRA and belong to that cycle, and averages their progress, grouped by KRA.
In plain terms:
  • Only top-level goals count towards the score. Sub-goals do not add their own line to the score — they exist to organise work and to roll their progress up into their parent. The parent (a top-level goal) is what the score reads.
  • A goal only counts if it has a KRA and is linked to the cycle. A goal with no KRA, or no cycle, contributes nothing to the automated score (it’s still a perfectly valid personal goal — it just doesn’t feed the review).
  • Archived goals are ignored in the score.
So if you want an employee’s goals to influence their appraisal, make the top-level goals carry the KRA and the cycle, and let sub-goals roll up underneath. The cycle then turns each KRA’s average completion into a weighted contribution to the overall goal score. (How that weighting and the final blended score work is covered on the Appraisals and Appraisal cycles pages.) Whenever a goal’s progress or status changes in a way that affects a cycle, Hitaji 360 quietly refreshes the related appraisal scores in the background — so the review stays in step with the work without anyone re-running anything by hand.

​
Permissions

Actions on goals are gated by these permission slugs (your role may have some and not others): All goal data is tenant- and business-scoped: requests are confined to the active business (X-Business-Id), and any attempt to read, edit, or bulk-mutate a goal in another business fails closed.