Metric dictionary

Metric	Formula	Formula interpretation
System Usage & Access
# of active users	Count of worker IDs	Number of users in scope, used as the denominator for the adoption percentages (for example % users having plans). It sets the "out of how many people" baseline, so every share on the page is read against it. Filtering to a team or org unit re-bases it to that population.
# managers	Count of distinct line-manager IDs referenced across worker rows	Number of distinct people act as a line manager for the population in view. There is no separate manager list; a person counts as a manager because their worker ID appears as someone else's line manager, so the number reflects only managers who actually have a reporting worker in scope. It typically serves as the base for manager-level coverage or activity measures, and it re-bases whenever you filter to a team or org unit. Because it is inferred from reporting links, a manager whose reports fall outside the current selection will not appear.
# workers	Count of distinct worker instances	Number of distinct workers who make up the population in view, i.e. the full headcount. It includes everyone with a worker record, managers among them, so it overlaps with # Managers rather than complementing it (managers are a subset of workers, not a separate group). It is also a different population from # Active users: workers are counted from the worker/employment records, whereas active users are provisioned application accounts, and the two do not always line up.
# accepted data privacy	Count of active users where [Has Accepted Data Privacy] = Yes	Number of users who have accepted the data-privacy statement. It tracks consent coverage in absolute terms; a rising count means more people have accepted. Read it against the workforce size, since a growing headcount can hold the share down even as the count climbs.
% accepted data privacy	Count of users where [Has Accepted Data Privacy] = Yes÷ count of all active users	Share of users in the directory who have accepted the data-privacy statement; i.e. the consent rate. It puts the raw count in context so groups of different sizes compare fairly; a low or falling rate flags a consent gap to chase.
% active users by user role	Count of managers÷ count of active users OR Count of workers÷ count of active users	Make-up of the active user base by role: what share are managers versus workers. It shows the shape of who is in the system, not how much they use it. It is useful as context for the adoption and login splits rather than an activity measure on its own. A shift over time (say more managers) reflects the population mix in scope, and filtering to a team re-bases the split to that selection.
worker full name	Worker's full name when exactly one worker is in view Otherwise blank	A label, not a number; it echoes the currently selected worker's name so the Individual People-Day page can title itself for that person. It shows a name only when the filters narrow to a single worker; with several (or none) selected it stays blank, which is how the page signals "pick one worker." It drives page headings, so it never aggregates or counts anything.
# logins	Count of connection IDs (one per sign-in event)	Number of sign-in events. It counts events, not people: one user logging in ten times adds ten. So it measures activity volume, not reach, and should be read alongside Unique logins (distinct people) to tell heavy repeat use apart from broad adoption. Filtering to a period or team re-bases it to those sign-ins.
# logins over time	Count of connection IDs, by date (one point per period)	Same sign-in event count as # logins, broken out along a date axis so you can see activity rise and fall period by period. Each point is the logins in that bucket (not a running total), so the points sum back to the single # Logins figure. Read it for trends and seasonality in usage; pair it with the cumulative first-time-login curve to tell repeat activity apart from new adoption.
unique logins over time	Count of distinct users who signed in, by date (one point per period)	Reach of logins over time: how many distinct people signed in during each period, regardless of how often. Within a period a user is counted once no matter how many times they connect, so this strips out repeat activity that # Logins over time includes. Comparing the two curves shows intensity: if total logins climb but unique logins stay flat, the same people are just logging in more. It measures active users per period, not a running total.
total logins over time per platform	Count of sign-in events, by date, split by platform	Login event volume over time, broken out by the device/platform each sign-in came from (desktop/iPhone/Android/Outlook/Teams), so you can see the usage trend and the channel mix together (for example desktop dropping while Teams rises). Each point is the events in that period for that platform, not a running total and not distinct people, so a heavy repeat user inflates their platform's bars. Read it for adoption of access channels over time rather than reach.
avg logins over time per platform	Count of sign-in events÷ count of distinct users who signed in, by date, split by platform	Average number of logins per user, tracked over time and broken out by platform. It is the intensity measure: total sign-in events divided by the distinct users behind them, so it answers "when people use this channel, how often do they come back," regardless of how many people that is. A rising line means the same users are logging in more frequently on that platform; comparing platforms shows which channels drive habitual use versus occasional access.
unique logins	Count of distinct users who signed in	Number of distinct people having signed in at all, i.e. the reach of logins as opposed to the volume. Counts each user once no matter how many times they connect, so it answers "how many people used the platform," which paired with # Logins (events) shows whether a high login count is broad use or a few heavy users. Filtering to a period or team re-bases it to those users.
% users having logged in	Count of distinct users who signed in÷ count of all users	Share of the user directory that has actually signed in, the login rate. It puts Unique Logins in context so groups of different sizes compare fairly, answering "what proportion of the people who could use the platform did." A low or falling rate flags an activation gap; it says nothing about how often those users return (that is the average-logins measure).
device usage	For each platform, count of distinct users who signed in on that platform ÷ total distinct users who signed in (donut share)	Channel mix of your user base by reach: how many distinct people used each platform to sign in (desktop/iPhone/Android/Outlook/Teams), displayed as a donut so each is a share of the whole. It counts people, not sessions, so it tells you where users actually work from rather than raw traffic. One caveat on the shares: a user who signs in from more than one platform is counted in each slice, so the slices can add up to more than the unique-user total, and the percentages describe per-platform reach rather than a clean split.
% Android logins	Count of distinct users who signed in on Android÷ count of distinct users who signed in (any platform)	Share of signed-in users who used Android at least once, so you can size the Android channel against overall reach rather than raw counts. The denominator is users who logged in (any platform), not the whole directory, so it reads as "of people who signed in, what fraction touched Android." Because a user can appear on several platforms, the Android share and the other platform shares can add to more than 100%; treat each as per-platform penetration, not a slice of a clean pie.
% Desktop logins	Count of distinct users who signed in on desktop÷ count of distinct users who signed in (any platform)	Share of signed-in users who logged in on desktop at least once, so you can size the desktop channel against overall reach rather than raw counts. The denominator is users who logged in (any platform), not the whole directory, so it reads as "of people who signed in, what fraction touched desktop." Because a user can appear on several platforms, the desktop share and the other platform shares can add to more than 100%; treat each as per-platform penetration, not a slice of a clean pie.
% iPhone logins	Count of distinct users who signed in on iPhone÷ count of distinct users who signed in (any platform)	Share of signed-in users who logged in on iPhone at least once, so you can size the desktop channel against overall reach rather than raw counts. The denominator is users who logged in (any platform), not the whole directory, so it reads as "of people who signed in, what fraction touched iPhone." Because a user can appear on several platforms, the iPhone share and the other platform shares can add to more than 100%; treat each as per-platform penetration, not a slice of a clean pie.
% Outlook logins	Count of distinct users who signed in on Outlook÷ count of distinct users who signed in (any platform)	Share of signed-in users who logged in on Outlook at least once, so you can size the desktop channel against overall reach rather than raw counts. The denominator is users who logged in (any platform), not the whole directory, so it reads as "of people who signed in, what fraction touched Outlook." Because a user can appear on several platforms, the Outlook share and the other platform shares can add to more than 100%; treat each as per-platform penetration, not a slice of a clean pie.
% MS Teams logins	Count of distinct users who signed in on Teams÷ count of distinct users who signed in (any platform)	Share of signed-in users who logged in on Teams at least once, so you can size the desktop channel against overall reach rather than raw counts. The denominator is users who logged in (any platform), not the whole directory, so it reads as "of people who signed in, what fraction touched Teams." Because a user can appear on several platforms, the Teams share and the other platform shares can add to more than 100%; treat each as per-platform penetration, not a slice of a clean pie.
# first time logins	Count of users by their first-login date (one row per user, so each user counted once at their first-ever sign-in)	Number of users signed in for the very first time, i.e. newly activated users. Each person is counted once, at their first login only, so unlike # Logins (events) or Unique Logins (distinct users active in a period) this measures onboarding rather than ongoing use. On a date axis it shows the per-period intake of new users; its running total is the adoption curve # Cumulative Logins.
avg logins per user	Count of sign-in events÷ count of distinct users who signed in	On average, how many times each user who signed in did so, i.e. the login intensity. It divides total sign-in events by the distinct users behind them, so it isolates depth of use from reach: Unique Logins tells you how many people came, this tells you how often they came back. A value near 1 means most users signed in just once; a higher value means habitual, repeat use.
# workers logged in	Count of distinct workers who signed in	Number distinct workers having signed in at all, i.e. login reach measured by worker (each person counted once no matter how many times they connect). It answers "how many of our people used the platform," and paired with # Logins (events) it separates reach from frequency.
# managers logged in	Count of distinct managers who signed in	Number of distinct managers having signed in at all, i.e. manager login reach. Each manager is counted once regardless of how many times they connect. It is the count behind % Managers Logged In; pair it with the total number of managers to see coverage.
% workers logged in	Count of distinct non-manager workers who signed in÷ count of all non-manager workers	Login rate among individual workers who are not managers; i.e. of the non-managers, the share who actually signed in. It isolates rank-and-file adoption from managers, so a low value points to the wider workforce not engaging even if leadership does. Read it against % Managers Logged In to compare turnout between the two groups.
% managers logged in	Count of distinct managers who signed in÷ count of all managers	Login rate among managers; i.e. of the people flagged as managers, the share who signed in. It isolates manager engagement, which matters because reviews, approvals and comp steps wait on them, so a low value is an early warning for stalled workflows. Compare with % Workers Logged In to see whether managers show up more or less than their reports.
Functionality usage	For each of the three core features, count of users who used it÷ count of active users	Share of the user base that has adopted each core feature (feedback, goals, check-ins), shown side by side so uptake can be compared across the three. It plots the three existing adoption rates (% Users Used Feedback, % Users Having Goals, % Users Having Check-ins) together, and the hover tooltip shows the underlying counts. Read against # of active users for the population each share is based on.
Last data refresh	Timestamp of the most recent successful data refresh	Shows when the report data was last refreshed, so readers know how current every figure on the page is. It is a freshness stamp, not a business metric. Read against your expected refresh schedule to spot stale data.
Role assignment	List of analytics users with their user ID, full name, email, and assigned analytics roles	One row per analytics user, listing the security roles each account is granted in the app. It is a reference table for auditing who holds which access, not a computed metric. Read against your role policy to confirm assignments are correct. Keyed by user (Analytics User ID), so it reflects application accounts, not workers.
Users with global access	List of users whose data access is unrestricted, with worker ID, full name, and email	Users who can see data for the whole organization, with no row-level restriction applied. It identifies the accounts with the broadest visibility. Read against Users with restricted access for how the population splits by access scope.
Users with restricted access	List of users whose data access is limited to a defined scope, with worker ID, full name, and email	Users whose view is confined by row-level security to a subset of the organization, such as their own team or org unit. It identifies the accounts with limited visibility. Read against Users with global access for how the population splits by access scope.
Total number of users in table	Count of users listed in the Role assignment table	Number of user accounts shown in the Role assignment table for the current selection. It is a live tally of that table's rows, so it moves with any filter applied. Read against Users with global access and Users with restricted access to see how those accounts break down by scope.
Activity	Section heading (no data)	A textbox label marking the Activity section of the Individual People Day Summary page. It carries no metric or value and simply groups the widgets beneath it.
Data Privacy acceptance	Share of users in each data-privacy acceptance status	Breakdown of users by whether they have accepted the data-privacy statement, as a share of the total, with the underlying count in the tooltip. It complements the single acceptance-rate card by showing the full status split. Read against % accepted data privacy for the headline rate. Counts users.
Goals (54)
# users having goals	Count of distinct goal owners (workers who own at least one goal); 0 if there are no goals in view	Number of distinct workers who own at least one goal, i.e. goal-setting adoption in absolute terms. It counts people, not goals, so someone with five goals still counts once. Read it against headcount (or use the % sibling) to judge reach; its complement is # Users having no goals.
% users having goals	Count of distinct goal owners (workers with at least one goal)÷ count of all people in the directory	Share of the population that owns a goal; i.e. the goal-setting adoption rate. It puts # Users having goals in context so groups of different sizes compare fairly, answering "what proportion of our people have set any goal." A low or falling rate flags a goal-setting gap; its complement is % Users having no goals.
% managers having used the goals feature	Count of distinct managers who own at least one goal÷ count of all managers	Goal-setting adoption rate among managers; i.e. of the people flagged as managers, the share who own at least one goal. It gauges whether leadership is modeling goal-setting. Compare with the worker gauge to see if managers are ahead of or behind their reports. A low value is worth attention since managers not setting goals often cascades to their teams. Shared goals: this counts goal owners, so a goal only counts for the person who owns it. A goal shared with a manager does not make them "having goals"; only goals they own do (and a goal the manager owns and has shared out still counts for them). Own goals only, by owner attribution.
% workers having used the goals feature	Count of distinct non-manager workers who own at least one goal÷ count of all non-manager workers	Goal-setting adoption rate among individual non-manager workers; i.e. of the workers who are not managers, the share who own at least one goal. It shows whether the wider workforce is setting goals, independent of leadership; compare with the manager gauge to see if the two groups track together. A low value flags rank-and-file disengagement from goal-setting even if managers are active. Shared goals: counts goal owners only, so a goal shared with a worker does not make them "having goals"; only goals they own do (a goal they own and shared out still counts). Own goals, by owner attribution.
% managers having goals	Count of distinct managers who own at least one goal÷ count of all managers	Goal-setting adoption rate among managers; i.e. of the people flagged as managers, the share who own at least one goal. It gauges whether leadership is modeling goal-setting. Compare with the worker gauge to see if managers are ahead of or behind their reports. A low value is worth attention since managers not setting goals often cascades to their teams. Shared goals: this counts goal owners, so a goal only counts for the person who owns it. A goal shared with a manager does not make them "having goals"; only goals they own do (and a goal the manager owns and has shared out still counts for them). Own goals only, by owner attribution.
% workers having goals	Count of distinct non-manager workers who own at least one goal÷ count of all non-manager workers	Goal-setting adoption rate among individual non-manager workers; i.e. of the workers who are not managers, the share who own at least one goal. It shows whether the wider workforce is setting goals, independent of leadership; compare with the manager gauge to see if the two groups track together. A low value flags rank-and-file disengagement from goal-setting even if managers are active. Shared goals: counts goal owners only, so a goal shared with a worker does not make them "having goals"; only goals they own do (a goal they own and shared out still counts). Own goals, by owner attribution.
% users having aligned goals	Count of distinct workers who own at least one aligned goal (Is Aligned = 1)÷ count of all people in the directory	Share of the population who own at least one goal that is aligned to a parent or company goal, i.e. how widely people connect their goals to something higher up. It measures cascade/alignment reach across people, not the share of goals that are aligned (that's a goal-level measure). A low value means goals are being set in isolation rather than tied to broader objectives. Shared goals: counts goal owners who have an aligned goal, by owner attribution. A goal shared with a worker does not make them count; a goal they own and shared out still counts if it is aligned. Own aligned goals only.
# goals	Count of goals (one per goal record)	Total number of goals in scope, each goal being counted once (goals, not people; shared goals included once each). Two exclusions are built in at load and worth knowing: goals in the completed-pending-approval state are left out entirely, and goals not attached to a goal plan are excluded. So a goal a worker has marked complete but whose completion the manager hasn't yet approved won't appear here at all, which can make the count dip while approvals are pending. Archived and completed goals are included.
# goals completed	Count of goals where [Is Completed] = Yes	Number of goals having reached the completed state, i.e. fully done with completion approved. Read against # Goals (or via % Goal Completed) to see how much of the goal load is finished. One subtlety from the data scope: a goal a worker has marked complete but the manager hasn't yet approved is not counted here and isn't in the totals at all (that's the excluded completed-pending-approval state), so this reflects approved completions only. Shared goals are included and counted only once (per owner).
% goals completed	Count of goals where [Is Completed] = Yes÷ count of all goals	Share of goals that are fully completed (completion approved), i.e. the goal completion rate. It puts # Goals completed in context so goal loads of different sizes compare fairly. Note the scope caveat: goals a worker marked complete but awaiting manager approval (completed-pending-approval) are in neither the numerator nor the denominator, so the rate reflects approved completions out of the goals that are in the data. Shared goals: both sides count goals once each, by owner. A goal shared by its owner with a team counts once in the denominator, and once in the numerator if completed; goals shared with someone are never counted as theirs. "Shared" is a per-goal flag (shared by the owner), and individual/team/org goals are counted together.
# goals approved	Count of goals where [Is Approved] = Yes	Number of goals have been approved (a manager has signed off on the goal itself, as opposed to its completion). It shows how much of the goal set has cleared the approval gate; pair it with # Goals or use % Approved to see the share still pending. A gap between total goals and approved goals points to goals stuck waiting on manager approval. Shared goals: counted once each, by owner. A goal shared by its owner with a team counts once here if approved; goals shared with someone are never counted as theirs. "Shared" is a per-goal flag (shared by the owner); individual, team and org goals are counted together.
% approved	Count of goals where [Is Approved] = Yes÷ count of all goals	Share of goals that have been approved; i.e. the goal-approval rate. It puts the approved count in context so goal sets of different sizes compare fairly, showing how much of the goal load has cleared the approval gate. A low or falling rate flags a backlog of goals waiting on manager approval; it pairs with % Goals pending approval (its rough inverse). Shared goals: both sides count goals once each, by owner. A goal shared by its owner with a team counts once in the denominator and, if approved, once in the numerator; goals shared with someone are never counted as theirs. "Shared" is a per-goal flag (shared by the owner); individual, team and org goals are counted together.
# goals pending approval	Count of goals that are not archived and whose status is "Approval Pending" (created, awaiting approval)	Number of goals sitting in the approval queue, waiting for a manager to approve the goal before work proceeds. It sizes the approval backlog; a rising value means goals are being created faster than managers approve them, which can stall goal-setting. Pair it with # Goals approved and % Goals pending approval to see the queue against the total. Shared goals: counted once each, by owner. A goal shared by its owner with a team counts once here if it is pending approval; goals shared with someone are never counted as theirs. "Shared" is a per-goal flag (shared by the owner); individual, team and org goals are counted together.
% goals pending approval	Count of goals not archived with status "Approval Pending"÷ count of all goals	Share of goals sitting in the approval queue, i.e. the approval-backlog rate. It puts # Goals pending approval in context so goal sets of different sizes compare fairly, showing how much of the goal load is still waiting on a manager to approve. A high or rising value means approvals aren't keeping pace with goal creation; it is roughly the inverse of % Approved goals. Shared goals: both sides count goals once each, by owner. A goal shared by its owner with a team counts once in the denominator and, if pending approval, once in the numerator; goals shared with someone are never counted as theirs. "Shared" is a per-goal flag (shared by the owner); individual, team and org goals are counted together.
# aligned goals	Count of goals where [Is Aligned] = Yes (goals that have at least one parent goal)	Number of goals aligned upward to a higher goal; i.e. linked to a parent so they cascade from broader objectives. It sizes how much of the goal set is connected to the wider strategy rather than set in isolation; read against # Goals or via % Aligned goals for the share. One definitional point: a goal counts as aligned only when it has a parent; being a parent to child goals does not by itself make a goal "aligned." Shared goals: counted once each, by owner. A goal shared by its owner with a team counts once here if it is aligned; goals shared with someone are never counted as theirs. "Shared" is a per-goal flag (shared by the owner); individual, team and org goals are counted together.
% aligned	Count of goals where [Is Aligned] = Yes (goals with at least one parent goal)÷ count of all goals	Share of goals aligned upward to a higher goal, i.e. the alignment rate. It puts # Aligned goals in context so goal sets of different sizes compare fairly, showing how much of the goal load is tied to broader objectives rather than set in isolation. A low value signals goals being created without a strategic link; same definitional point applies, a goal counts as aligned only if it has a parent (being a parent to children does not count). Shared goals: both sides count goals once each, by owner. A goal shared by its owner with a team counts once in the denominator and, if aligned, once in the numerator; goals shared with someone are never counted as theirs. "Shared" is a per-goal flag (shared by the owner); individual, team and org goals are counted together.
avg. progress (%)	Sum of goals' progress %÷ number of goals (in scope: goals that are In Progress or in a completion state, with a non-blank progress value)	Mean completion progress of goals that are actually being worked on or closing out, on a 0–100% scale. Not-started/draft goals are excluded from both the sum and the count, so it reflects momentum on live goals rather than being dragged down by ones that haven't begun. Rising means goals are advancing toward completion; read it with % Goals completed to separate "progressing" from "finished." Shared goals: this divides over goals, each counted once and attributed to its owner. A goal shared by its owner with a team contributes one progress value to both the sum and the count; goals shared with someone are never counted as theirs. Individual, team and org goals are pooled together.
# actions	Sum of each goal's deliverable count (total deliverables across goals)	Total number of actions (deliverables) defined under the goals in scope, i.e. the concrete sub-tasks people attach to their goals. It counts action items, not goals, so a goal with several actions contributes several and a goal with none contributes zero. Read it with # Actions completed/% Deliverable completed to see how much of that work is done, and against # Goals to gauge how granular goals are being broken down. Shared goals: this sums over goals, each goal's actions counted once and attributed to its owner. A goal shared by its owner with a team contributes its actions once; goals shared with someone never count as theirs. Individual, team and org goals are pooled together.
# actions completed	Sum of each goal's completed-deliverable count (total completed deliverables across goals)	Number actions (deliverables) attached to goals that have been completed, in scope. It counts finished sub-tasks, not goals, so it measures execution at the action level rather than whether whole goals are done. Read it against # Actions (or via % Deliverable completed) to see how much of the action workload is finished; a low ratio means goals are set with actions that aren't being ticked off. Shared goals: sums over goals, each goal's completed actions counted once and attributed to its owner. A goal shared by its owner with a team contributes its completed actions once; goals shared with someone never count as theirs. Individual, team and org goals are pooled together.
% actions completed	Sum of completed deliverables÷ sum of all deliverables (across goals)	Share of goal actions that are done; i.e. the deliverable completion rate. It divides completed actions by total actions across all goals in scope, so it measures execution at the action level independent of how many actions there are. A low or falling rate means actions are being defined but not ticked off; it complements % Goals completed, which looks at whole goals rather than their sub-tasks. Shared goals: both sides sum over goals, each goal's actions counted once and attributed to its owner. A shared goal contributes its actions (and completed actions) once; goals shared with someone never count as theirs. Individual, team and org goals are pooled together.
# goals (with at least one deliverable)	count of goals where deliverable count ≥ 1	Number goals that have been broken down into at least one concrete deliverable/action, as opposed to being set with no action items behind them. It measures whether goals are being made actionable; pair it with # Goals (or use % Goals with deliverables) to see the share. A large gap means many goals exist as headline statements with nothing tracked underneath. Shared goals: counts goals, each once and attributed to its owner. A goal shared by its owner with a team counts once here if it has a deliverable; goals shared with someone never count as theirs. Individual, team and org goals are counted together.
% goals with deliverables	Count of goals where deliverable count ≥ 1÷ count of all goals	Share of goals that have at least one deliverable/action attached, i.e. how actionable the goal set is. It puts the count in context so goal sets of different sizes compare fairly, showing what proportion of goals have concrete steps versus being headline statements alone. A low or falling rate means goals are being set without anything tracked underneath. Shared goals: both sides count goals, each once and attributed to its owner. A shared goal counts once in the denominator and, if it has a deliverable, once in the numerator; goals shared with someone never count as theirs. Individual, team and org goals are counted together.
# unique parent goals	Count of distinct parent goal IDs (goals that at least one other goal is aligned to)	Number of distinct goals that act as a parent; i.e. the higher-level goals that other goals cascade up to. It sizes the set of anchor goals the organisation aligns around, so a small number relative to many aligned child goals means alignment converges on a few key objectives, while a large number means alignment is spread across many parents. It counts the parents themselves, not the alignment links or the child goals. Shared goals: this counts distinct parent goals from the alignment links, so each parent goal is counted once whether or not it is shared; sharing does not change it. Because it comes from the alignment table rather than goal ownership, it isn't owner-attributed like the ownership measures, and individual/team/org parent goals are counted together.
avg parent goal progress (%)	Sum of parent (main) goal progress % across alignment links ÷ number of alignment links	Average progress of the higher-level (parent) goals that others align to, on a 0–100% scale, telling you how well the anchor objectives are advancing. Important weighting caveat: the average runs over alignment links, not distinct parents, so a parent goal with several children is counted once per child and therefore pulls the average more heavily than a parent with one child. So it's a child-weighted average of parent progress, not a plain average per parent goal. Shared goals: this averages parent goals' progress across alignment links, so each parent contributes once per child link regardless of sharing; it's alignment-based, not owner-attributed, and individual/team/org parents are pooled together.
# unique aligned goals	Count of child goal IDs across alignment links (one per alignment link, not deduplicated)	Number of alignment relationships that exist from the child side, i.e. how many goals are aligned up to a parent, counted per alignment link. It sizes the volume of upward alignments; read with # Unique parent goals to see how children spread across parents. Because it counts links, a child goal aligned to more than one parent is counted once per parent, so this reflects alignment connections, not distinct aligned goals. Shared goals: this counts alignment links (child side), so each child goal is counted per parent it aligns to, regardless of sharing; it's alignment-based, not owner-attributed, and individual/team/org goals are pooled together.
avg aligned goal progress (%)	Sum of child (aligned) goal progress % across alignment links÷ number of alignment links	Average progress of the aligned (child) goals, on a 0–100% scale, telling you how well the goals that cascade from higher objectives are advancing. It's the child-side counterpart to Avg parent goal progress; comparing the two shows whether the cascaded goals keep pace with their parents. Same weighting caveat: because it averages over alignment links, a child goal aligned to more than one parent is counted once per parent, so it's a link-weighted average, not a clean average per distinct child goal. Shared goals: averages child goals' progress across alignment links regardless of sharing; it's alignment-based, not owner-attributed, and individual/team/org goals are pooled together.
# goals created over time	Count of goals, by created date (one point per period = goals created that period)	Number of goals created in each period; i.e. the goal-creation trend over time. Each goal lands in the period of its created date, so this is a per-period count (not a running total), useful for seeing spikes around review cycles or planning seasons and whether goal-setting is sustained or bursty. The points sum back to # Goals over the full range. Shared goals: counts goals, each once and attributed to its owner, placed at its creation date. A shared goal counts once; goals shared with someone never count as theirs. Individual, team and org goals are counted together.
# shared goals	Count of goals where [Is Shared] = Yes (shared by the owner with at least one person)	Number of goals have been shared by their owners, i.e. made visible to others rather than kept private. It sizes collaborative/transparent goal-setting; read against # Goals (or % Shared goals) for the share. Rising means more goals are being opened up to colleagues. Each goal is counted once, by its owner, if that owner has shared it. "Shared" means shared by the owner, not shared with the person, so a goal shared with a whole team still counts as one shared goal under its owner; goals shared with someone never count as theirs. Individual, team and org goals are counted together.
% shared goals	# shared goals / # goals	Share of goals that owners have shared, i.e. the goal-sharing rate. It puts # Shared goals in context so goal sets of different sizes compare fairly, showing how transparent/collaborative goal-setting is overall. A low value means most goals are kept private; rising means more are being opened up to colleagues. Both sides count goals, each once by owner. "Shared" means shared by the owner (not with them), so a goal shared with a whole team counts once in the numerator; goals shared with someone never count as theirs. Individual, team and org goals are counted together.
# organizational goals	Count of goals where Goal Type = "Organizational"	Number of goals that are of the "Organizational" goal type; i.e. company/org-level objectives as distinct from individual or team goals. It sizes how much of the goal set is top-level organizational goals; read against # Goals or the other Goal Type slices to see the balance between organizational and personal/team goal-setting. Note "Organizational" is one of the tenant's configured goal types, so what qualifies depends on the tenant's goal type setup. Shared goals: counts goals, each once and attributed to its owner. A shared organizational goal counts once; goals shared with someone never count as theirs. Individual, team and org-type goals are the categories being split here, each goal counted once in its own type.
% goal type	For each goal type, count of goals of that type÷ count of all goals	Mix of goals by type, i.e. what share of all goals are Organizational vs Team vs Individual (whatever types the tenant has configured). It shows where goal-setting is concentrated: a large Individual slice means goals are mostly personal, a large Organizational slice means top-down objectives dominate. Because it's a share of the total in view, filtering to a team or period re-bases the percentages to that selection. Shared goals: counts goals, each once by owner and assigned to its single goal type. A shared goal counts once in its type's slice and once in the total; goals shared with someone never count as theirs. Each goal falls in exactly one type.
goal status (%)	For each goal status, count of goals of that status÷ count of all goals	Distribution of goals across their workflow statuses (In Progress, Completed, Approval Pending, etc.), i.e. where the goal set sits in its lifecycle. It shows whether goals are mostly active, finished, or stuck awaiting approval; a big Approval-Pending slice flags a bottleneck, a big Completed slice shows a mature cycle. As a share of the total in view, filtering re-bases the percentages to the current selection. Shared goals: counts goals, each once by owner and placed in its single current status. A shared goal counts once in its status slice and once in the total; goals shared with someone never count as theirs.
# goals at risk	Count of goals where Tracking Status = "At-risk"	Number of goals that the owner has flagged as at risk of not being achieved, a self-reported health signal separate from progress %. It surfaces goals needing attention even if their progress bar looks reasonable; watch it alongside "Blocked" and progress to spot goals drifting. Rising means more goals are being called out as in trouble. Shared goals: counts goals, each once and attributed to its owner. A shared at-risk goal counts once; goals shared with someone never count as theirs. Individual, team and org goals are counted together.
# goals blocked	Count of goals where Tracking Status = "Blocked"	Number of goals that the owner has flagged as blocked, i.e. stalled by something they can't move past, a self-reported health signal separate from progress %. It pinpoints goals needing help or escalation even if progress looks fine; read it alongside "At-risk" to gauge how much of the goal set is in trouble. Rising means more goals are being called out as stuck. Shared goals: counts goals, each once and attributed to its owner. A shared blocked goal counts once; goals shared with someone never count as theirs. Individual, team and org goals are counted together.
# goals not selected	Count of goals where Tracking Status = "Not selected"	Number of goals that have no tracking status set, i.e. the owner hasn't marked them On track, At-risk or Blocked. It measures how much of the goal set has no health signal at all, which is the key context for the other tracking tiles: if this bucket is large, low At-risk/Blocked counts reflect missing input rather than healthy goals. A high value is a data-hygiene flag, not a performance one. Shared goals: counts goals, each once and attributed to its owner. A shared untracked goal counts once; goals shared with someone never count as theirs. Individual, team and org goals are counted together.
# goals on track	Count of goals where Tracking Status = "On track"	Number of goals that the owner has flagged as on track, i.e. progressing as expected, a self-reported health signal separate from progress %. It's the positive counterpart to At-risk and Blocked; together the three (plus Not selected) show the health mix of the goal set. Read it as a share of goals that actually have a status set, since untracked goals sit in "Not selected" rather than here. Shared goals: counts goals, each once and attributed to its owner. A shared on-track goal counts once; goals shared with someone never count as theirs. Individual, team and org goals are counted together.
# goals high priority	Count of goals where Priority Type = "High"	Number of goals that are marked high priority, i.e. the ones the owner considers most important. It sizes the top-priority workload; read against # Goals or the Medium/Low counts to see whether priority is being used meaningfully or everything is flagged high. Watch it with completion/at-risk to check the most important goals are actually progressing. Shared goals: counts goals, each once and attributed to its owner. A shared high-priority goal counts once; goals shared with someone never count as theirs. Individual, team and org goals are counted together.
# goals medium priority	Count of goals where Priority Type = "Medium"	Number of goals that are marked medium priority, the standard/default priority level. It's usually the largest priority bucket since Medium is the platform default, so read it as the baseline against which deliberately High- or Low-flagged goals stand out. A very large Medium share can mean owners aren't actively setting priority rather than a true mid-level workload. Shared goals: counts goals, each once and attributed to its owner. A shared medium-priority goal counts once; goals shared with someone never count as theirs. Individual, team and org goals are counted together.
# goals low priority	Count of goals where Priority Type = "Low"	Number of goals that are marked low priority, the least important tier. It's usually the smallest priority bucket; a meaningful Low count shows owners are actively de-prioritising some goals rather than leaving everything at the Medium default. Watch it if low-priority goals are consuming attention (progress/actions) that higher-priority ones should get. Shared goals: counts goals, each once and attributed to its owner. A shared low-priority goal counts once; goals shared with someone never count as theirs. Individual, team and org goals are counted together.
% public goals	Count of goals where [Has Public Visibility] = Yes (returns 0 if none) — not a percentage, despite the name and % formatting	Meant to be the share of goals set to public visibility (visible to everyone rather than restricted). As written it returns the raw count of public goals with no division by the total, yet carries a 0 % format string, so it renders the count multiplied into a nonsensical percentage. The intended metric is "what fraction of goals are public"; the delivered value is neither a clean count (wrong format) nor a rate (no denominator). Shared goals: it counts goals, each once by owner. Public visibility is separate from sharing: "public" = visible to all, whereas "shared" = shared by the owner with specific people/org units. A goal shared with someone never counts as theirs here. Individual, team and org goals are counted together.
# users with no goals	Count of active users − count of workers who own at least one goal	Number of active people who have no goals of their own, i.e. the goal-setting gap. It's the complement of # Users having goals: subtract the goal owners from the active population to get those not participating. A high value flags people who haven't set any goals, which is the group to chase for adoption. Shared goals: this hinges on ownership. A person counts as "having goals" only if they own a goal; a goal merely shared with them does not count. So someone who only has goals shared with them (but owns none) is counted here as "no goals." "Shared" = shared by the owner; individual, team and org goals all count toward their owner.
% users with no goals	(count of active users − count of workers who own at least one goal)÷ count of active users	Share of active people who have no goals of their own, i.e. the goal-setting gap as a rate. It puts # Users having no goals in context so populations of different sizes compare fairly, showing what proportion of the workforce hasn't set any goals. A high or rising value flags an adoption problem; it's the complement of % Users having goals. Shared goals: hinges on ownership. Someone counts as "having goals" only if they own a goal; a goal merely shared with them doesn't count, so a person who only has goals shared with them lands in this "no goals" group. "Shared" = shared by the owner; individual, team and org goals all count toward their owner.
# managers with no goals	Count of active managers − count of managers who own at least one goal	Number of managers who have no goals of their own, i.e. the goal-setting gap among leadership. It flags managers not modeling goal-setting, which matters because their teams often follow; compare with # Workers with no goals to see whether the gap sits with managers or the wider workforce. A high value is worth chasing since managers set the tone. Shared goals: ownership-based. A manager counts as "having goals" only if they own a goal; goals shared with them don't count, so a manager who only has goals shared with them lands in this "no goals" group. "Shared" = shared by the owner; individual, team and org goals all count toward their owner.
% managers with no goals	(count of active managers − count of managers who own at least one goal)÷ count of active managers	Share of managers who have no goals of their own; i.e. the goal-setting gap among leadership as a rate. It puts # Managers with no goals in context so it compares fairly regardless of how many managers there are; a high or rising value flags leadership not modelling goal-setting, which tends to cascade to their teams. It's the complement of % Managers having goals and pairs with % Workers with no goals. Shared goals: ownership-based. A manager counts as "having goals" only if they own a goal; goals shared with them don't count, so a manager who only has goals shared with them lands in this "no goals" group. "Shared" = shared by the owner; individual, team and org goals all count toward their owner.
# workers with no goals	count of active non-manager workers − count of non-manager workers who own at least one goal	Number of individual non-manager contributors who have no goals of their own, i.e. the goal-setting gap among the wider workforce. It shows whether rank-and-file staff are participating in goal-setting, independent of leadership; compare with # Managers with no goals to see where the gap sits. A high value flags broad non-adoption to chase. Shared goals: ownership-based. A worker counts as "having goals" only if they own a goal; goals shared with them don't count, so a worker who only has goals shared with them lands in this "no goals" group. "Shared" = shared by the owner; individual, team and org goals all count toward their owner.
% workers with no goals	(count of active non-manager workers − count of non-manager workers who own at least one goal)÷ count of active non-manager workers	Share of individual contributors (non-managers) who have no goals of their own, i.e. the goal-setting gap among the wider workforce as a rate. It puts # Workers with no goals in context so it compares fairly regardless of team size; a high or rising value flags broad non-adoption among staff. It's the complement of % Workers having goals and pairs with % Managers with no goals. Shared goals: ownership-based. A worker counts as "having goals" only if they own a goal; goals shared with them don't count, so a worker who only has goals shared with them lands in this "no goals" group. "Shared" = shared by the owner; individual, team and org goals all count toward their owner.
# users with no goals by org level	(count of active users − count of workers who own at least one goal), split by org level	Goal-setting gap broken down by organizational level/unit, so you can see where in the org people aren't setting goals rather than just the total. Drilling the org hierarchy pinpoints the departments or teams driving the gap, which is more actionable than the company-wide number. Bars/rows sum back to the overall # Users having no goals. Shared goals: ownership-based. A person counts as "having goals" only if they own a goal; goals shared with them don't count, so someone with only shared-with goals falls into "no goals" in their org unit. "Shared" = shared by the owner; individual, team and org goals all count toward their owner.
# of goals with strategic drivers	Count of distinct goals that have at least one strategic driver (tag)	Number of goals that are tagged with a strategic driver, i.e. linked to a strategic theme/priority the organisation tracks against. It shows how many goals are connected to strategy via tagging (distinct from parent-child alignment); read against # Goals to see the share that carry a driver. A goal with several drivers is counted once, since it's distinct goals, not tag assignments. Shared goals: counts goals, each once and attributed to its owner. A shared goal with a driver counts once; goals shared with someone never count as theirs. Individual, team and org goals are counted together.
Top 5 strategic drivers	Count of goals per strategic driver (tag), keeping the 5 drivers with the highest goal counts	The five strategic drivers that the most goals are tagged with, ranked by how many goals sit under each, so you can see where goal-setting concentrates strategically. It highlights the dominant themes people attach their goals to; the long tail of less-used drivers is cut off by the top-5 limit. Because a goal can carry more than one driver, a single goal can contribute to several bars. Shared goals: counts goals per driver, each attributed to its owner. A shared goal tagged with a driver counts once under that driver; goals shared with someone never count as theirs. Individual, team and org goals are counted together.
# goals by strategic drivers	count of goals per strategic driver (tag), grouped by driver library — all drivers	Full breakdown of the number of goals that sit under each strategic driver, organized by driver library, shown as a treemap sized by goal count. It's the uncapped counterpart to Top 5 strategic drivers, so you see the whole distribution including smaller drivers and which libraries dominate. Because a goal can carry more than one driver, a single goal can appear under several tiles. Shared goals: counts goals per driver, each attributed to its owner. A shared goal tagged with a driver counts once under that driver; goals shared with someone never count as theirs. Individual, team and org goals are counted together.
goal title word cloud	Frequency of each word across goal titles (word size = how often it appears)	Visual tally of the words used in goal titles, with more frequent words shown larger, surfacing the common themes people are setting goals around at a glance. It's a directional cue, not a metric: filler words can dominate, it reflects wording rather than outcomes, and it says nothing about how many goals or how they're progressing. Useful for spotting language patterns (e.g. lots of "revenue" or "customer") across the goal set. Shared goals: each goal's title feeds the cloud once, attributed to its owner. A shared goal's title is counted once; goals shared with someone never count as theirs. Individual, team and org goals are pooled together.
# tag	Count of tag assignments across goals (one per goal-tag link, not distinct tags)	Total number of strategic-driver tags applied to goals, i.e. overall tagging volume. It counts assignments, not distinct tags and not goals: a driver applied to 20 goals contributes 20, and a goal carrying 3 drivers contributes 3. So it measures how much tagging activity there is, not how many different drivers exist. Read it against # Goals with drivers (distinct tagged goals) and the per-driver counts to interpret. Shared goals: counts goal-tag links, each goal's tags attributed to its owner. A shared goal's tags count once per tag; goals shared with someone never count as theirs. Individual, team and org goals are pooled together.
% RT count of tag UUID	Tag assignments for this driver÷ total tag assignments in the row (that org level / worker)	Within each row of the pivot (an org level, drilling down to a worker), the share of that row's tag assignments that goes to each strategic driver, so each row sums to 100% across the drivers. It shows the mix of drivers within each org unit rather than raw volume, letting you compare which strategic themes dominate in different parts of the organisation. Because it's row-relative, a small team and a large one are directly comparable. Shared goals: the underlying tag assignments come from goals, each attributed to its owner; a shared goal's tags count once per tag. Goals shared with someone never count as theirs. Individual, team and org goals are pooled into the row totals.
goal status by org level (%)	For each org level, count of goals in each status÷ total goals in that org level	Goal-status mix within each part of the organization, shown as 100%-stacked bars so every org level sums to 100% and you compare composition rather than volume. It reveals where goals are mostly In Progress vs Completed vs Approval-Pending across departments, so a unit with a big Approval-Pending band stands out as a bottleneck regardless of its size. Drill the org hierarchy to pinpoint the level driving a pattern. Shared goals: counts goals, each once and attributed to its owner, placed in its status and its org level. A shared goal counts once; goals shared with someone never count as theirs. Individual, team and org goals are counted together.
Feedback (49)
# users used feedback	Count of distinct workers who sent feedback OR requested feedback (the two groups combined and de-duplicated)	Number of distinct people who actively used the feedback feature by either giving or requesting feedback. It's an adoption measure of active participation, so someone who only received feedback (never sent or requested) is not counted here. A worker who both sent and requested is counted once. Read against headcount (or % Users used feedback) for reach.
% users used feedback	Count of distinct workers who sent or requested feedback÷ count of all people in the directory	Share of the population who actively used the feedback feature by giving or requesting, i.e. the feedback adoption rate. It puts # Users used feedback in context so groups of different sizes compare fairly; a low value flags feedback not catching on. Receive-only participation is excluded, so it reflects active use, not exposure.
% managers having used the feedback feature	Count of distinct managers who sent or requested feedback÷ count of all managers	Share of managers who actively used the feedback feature by either giving or requesting feedback. It's an adoption measure of active participation, so a manager who only received feedback (never sent or requested) is not counted. A manager who both sent and requested is counted once. Read against the worker rate (% Workers used feedback) to see whether managers model feedback more than their reports.
% workers having used the feedback feature	Count of distinct non-manager workers who sent or requested feedback÷ count of all non-manager workers	Share of individual contributors (non-managers) who actively used the feedback feature by either giving or requesting feedback. It's an adoption measure of active participation, so a worker who only received feedback (never sent or requested) is not counted. A worker who both sent and requested is counted once. Read against the manager rate (% Managers used feedback) to see whether the wider workforce engages with feedback as much as leadership.
% users having feedback	Count of distinct users who received feedback÷ count of all people in the directory	Share of people who received any feedback. This is the receiving side of feedback, so unlike % Users used feedback (people who gave or requested), someone counts here if feedback was directed at them even if they never sent or requested any. A person who received many pieces is counted once. Read against % Users used feedback to compare who gets feedback versus who actively participates.
# users who sent feedback	Count of distinct users who sent feedback	Number of distinct people who gave feedback to someone. It's the giving side only, so people who merely requested or received feedback are not counted here. Someone who sent many pieces of feedback is counted once. Read against # Users who requested feedback and # Users received feedback to see the balance between giving, asking, and getting.
% users who sent feedback	Count of distinct users who sent feedback÷ count of all people in the directory	Share of people who gave feedback to someone. It's the giving side only, so people who merely requested or received feedback are not counted. Someone who sent many pieces of feedback counts once. Read against % Users received feedback and % Users used feedback to compare giving with getting and with overall active use.
% users who requested feedback	Count of distinct users who requested feedback÷ count of all people in the directory	Share of people who asked someone for feedback. It's the requesting side only, so people who gave or received feedback but never asked are not counted. Someone who made several requests counts once. Read against % Users who sent feedback and % Users received feedback to compare asking with giving and getting.
# feedback sent	Count of feedback items sent (one per feedback record)	Number of pieces of feedback given, in scope. It counts feedback items, not people, so a prolific sender who gave 20 pieces contributes 20. It measures volume of feedback activity, not reach. Read against # Users who sent feedback (distinct givers) to tell heavy use by a few apart from broad participation.
# feedback requested	Count of feedback requests (one per request record)	Number of feedback requests made, in scope. It counts request items, not people, so someone who asked several times contributes several. It measures the volume of requesting activity, not how many distinct people requested. Read against # Users who requested feedback (distinct requesters) to separate heavy requesting by a few from broad participation.
reply rate (%)	Count of feedback requests replied to÷ count of all feedback requests	Share of feedback requests that received a reply, i.e. how responsive people are to being asked for feedback. It puts the replied count in context so periods or teams with different request volumes compare fairly; a low rate means requests are going unanswered. It's measured at the request level, so someone who ignores several requests drags it down more than someone who ignores one.
# feedback followed-up	Count of feedback items that had at least one follow-up	Number of pieces of feedback that led to a follow-up (Thanks, Favorite or Let's Meet), i.e. feedback that sparked continued conversation rather than being a one-off. It's a depth-of-engagement signal: high values mean feedback is being acted on or discussed further. It counts feedback items (each counted once if it had any follow-up), not the number of follow-ups and not people. Read against # Feedback sent to see what share of feedback gets followed up.
% feedback followed-up	Count of feedback items that had at least one follow-up÷ count of all feedback items	Share of feedback that led to a follow-up (Thanks, Favorite or Let's Meet), i.e. the follow-up rate. It puts # Feedback follow-up in context so periods with different feedback volumes compare fairly, showing how often feedback turns into continued conversation rather than a one-off. A low rate means feedback is largely fire-and-forget; a higher rate signals feedback is being engaged with further.
# feedback received	Sum of each recipient's received-feedback count (total feedback items received)	Total number of feedback items people received, in scope. It counts pieces of feedback, not recipients, so someone who got 10 pieces contributes 10. It measures volume on the receiving end, not reach. Read against # Users received feedback (distinct recipients) to separate a few heavily-reviewed people from broad coverage, and against # Feedback sent to see the broad feedback tracking.
# feedback received over time	Sum of received-feedback count, by date (feedback items received each period)	Number of feedback items received in each period, plotted as a trend. Each point is that period's total, not a running total, so it shows when feedback arrived rather than a cumulative build-up. On the Individual People Day Summary page, the whole view is scoped to one selected worker, so it reads as that person's incoming-feedback timeline. Read against the sent-over-time line to compare giving and receiving rhythms.
# feedback sent over time	Count of feedback items sent, by date (feedback sent each period)	Number of feedback items given in each period, plotted as a trend. Each point is that period's total, not a running total, so it shows the rhythm of feedback-giving (spikes around review cycles, quiet stretches). The points sum back to # Feedback sent over the full range. On the Individual People Day Summary page, it's scoped to one selected worker, so it reads as that person's outgoing-feedback timeline; on the Feedback report it's the whole population in view.
Avg word count	Sum of feedback word counts÷ number of feedback items	Average length, in words, of the feedback messages that were sent. It's a rough proxy for how detailed or substantive feedback is: a higher value suggests richer, more considered feedback, a very low value suggests terse one-liners. It averages over feedback items with a non-blank word count, so a few long messages can pull it up. Read against # Feedback sent to see whether volume comes with substance.
# rated feedbacks	Count of feedback items that have a rating (non-blank rating ID)	Number of feedback items that received a rating, i.e. where the recipient rated the feedback they got (on qualities like clarity or trust). It's an engagement signal on the quality loop: it counts rated feedback items, not the ratings' scores and not people. Read against # Feedback sent to see what share of feedback gets rated; a low count means the rating feature is little used.
trust (avg.)	Average across recipients of each recipient's average trust rating	Overall average trust score (1–5) that feedback recipients gave when rating the feedback they received, trust being one rating dimension alongside clarity. It gauges how trustworthy or credible feedback is perceived to be. It's computed as a mean of per-recipient averages, so each recipient counts equally regardless of how many ratings they gave. Read against the Clarity average and against # Rated feedbacks, since few ratings make it volatile.
clarity (avg.)	Average across recipients of each recipient's average clarity rating	Overall average clarity score (1–5) that feedback recipients gave when rating the feedback they received, clarity being a rating dimension alongside trust. It gauges how clear and understandable feedback is perceived to be. It's a mean of per-recipient averages, so each recipient counts equally regardless of rating volume. Read against the Trust average and # Rated feedbacks, since few ratings make it volatile.
trust (distribution)	Count of rated feedback items, by trust score	How the trust ratings spread across the 1–5 scale, i.e. how many feedback items got each trust value. It shows the shape behind the trust average: a skew toward 4–5 means feedback is widely seen as trustworthy, while a tail at 1–2 flags feedback perceived as less credible. Read alongside Trust (avg), which collapses this same distribution into one number.
clarity (distribution)	Count of rated feedback items, by clarity score	How the clarity ratings spread across the 1–5 scale, i.e. how many feedback items got each clarity value. It reveals whether clarity perceptions cluster at 4–5 or have a low tail at 1–2 of hard-to-understand feedback, which the single clarity average hides. Read alongside Clarity (avg) and the trust distribution to compare the two dimensions.
# trust & clarity (correlation)	Each point plots a feedback rating's Clarity score (x, 1–5) against its Trust score (y, 1–5)	How the two rating dimensions relate: whether feedback rated clear also tends to be rated trustworthy. Points clustering along the low-to-high diagonal indicate a positive correlation (clear feedback is trusted); a scattered cloud means the two are judged independently. Because both scores are 1–5, points land on a 5×5 grid, so density (or overlap) at each grid position shows where most ratings sit. Read with the trust and clarity distributions, which show each dimension on its own.
sum feedback characteristics	For each characteristic (Helpful, Constructive, Insightful, Inspiring, Unhelpful, Unclear), count of feedback items tagged with it	A profile of how feedback is characterized, comparing the positive tags (Helpful, Constructive, Insightful, Inspiring) against the negative ones (Unhelpful, Unclear). It shows the quality mix of feedback: a healthy picture leans heavily on the positive characteristics with small Unhelpful/Unclear bars. A single feedback item can carry more than one characteristic, so the bars don't sum to the number of feedbacks. Read with the trust/clarity ratings, which score feedback rather than tag it.
sum of avg. clarity	Sum of per-recipient average clarity scores (1–5)	At a single-worker grain (its intended use, as the X-axis of the trust-vs-clarity scatter, one point per worker) this equals that worker's own average clarity score, since summing one recipient's single average returns that average. It is only meaningful per worker. If ever placed in a total or aggregated across workers it would add up per-recipient averages, which is not a valid overall clarity score, so don't read it as a grand total.
sum of avg. trust	Sum of per-recipient average trust scores (1–5)	At a single-worker grain (its intended use, as the Y-axis of the trust-vs-clarity scatter, one point per worker) this equals that worker's own average trust score, since summing one recipient's single average returns that average. It is only meaningful per worker. Aggregated across workers or in a total it would add up per-recipient averages, which is not a valid overall trust score, so don't read it as a grand total.
# request sent over time	Count of feedback requests, by date (requests sent each period)	Number of feedback requests made in each period, plotted as a trend. Each point is that period's total, not a running total, so it shows the rhythm of requesting activity (spikes around review cycles, quiet stretches). It counts requests, not people, so heavy requesting by a few shows up here. Read against # Feedback sent over time to compare asking versus giving over time.
request flow	For each role pair (Worker→Worker, Worker→Manager, Manager→Worker, Manager→Manager), count of requests with that relationship÷ count of all requests	Direction of feedback requests across the hierarchy: what share of requests flow within peers versus up or down the reporting line. It shows who asks whom, so a heavy Worker→Manager slice means people mostly ask their managers for feedback, while Manager→Worker shows leaders soliciting upward-facing input. The four shares are of all requests and sum to 100%. Read with the Feedback flow (sent side) to compare requesting patterns with giving patterns.
% managers having sent feedback	Count of distinct managers who sent feedback÷ count of all managers	Share of managers who gave feedback to someone. It's the giving side scoped to managers, so managers who only received or requested feedback are not counted in the numerator; a manager who sent many pieces counts once. Read against the worker equivalent to see whether managers model feedback-giving more than their reports.
% workers having sent feedback	Count of distinct non-manager workers who sent feedback÷ count of all non-manager workers	Share of individual contributors (non-managers) who gave feedback to someone. It's the giving side scoped to workers, so people who only received or requested feedback are not counted in the numerator; a worker who sent many pieces counts once. Read against the manager equivalent to see whether the wider workforce gives feedback as much as leadership.
% managers having requested feedback	Count of distinct managers who requested feedback÷ count of all managers	Share of managers who asked someone for feedback. It's the requesting side scoped to managers, so managers who only gave or received feedback are not counted in the numerator; a manager who made several requests counts once. Read against the worker equivalent and against % Managers having sent feedback to compare asking with giving among leadership.
% workers having requested feedback	Count of distinct non-manager workers who requested feedback÷ count of all non-manager workers	Share of individual contributors (non-managers) who asked someone for feedback. It's the requesting side scoped to workers, so people who only gave or received feedback are not counted in the numerator, and a worker who made several requests counts once. Read against the manager equivalent and against % Workers having sent feedback to compare asking with giving across the wider workforce.
% requests read	Count of feedback requests that were read÷ count of all feedback requests	Share of feedback requests that the recipient has opened/read. It gauges whether requests are reaching attention, separate from whether they are answered: a request can be read but not replied to. A low value means requests are going unseen; compare it with the reply rate to tell "not seen" apart from "seen but ignored."
# requests replied	Count of feedback requests where the reply status is Replied	Number of feedback requests that got a reply, in scope. It counts requests that were answered, not the people answering, so several answered requests from one person all count. It's the numerator behind the reply rate. Read against # Feedback requests to see how many requests were satisfied, and against # Requests read to tell replied apart from merely seen.
% endorsed feedback	Count of endorsed feedback÷ count of feedback that is Public or Shared	Share of visible feedback that others endorsed (backed/agreed with). The denominator is only public-or-shared feedback, not all feedback, since private feedback can't be seen or endorsed, so it correctly measures endorsement among feedback that was actually endorsable. A higher value means visible feedback is resonating with colleagues.
% shared feedback	Count of feedback where Share = 1÷ count of all feedback	Share of feedback that the sender chose to share (beyond the direct recipient). It gauges how openly feedback is distributed; a low value means feedback is mostly kept one-to-one. Read against % Public feedback, which is the stronger form of openness.
% public feedback	Count of feedback where visibility = Public÷ count of all feedback	Share of feedback set to public visibility (visible to everyone, not just the recipient). It measures feedback transparency; a higher value indicates a more open feedback culture. Read against % Shared feedback, since public is the broadest visibility while shared may be limited to specific people.
# Thanks	Sum of Thanks reactions across feedback	Total number of "Thanks" reactions given to feedback, in scope. It's an appreciation signal from recipients: high volume means feedback is landing well. It counts reactions, not feedback items or people, so one feedback can attract many. Read against # Feedback received to gauge how often feedback prompts a thank-you.
# Favorites	Sum of Favorite reactions across feedback	Total number of times feedback was marked as a favorite (saved/valued) by recipients. It flags feedback people found worth keeping, a stronger signal than a passing thanks. It counts reactions, not feedback items or people. Read against # Thanks to compare light appreciation with feedback people actively hold onto.
# Let's meet	Sum of Let's Meet reactions across feedback	Total number of "Let's Meet" reactions, where a recipient wants to discuss the feedback in person. It signals feedback that opens a conversation rather than closing the loop, so a rise can mean richer follow-up dialogue. It counts reactions, not feedback items or people. Read against # Thanks and # Favorite to see which reaction type dominates.
# feedback linked to goals	Count of feedback where linked-to-goal flag = Yes	Number of feedback items that are tied to a goal, in scope. It counts feedback items grounded in an objective, not goals and not people, so one feedback linked to a goal counts once. It's the count behind % Linked to goals. Read against # Feedback sent to see how much feedback is connected to goals versus freestanding.
% feedback linked to goals	Count of feedback where linked-to-goal flag = Yes÷ count of all feedback items	Share of feedback that is tied to a goal, connecting feedback to what people are working toward. A higher rate means feedback is grounded in objectives rather than freestanding; it's the goal-side counterpart to % Feedback with behaviors. Read the two together to see how much feedback is contextualized.
avg feedback sent per user	Count of feedback items sent÷ count of distinct workers who sent feedback	Average number of feedback items each giver sent, i.e. feedback-giving intensity. It divides total feedback by the distinct people who sent any, so it answers "when someone gives feedback, how much do they give," independent of how many people participate. A value near 1 means most senders gave once; higher means prolific givers. Read against # Users who sent feedback (reach) to separate depth from breadth.
feedback flow	For each role pair (Manager→Manager, Manager→Employee, Employee→Manager, Employee→Employee), count of feedback items with that relationship÷ count of all feedback items	Direction of feedback given across the hierarchy: what share of feedback flows within peers versus up or down the reporting line. It shows who gives feedback to whom, so a heavy Manager→Employee slice means feedback is largely top-down, while Employee→Manager captures upward feedback. The four shares are of all feedback and sum to 100%. Read against Request flow to compare who gives with who asks.
Endorsed, Public & Shared	Share of feedback that is endorsed, that is public, and that is shared, side by side	Three feedback-visibility rates shown together (% endorsed feedback, % public feedback, % shared feedback), so uptake of each can be compared. Each is a share of all feedback. Read against # feedback sent for the volume behind the percentages.
Feedback quality metrics	Share of feedback with behaviors, followed up, and linked to goals, side by side	Three feedback-quality rates shown together (% feedback with behaviors, % feedback followed-up, % feedback linked to goals), so how richly feedback is used can be compared. Each is a share of all feedback. Read against # feedback sent for the volume behind the percentages.
Leadership clusters	For each worker, average clarity rating on the X axis and average trust rating on the Y axis	Plots each worker (as feedback recipient) by their average clarity and trust ratings, so leaders group into clusters (for example high on both versus low on both). Both axes use the 1 to 5 feedback-rating scale. Read against trust (avg.) and clarity (avg.) for the population averages. One point per worker.
Behaviors (18)
# feedback with behaviors	Count of feedback items that reference at least one behavior	Number of pieces of feedback that are tied to at least one behavior (a competency or value from the framework), rather than being free-form only. It's a quality/structure signal: feedback linked to behaviors maps to the organization's competency model and is easier to act on. It counts feedback items (each counted once if it has any behavior), not the number of behaviors and not people. Read against # Feedback sent to see what share of feedback is behavior-linked.
% feedback with behaviors	Count of feedback items that reference ≥1 behavior÷ count of all feedback items	Share of feedback that is tied to at least one behavior from the competency/values framework, rather than free-form only. It puts # Feedback with behaviors in context so periods with different feedback volumes compare fairly, showing how structured and framework-aligned the feedback culture is. A low rate means most feedback is unstructured; a higher rate means people are anchoring feedback to defined behaviors.
% users having behaviors	Count of distinct workers who sent a behavior÷ count of all people in the directory	Share of the population who gave behavior-based feedback, i.e. adoption of the behaviors feature. It counts people who sent at least one behavior, not the behaviors themselves, so someone who cited many behaviors counts once. A low value means behavior feedback is little used across the workforce. Read against % Users used feedback to see whether feedback-givers also tag behaviors.
behavior distribution	Count of behavior references, by behavior	How behavior citations spread across the behavior framework, showing which behaviors get referenced most in feedback. It counts behavior instances, not feedback items or people, so a behavior cited across many feedbacks shows a larger slice. The donut renders each behavior as a share of the total, so it reads as the behavior mix rather than raw counts. Read against # Behaviors sent for the overall volume.
% behaviors received	# behaviors received / total # behaviors (received)
behavior requested (#)	Sum of each request's requested-behavior count (total behaviors requested across requests)	Number of behaviors that feedback requests asked to be assessed on, in scope. Behaviors are the competency/value tags, so this counts behavior instances attached to requests, not the requests and not people; one request asking about three behaviors adds three. It shows how much requesting is anchored to the behavior framework. Read against # Feedback requests and # Requests with behaviors.
behavior sent	Count of behavior records sent (one per behavior referenced in feedback)	Number of behaviors referenced in the feedback that was given, in scope. Behaviors are the competency/value tags on feedback, so this counts behavior instances, not feedback items and not people; one feedback citing three behaviors adds three. It shows how much feedback is anchored to the behavior framework by volume. Read against # Feedback sent and # Feedback with behaviors.
behaviors sent	Count of feedback that cited each behavior, by behavior	How the selected person's sent feedback breaks down across behaviors, showing which behaviors they reference most when giving feedback. On the Individual People Day Summary page, the view is scoped to one worker, so it reads as that person's behavior-usage profile. It counts feedback per behavior, so a feedback citing several behaviors appears under each. Read against # Behaviours Sent for their total behavior volume.
# behaviors received	Sum of each recipient's received-behavior count (total behaviors received across recipients)	Number of behaviors referenced in the feedback that people received, in scope. It counts behavior instances on the receiving end, not feedback items and not people, so a person who received feedback citing many behaviors contributes many. It shows how much behavior-anchored feedback is landing on people. Read against # Behaviors sent (should broadly track it) and # Feedback received.
# behaviors	Count of behavior records (one per behavior referenced in feedback)	Total number of behaviors cited across feedback, in scope. It counts behavior instances, not feedback items and not people, so one feedback citing three behaviors adds three. It sizes how much feedback is anchored to the behavior framework by volume. Read against # Feedback sent and # Feedback with behaviors.
avg. behaviors per feedback	Sum of behaviors across feedback÷ count of feedback items	verage number of behaviors cited per piece of feedback, i.e. how richly feedback is tagged to the competency/value framework. A value near or below 1 means most feedback references at most one behavior (or none), higher means feedback consistently anchors to several behaviors. It divides total behaviors by all feedback, so feedback with no behaviors drags it down. Read against % Feedback with behaviors to separate breadth of tagging from depth.
% behavior distribution	Count of behavior references for this behavior÷ count of all behavior references	Share of all behavior citations that each behavior represents, i.e. the behavior mix in feedback normalized to 100%. It shows which behaviors dominate independent of overall volume, so you can compare the framework's usage pattern across periods or teams. It counts behavior instances, not feedback or people; a behavior cited across many feedbacks takes a larger share. Read against Behavior count distribution for the underlying counts.
behaviors sent over time	Count of behavior references, by date (behaviors cited each period)	Number of behaviors cited in feedback in each period, plotted as a trend. Each point is that period's total, not a running total, so it shows the rhythm of behavior-tagging over time (spikes around review cycles, quiet stretches). It counts behavior instances, not feedback or people. Read against # Feedback sent over time to see whether behavior tagging keeps pace with feedback volume.
behaviors sent by organization level	For each org level, count of behavior references for each behavior÷ total behavior references in that org level	he behavior mix within each part of the organization, shown as 100%-stacked bars so every org level sums to 100% and you compare composition rather than volume. It reveals which behaviors each org unit emphasizes in its feedback, so differences in culture or focus across teams stand out regardless of size. Drill the org hierarchy to pinpoint the level driving a pattern. It counts behavior instances, not people or feedback.
% requests with behaviors	Count of feedback requests that reference ≥1 behavior÷ count of all feedback requests	hare of feedback requests that specify at least one behavior to be assessed on, rather than being open-ended. It signals how structured and framework-aligned requesting is; a low rate means most requests are freeform, a higher rate means requesters point to specific behaviors. It counts requests, not behaviors or people. Read against # Requests with behaviors for the count and % Feedback with behaviors for the sent-side equivalent.
# requests by behavior	Count of feedback requests, by requested behavior	How many feedback requests ask for feedback on each behavior, showing which behaviors people most want to be assessed on. It surfaces demand for feedback against the behavior framework. It counts requests, not behaviors or people, and a request naming several behaviors appears under each, so the bars can exceed the total request count. Read against # Feedback requests for the overall volume.
Check-ins (52)
# users having check-ins	Count of distinct people who took part in a check-in	Number of distinct people who participated in at least one check-in (with their manager or peers), i.e. check-in adoption by reach. It counts people, not check-ins, so someone with many check-ins counts once. Read against headcount (or % Users having check-ins) to gauge how widely check-ins are used.
% users having check-ins	Count of distinct people who took part in a check-in÷ count of all workers	Share of the workforce who participated in at least one check-in, i.e. the check-in adoption rate. It puts # Users having check-ins in context so groups of different sizes compare fairly; a low value flags check-ins not catching on. A person with many check-ins still counts once in the numerator.
# managers having check-ins	Count of distinct managers who took part in a check-in	Number of distinct managers who participated in at least one check-in, i.e. check-in adoption among managers. It counts managers, not check-ins, so a manager with many check-ins counts once. Read against # Workers having check-ins and the total to see whether managers are driving check-in use.
# workers having check-ins	Count of distinct non-manager workers who took part in a check-in	Number of distinct individual contributors (non-managers) who participated in at least one check-in, i.e. check-in adoption among the wider workforce. It counts people, not check-ins, so a worker with many check-ins counts once. Read against # Managers having check-ins and the total to see whether check-in use sits with managers or their reports.
% managers having used the check-ins feature	Count of distinct managers who took part in a check-in÷ count of active managers	Share of managers who participated in at least one check-in, i.e. check-in adoption among managers. It puts # Managers having check-ins in context so it compares fairly regardless of how many managers there are; a low value flags managers not using check-ins with their teams. A manager with many check-ins still counts once in the numerator. Read against the worker equivalent to see whether managers drive check-in use.
% workers having used the check-ins feature	Count of distinct non-manager workers who took part in a check-in÷ count of active non-manager workers	Share of individual contributors (non-managers) who participated in at least one check-in, i.e. check-in adoption among the wider workforce. It puts # Workers having check-ins in context so it compares fairly regardless of team size; a low value flags rank-and-file staff not using check-ins. A worker with many check-ins still counts once in the numerator. Read against the manager equivalent to see whether check-in use sits with managers or their reports.
# check-ins having comments	Count of check-ins where the has-message flag = Yes	Number of check-ins that include a written message, i.e. check-ins with a qualitative comment rather than just a status or rating. It counts check-in records, not messages and not people, so a check-in with several messages counts once. Read against # Check-ins to see how many check-ins carry a written note, a signal of depth versus quick tick-box check-ins.
% check-ins having comments	Count of check-ins where has-message flag = Yes÷ count of all check-ins	Share of check-ins that include a written message, i.e. how many carry a qualitative comment rather than just a status or rating. It puts # Check-ins having comments in context so periods with different check-in volumes compare fairly; a low rate means check-ins are mostly quick tick-box entries with little written detail. Read against % Discussion points to gauge overall check-in richness.
# check-ins	Count of check-in IDs (one per check-in)	Total number of check-ins that took place, in scope. It counts check-in events, not people, so one person with many check-ins adds many; it measures activity volume, not reach. Read against # Users having check-ins (distinct participants) to separate heavy repeat use from broad adoption.
# check-ins having manager roles	Count of distinct check-ins where either participant (from or to) has the Manager role	Number of check-ins that involve a manager, on either side (as the person checking in or the one being checked in with). Since most check-ins are between a worker and their manager, this is usually a large share of all check-ins; a gap versus # Check-ins would be peer-to-peer check-ins with no manager involved. It counts check-in events (a check-in involving two managers still counts once), not people.
# check-ins having worker roles	Count of distinct check-ins where either participant (from or to) has the Worker role	Number of check-ins that involve a non-manager worker, on either side. Since most check-ins are between a worker and their manager, this overlaps heavily with the manager-role count rather than being its complement, so the two should not be expected to sum to # Check-ins. A worker↔worker peer check-in counts here but not in the manager-role count. It counts check-in events, not people.
% workers who created check-ins
# check-ins in the future	Count of check-ins where the future-check-in flag = Yes (check-in date is upcoming)	Number of check-ins scheduled for a future date, i.e. planned rather than already held. It signals forward planning: a healthy value means people are booking check-ins ahead. It counts check-in events, not people, so it's the pipeline of upcoming check-ins. Read against # Check-ins (total) or via % Check-ins in the future to see how much of check-in activity is still to come.
% check-ins in the future	Count of check-ins where future-check-in flag = Yes÷ count of all check-ins	Share of check-ins that are scheduled for a future date rather than already held. It puts # Check-ins in the future in context so periods with different check-in volumes compare fairly, showing how much check-in activity is still ahead versus behind. A higher share signals active forward planning; a very low share means check-ins are mostly logged after the fact.
# check-ins over time	Count of check-in IDs, by date (check-ins each period)	Number of check-ins created in each period, plotted as a trend. Each point is that period's total, not a running total, so it shows the rhythm of check-in activity (spikes around review cycles, quiet stretches). The points sum back to # Check-ins over the full range. It counts check-in events, not people.
% users with check-ins by role	For each role (Manager / Worker), count of that role's check-in participants÷ count of that role's workers	Share of each role who participated in at least one check-in, shown for managers and workers side by side. It reveals where check-in use concentrates, whether managers are ahead of their reports or the reverse. Each bar is that role's participation rate, and a person with many check-ins still counts once. Read against % Users having check-ins for the blended figure across both roles.
% assigned check-ins	#Count of check-ins that are assigned (created from a template)÷ count of all check-ins	hare of check-ins that were assigned from a template rather than created ad-hoc. It shows how structured/standardized the check-in process is: a higher share means check-ins mostly follow a set template, a lower share means they are largely freeform. It counts check-in events, not people. Read against # Check-ins for the underlying volume.
# check-ins by status	Count of check-in IDs, by status (New / In Progress / Done Pending Confirmation / Done / Deleted / Under Review / Assigned)	Distribution of check-ins across their lifecycle statuses, showing where check-ins sit at a glance. A large Done bar means most check-ins are completed, a large New / In Progress bar means an active pipeline, and a visible Deleted bar flags canceled ones. It counts check-in events, not people. Read against # Check-ins for the total these bars sum to.
avg. number of check-ins per user	Count of check-in participations÷ count of distinct participants	Average number of check-ins each participant took part in, i.e. check-in intensity per person. It divides total participations by the distinct people behind them, so it isolates depth of use from reach: a value near 1 means most people had one check-in, higher means habitual check-in users. Read against # Users having check-ins (reach) to tell frequent use apart from broad participation.
avg. number of check-ins (worker)	Count of distinct check-ins involving a worker (from or to)÷ count of distinct workers who took part in a check-in	Average number of check-ins each participating worker was involved in, i.e. check-in intensity among individual contributors. It measures depth of use for workers who use check-ins at all (the denominator excludes non-participants), so a value near 1 means most workers had a single check-in, higher means repeat use. Read against Avg. check-ins per manager to compare intensity between the two roles.
avg. number of check-ins (manager)	Count of distinct check-ins involving a manager (from or to)÷ count of distinct managers who took part in a check-in	Average number of check-ins each participating manager was involved in, i.e. check-in intensity among managers. The denominator excludes managers who never checked in, so it measures depth of use among those who do; a value near 1 means most had a single check-in, higher means repeat use. Read against Avg. Check-ins per worker to compare intensity between the two roles, noting managers often sit across many check-ins with their reports.
# check-ins recurring	Count of check-ins where the recurring flag = Yes	Number of check-ins that are part of a recurring series (set to repeat on a schedule) rather than one-off. It signals a standing check-in cadence: a higher count means regular, habitual check-ins rather than ad-hoc ones. It counts check-in events, not series and not people. Read against # Check-ins to see what share follow a recurring pattern.
% check-ins recurring	Count of check-ins where recurring flag = Yes÷ count of distinct check-ins	Share of check-ins that are part of a recurring series rather than one-off, i.e. how much of check-in activity follows a standing cadence. It puts # Check-ins recurring in context so periods with different volumes compare fairly; a higher rate means regular, habitual check-ins, a low rate means mostly ad-hoc ones. Read against # Check-ins for the underlying volume.
# check-ins with discussion points	Count of check-ins where the has-discussion-points flag = Yes	Number of check-ins that include at least one discussion point (a structured agenda/talking point), as opposed to none. It's a depth signal: check-ins with discussion points are more substantive than a bare status update. It counts check-in events, not discussion points and not people, so a check-in with several points counts once. Read against # Check-ins to see how many carry structured discussion.
% check-ins with discussion points	Count of check-ins where has-discussion-points flag = Yes÷ count of all check-ins	Share of check-ins that include at least one structured discussion point, i.e. how substantive check-ins are versus bare status updates. It puts # Check-ins with discussion points in context so periods with different volumes compare fairly; a higher rate means richer, agenda-driven check-ins. Read against % Check-ins having comments to gauge overall check-in depth.
# manager check-ins with comments	Count of manager check-ins with a message÷ count of all manager check-ins	Share of check-ins involving managers that include a written message, i.e. how substantive managers' check-ins are. Read against the worker bar to compare who writes more in their check-ins.
# worker check-ins with comments	Count of non-manager-worker check-ins with a message÷ count of all non-manager-worker check-ins	Share of check-ins involving non-manager workers that include a written message, i.e. how substantive individual contributors' check-ins are. Read against the manager bar to compare who writes more in their check-ins; a low value means workers' check-ins are mostly bare status entries.
% manager check-ins with comments	Count of manager check-ins with a message÷ count of all manager check-ins	Share of check-ins involving managers that include a written message, i.e. how substantive managers make their check-ins rather than leaving them as bare status entries. A higher value means managers add written context; read against the worker bar to compare who writes more in their check-ins.
% worker check-ins with comments	Count of non-manager-worker check-ins with a message÷ count of all non-manager-worker check-ins	Share of check-ins involving non-manager workers that include a written message, i.e. how substantive individual contributors make their check-ins rather than leaving bare status entries. A higher value means workers add written context; read against the manager bar to compare who writes more.
% check-in ID Row Total	Count of performance check-ins for this rating÷ count of performance check-ins across all ratings (in the row)	Within each row, the share of performance check-ins that fall at each rating value, normalized so the row sums to 100%. It turns raw rating counts into a distribution you can compare across rows (for example org units) regardless of their size, showing where each group's performance-check-in ratings cluster. Read it as the rating mix per row, not an absolute count.
# performance check-ins	Count of performance check-in IDs (one per performance check-in)	Total number of performance check-ins that took place, in scope. Performance check-ins are the review-cycle variety (rated on a scale), distinct from regular check-ins, so this counts those events specifically. It counts check-ins, not people, so someone with several adds several. Read against # Check-ins to separate performance check-ins from the broader set, and use the rating breakdowns for how they scored.
% status by org level	For each org level, count of performance check-ins in each status÷ total performance check-ins in that org level	Status mix of performance check-ins within each part of the organization, shown as 100%-stacked bars so every org level sums to 100% and you compare composition rather than volume. It reveals where performance check-ins are mostly completed versus stuck in earlier statuses, so an org unit with a large in-progress or pending band stands out regardless of its size. Drill the org hierarchy to pinpoint the level driving a pattern.
% rating distribution	Count of performance check-ins for this rating÷ count of all performance check-ins (in the current selection)	Distribution of performance check-in ratings, showing what share of check-ins fall at each rating label. It reveals where ratings cluster: a skew toward the higher labels means strong performance ratings, a heavier low tail flags weaker ones. Because it's a share of the total in the selection, filtering to a team or period re-bases the percentages to that scope. Read it as the rating mix, not absolute counts.
# check-ins (filtered by type)	Count of check-in IDs, by check-in type	Number of check-ins of each type, showing how check-in activity splits across the check-in varieties. It counts check-in events, not people, so a busy type shows a larger slice. The on-screen donut renders this as a share of the total rather than a raw count. Read against # Check-ins for the overall volume the types add up to.
check-in type (%)	Count of check-ins of this type÷ count of all check-ins (in the current selection)	Share of check-ins that are each type, i.e. the type mix of check-in activity. It shows which check-in varieties dominate; because it's a share of the total in the selection, filtering to a team or period re-bases the percentages to that scope. Read it as the type composition rather than absolute volume, and against # Check-ins by type for the counts.
# check-ins (filtered by participant relation)	Count of check-in IDs, by participant relationship (Employee and Manager / Between Colleagues)	Number of check-ins grouped by who takes part, splitting hierarchical check-ins (a worker and their manager) from peer ones (between colleagues). It shows whether check-in activity is mostly manager-driven or peer-to-peer. It counts check-in events, not people. Read against # Check-ins for the total the relationship groups sum to.
check-in participant relation (%)	Count of check-ins of this participant relationship÷ count of all check-ins (in the current selection)	Share of check-ins that are each participant relationship, i.e. the split between hierarchical check-ins (a worker and their manager) and peer ones (between colleagues). It shows whether check-in culture is mostly manager-driven or peer-based; because it's a share of the total in the selection, filtering re-bases the percentages. Read it as the relationship mix rather than raw volume, and against # Check-ins by participant relationship for the counts.
check-in status by organization level (%)	For each org level, count of check-ins in each status÷ total check-ins in that org level	Status mix of regular check-ins within each part of the organization, shown as 100%-stacked bars so every org level sums to 100% and you compare composition rather than volume. It reveals where check-ins are mostly Done versus stuck in New / In Progress / Under Review, so an org unit with a large unfinished band stands out regardless of size. Drill the org hierarchy to pinpoint the level driving a pattern.
# assigned check-ins	Count of check-in IDs where the assigned flag = Yes (created from a template)	Number of check-ins that were assigned from a template rather than created ad-hoc. It sizes the template-driven, standardized portion of check-in activity. It counts check-in events, not people, so a busy assigned type shows a larger figure. Read against # Check-ins for the total, or use % Assigned check-ins for the share.
# deleted check-ins	Count of check-in IDs where status = Deleted	Number of check-ins that were deleted, in scope. It flags check-ins that were created then removed, so a high or rising figure can signal mistaken or abandoned check-ins. It counts check-in events, not people. Read against # Check-ins to see what share of check-ins end up deleted, and against the status breakdown where Deleted is one bucket.
% deleted check-ins	Count of check-in IDs where status = Deleted÷ count of all check-ins	Share of check-ins that were deleted, in scope. It puts the deleted count in context so periods with different volumes compare fairly, showing how often check-ins are created then removed. A high or rising rate can signal mistaken, duplicate, or abandoned check-ins worth investigating. Read against # Check-ins for the underlying volume.
# done check-ins	Count of check-in IDs where status = Done	Number of check-ins that have been fully completed and confirmed, in scope. It's the end-state of the check-in lifecycle, so it measures follow-through; a low share versus total means many check-ins never reach completion. It counts check-in events, not people. Note "Done" is distinct from "Done Pending Confirmation", which is completed but not yet confirmed and is not counted here. Read against # Check-ins and the status breakdown.
% done check-ins	Count of check-in IDs where status = Done÷ count of all check-ins	Share of check-ins that have been fully completed and confirmed, i.e. the check-in follow-through rate. It puts # Done Check-ins in context so periods with different volumes compare fairly; a low or falling rate means many check-ins are created but never carried to completion. Note it counts only "Done", not "Done Pending Confirmation", so completed-but-unconfirmed check-ins are excluded from the numerator. Read against the status breakdown for where the rest sit.
# done pending confirmation check-ins	Count of check-in IDs where status = Done Pending Confirmation	Number of check-ins that one side has marked done but the other has not yet confirmed. It's a waiting state between active and fully done, so a build-up here flags check-ins stuck awaiting the counterpart's confirmation. It counts check-in events, not people. Read against # Done check-ins to see how many completions are still unconfirmed, and against # Check-ins for context.
% done pending confirmation check-ins	Count of check-in IDs where status = Done Pending Confirmation	Number of check-ins that one side has marked done but the other has not yet confirmed. It's a waiting state between active and fully done, so a build-up here flags check-ins stuck awaiting the counterpart's confirmation. It counts check-in events, not people. Read against # Done check-ins to see how many completions are still unconfirmed, and against # Check-ins for context.
# in progress check-ins	Count of check-in IDs where status = In Progress	umber of check-ins currently underway, i.e. started but not yet done. It's the active-work portion of the check-in lifecycle, so it shows the live workload; a large or growing figure means many check-ins are open at once. It counts check-in events, not people. Read against # Done Check-ins and # Check-ins to see how much is in flight versus completed.
% in progress check-ins	Count of check-in IDs where status = In Progress	Number of check-ins currently underway (started but not yet done), the active-work portion of the lifecycle. A large or growing figure means many check-ins are open at once. Read against # Done check-ins and # Check-ins to see how much is in flight versus completed.
# new check-ins	Count of check-in IDs where status = New	Number of check-ins that have been created but not yet started, i.e. sitting at the very start of the lifecycle. It shows the backlog of not-yet-begun check-ins; a large or growing figure can mean check-ins are being scheduled but not acted on. It counts check-in events, not people. Read against # In progress check-ins and # Done check-ins to see how check-ins move through their stages.
% new check-ins	Count of check-in IDs where status = New÷ count of all check-ins	Share of check-ins that are created but not yet started, i.e. how much of check-in activity is still sitting at the start of the lifecycle. It puts # New check-ins in context so periods with different volumes compare fairly; a high or rising rate means check-ins are being scheduled but not acted on. Read against % In progress and % Done check-ins to see the lifecycle balance.
# under review check-ins	Count of check-in IDs where status = Under Review	Number of check-ins in the review stage, i.e. submitted and being reviewed rather than active or finished. A build-up here flags check-ins waiting on a reviewer to act. It counts check-in events, not people. Read against # Done check-ins and # Check-ins to see how many are held at review versus completed.
% under review check-ins	Count of check-in IDs where status = Under Review÷ count of all check-ins	Share of check-ins sitting in the review stage, i.e. how much of check-in activity is waiting on a reviewer rather than active or finished. It puts # Under review check-ins in context so periods with different volumes compare fairly; a high or rising rate flags a review bottleneck. Read against % Done check-ins to see how many clear review versus stay held.
Performance Checkin Ratings by Org Levels	For each org unit and rating, count of performance check-ins and its share of the org unit's row total	A matrix of performance check-in ratings by org unit, showing both the count of check-ins at each rating and that rating's share of the unit's row total. It reveals how ratings are distributed across the organization. Read against % rating distribution for the overall rating spread.
Performance Reviews (45)
# reviews	Count of review IDs (one per performance review)	Total number of performance reviews in scope. It's the base against which the review-status, alignment, and rating measures are read, so every review share on the page is relative to it. It counts reviews, not people, though typically each worker has one review per cycle. Read the completion and alignment percentages relative to this total.
# initial manager/worker alignment	Count of reviews, by initial alignment (Yes / No / Not Available)	How many reviews had the worker's self-rating agree with the manager's rating at the initial stage, split into Yes (they matched), No (they differed), and Not Available (no worker rating to compare). It gauges how aligned self-assessment and manager assessment are before any final calibration; a large No slice signals gaps between how workers and managers see performance. It counts reviews, not people.
% initial manager/worker alignment	Count of reviews where initial alignment = Yes÷ count of all reviews (with the No and Not Available categories making up the rest)	Share of reviews where the worker's self-rating matched the manager's rating at the initial stage. It puts the initial-alignment count in context so it compares fairly across groups of different sizes; a higher rate means workers and managers largely agree before calibration, a low rate flags divergent self- versus manager assessment. Read against the final-alignment rate to see whether calibration brings the two closer.
# final manager/worker alignment	Count of reviews, by final alignment (Yes / No / Not Available)	How many reviews had the worker's self-rating agree with the review's final rating, split into Yes (matched), No (differed), and Not Available (no final rating yet). Unlike the initial version, which compares against the manager's own rating, this compares against the calibrated final rating, so it shows alignment after the process concludes. A large No slice means workers' self-view often diverges from where reviews land. It counts reviews, not people.
% final manager/worker alignment	Count of reviews where final alignment = Yes÷ count of all reviews	Share of reviews where the worker's self-rating matched the calibrated final rating. It puts the final-alignment count in context so groups of different sizes compare fairly; a higher rate means workers' self-view largely agrees with where reviews land, a low rate flags divergence after calibration. Read against the initial-alignment rate to see whether the review process narrows or widens the gap.
% self-review rating distribution	Count of reviews with this worker self-rating÷ count of all reviews (in the current selection)	How workers' self-ratings spread across the rating scale, showing what share of reviews land at each self-rating value. It reveals self-assessment tendencies: a skew toward the top means workers rate themselves generously, a spread or lower cluster means more critical self-views. Because it's a share of the total in the selection, filtering re-bases the percentages. Read against the manager rating distribution to compare how workers rate themselves versus how managers rate them.
% manager rating distribution	Count of reviews with this manager rating÷ count of all reviews (in the current selection)	How managers' ratings spread across the rating scale, showing what share of reviews land at each manager-given value. It reveals rating tendencies on the manager side: a skew toward the top means lenient rating, a wider or lower spread means more differentiated assessment. Because it's a share of the total in the selection, filtering re-bases the percentages. Read against the self-review rating distribution to compare how managers rate versus how workers rate themselves.
% final review rating distribution	Count of reviews with this final rating÷ count of all reviews (in the current selection)	How the calibrated final ratings spread across the rating scale, showing what share of reviews land at each final value. It's the outcome distribution after the review process, so it reflects where performance actually settles once self and manager inputs are reconciled. Because it's a share of the total in the selection, filtering re-bases the percentages. Read against the self-review and manager rating distributions to see how the final outcome differs from either input.
# completed reviews	Count of reviews where the completed flag = Yes	Number of performance reviews that are fully completed, i.e. finished the review cycle overall. It measures review follow-through; read against # Reviews (or via a completion rate) to see how many reviews reached the end. It counts reviews, not people. Note there are separate worker-side (# Worker review completed) and manager-side (# Manager completed review) completion measures for each party's own status, whereas this is the overall completion.
completion rate (%)	Count of reviews where completed flag = Yes÷ count of all reviews	Share of performance reviews that are fully completed, i.e. the overall review completion rate. It puts # Completed reviews in context so cycles or teams of different sizes compare fairly; a low or falling rate flags reviews stalling before completion. It counts reviews, not people. Read against the worker-side and manager-side completion rates to see which party is holding reviews up.
# review completion worker	Count of reviews where Worker Final Review Status = Completed	Number of reviews the worker has completed their part of, i.e. finished their self-review side. It isolates the worker's contribution to review progress, separate from the manager's; read against # Reviews (or the worker completion rate) to see how many workers have done their part. A gap versus # Manager completed review shows which side is holding reviews up. It counts reviews, not people.
% review completion worker	Count of reviews where Worker Final Review Status = Completed÷ count of all reviews	Share of reviews the worker has completed their side of, i.e. the worker-side completion rate. It puts # Worker review completed in context so cycles or teams of different sizes compare fairly; a low or falling rate means workers are slow to finish their self-review. It counts reviews, not people. Read against % Manager Completed Review to see which side is lagging.
# review completion manager	Count of reviews where Manager Review Status = Completed	Number of reviews the manager has completed their part of, i.e. finished the manager review side. It isolates the manager's contribution to review progress, separate from the worker's; read against # Reviews (or the manager completion rate) to see how many managers have done their part. A gap versus # Worker review completed shows which side is holding reviews up. It counts reviews, not people.
% review completion manager	Count of reviews where Manager Review Status = Completed÷ count of all reviews	Share of reviews the manager has completed their side of, i.e. the manager-side completion rate. It puts # Manager completed review in context so cycles or teams of different sizes compare fairly; a low or falling rate means managers are slow to finish their review. It counts reviews, not people. Read against % Worker review completed to see which side is lagging.
# challenged reviews	Count of reviews where the review was challenged (worker or manager+1 formally contested the rating)	Number of performance reviews that were challenged, i.e. where the worker (or the manager's manager) disputed the rating rather than accepting it. It flags friction in the review process; a rising figure signals more workers contesting outcomes. It counts reviews, not people. Read against # Reviews for the challenge share.
# additional review questions	Count of additional review question IDs	Number of additional (custom scale-and-comment) questions in the review, beyond the standard overall rating. It sizes how much extra, tailored questioning the review template includes. It counts question entries, not people and not reviews. Read alongside # Reviews to sense how question-heavy the review process is.
question title	Additional question's title text (a label, not a calculation)	Wording of each additional review question, used to label rows or slice the additional-question widgets so you can see which specific question the responses relate to. It's a dimension, not a metric, so it neither counts nor aggregates anything on its own; it gives the other measures (counts, response breakdowns) their per-question context.
question	List of questions + number of answers for each question	Number of answers each additional review question received, listed by the question's full wording. Since the data has one row per review-question answer, a question's total is how many reviews answered it across the scope in view, and the grand total is all answers combined. It's the granular counterpart to the Question Title matrix, which rolls the same answers up to their category (Competencies, Engagement, and so on). Read the two together to move between the specific question and its category, and note it counts answers, not distinct questions or people.
rating changed by moderator (%)	Count of reviews where Moderated = Yes÷ count of all reviews	Share of reviews where the moderator (the calibrating layer, typically the manager's manager) changed the rating during moderation, rather than leaving the manager's rating as is. It signals how much calibration is actually altering outcomes: a high rate means moderation frequently overrides, a low rate means manager ratings mostly stand. Because it's a share of the total in view, filtering re-bases it. It counts reviews, not people.
# manager review change (people day)	Count of reviews, grouped by the manager's submitted rating, then by the published (post-moderation) rating	How manager ratings shift from submission to publication, shown as a two-level ring: the inner level is the rating the manager originally submitted, the outer level is the rating actually published after moderation, and the size is the number of reviews following each path. Where the outer rating differs from the inner one, the rating was changed during moderation, so the visual surfaces both how much changed and in which direction. It counts reviews, not people.
# review status	Count of reviews, by overall review status	Review break down across their overall status (the combined worker + manager progress state), showing where reviews sit in the lifecycle. A large completed bucket means reviews are finishing; large not-started or in-progress buckets flag a stalled cycle. On screen it's rendered as a 100%-stacked column per org level (share of that unit's reviews in each status), so it compares composition across the org rather than raw counts. It counts reviews, not people.
% review status	For each org level, count of reviews in each overall status÷ total reviews in that org level	Share of reviews at each overall status within each part of the organization, shown as 100%-stacked bars so every org level sums to 100%. It lets you compare status composition across units regardless of their size, so an org unit with a large not-started or in-progress band stands out as behind, while a large completed band shows a unit that has finished. Drill the org hierarchy to pinpoint the level driving a pattern. It counts reviews, not people.
# reviews (worker self-review) status	Count of reviews, by worker self-review status	Breakdown of reviews across the worker's own review status, showing where workers are in completing their self-review side (for example not started, in progress, completed). A large not-started or in-progress bucket means workers are behind on their part, separate from the manager's progress. On screen it's a 100%-stacked column per org level (share of that unit's reviews in each worker status), so it compares composition across the org rather than raw counts. It counts reviews, not people.
% worker self-review status	For each org level, count of reviews in each worker self-review status÷ total reviews in that org level	Share of reviews at each worker self-review status within each part of the organization, shown as 100%-stacked bars so every org level sums to 100%. It compares worker-side progress composition across units regardless of size, so a unit with a large not-started or in-progress band stands out as behind on self-reviews, while a large completed band shows workers who have finished their part. Drill the org hierarchy to pinpoint the level driving a pattern. It counts reviews, not people.
# reviews (manager assessment) by status	Count of reviews, by manager review status	Breakdown of reviews across the manager's review status, showing where managers are in completing their assessment side (for example not started, in progress, completed). A large not-started or in-progress bucket means managers are behind on their part, separate from the worker's self-review progress. On screen it's a 100%-stacked column per org level (share of that unit's reviews in each manager status), so it compares composition across the org rather than raw counts. It counts reviews, not people.
% manager review status	For each org level, count of reviews in each manager review status÷ total reviews in that org level	Share of reviews at each manager review status within each part of the organization, shown as 100%-stacked bars so every org level sums to 100%. It compares manager-side progress composition across units regardless of size, so a unit with a large not-started or in-progress band stands out as behind on manager assessments, while a large completed band shows managers who have finished their part. Drill the org hierarchy to pinpoint the level driving a pattern. It counts reviews, not people.
# reviews by performance rating	Count of reviews, by review (performance) rating	Number of reviews that landed at each performance rating, showing the distribution of outcomes across the rating scale. A skew toward the higher ratings means generous outcomes, a wider spread means more differentiated results. It counts reviews, not people. Read against the per-rating share (% Distribution) to compare rating patterns across groups of different sizes.
review rating distribution (%)	Count of reviews with this rating÷ count of reviews across all ratings (in the row)	Share of reviews at each performance rating, normalized so the ratings sum to 100% within each row (for example within each org unit). It turns raw rating counts into a distribution you can compare across rows regardless of their size, showing where each group's ratings cluster. A skew toward the higher ratings means generous outcomes, a flatter spread means more differentiated results. Read against # Reviews by performance rating for the underlying counts.
# reviews with goals ratings	Count of goal-rating records (one per review-goal)	Number of goal ratings given across reviews, i.e. how many individual goals were rated in the review process. It counts goal-rating rows, not reviews and not people, so a review that rated three goals contributes three. It sizes the volume of goal assessment within reviews. Read against # Reviews to sense how many goals are rated per review.
# reviews with behavior ratings	Count of behavior-rating records (one per review-behavior)	Number of behavior ratings given across reviews, i.e. how many individual behaviors were rated in the review process. It counts behavior-rating rows, not reviews and not people, so a review that rated four behaviors contributes four. It sizes the volume of behavior assessment within reviews. Read against # Reviews to sense how many behaviors are rated per review, and against # Reviews with goals ratings to compare goal versus behavior assessment volume.
# reviews with aligned goal ratings	Count of distinct goal-rating records where Goal Rating Alignment = Aligned	Number of goal ratings where the worker and manager agreed on the goal's rating (aligned), as opposed to differing. It measures agreement at the goal level within reviews; a higher figure means workers and managers see individual goal performance the same way. It counts goal-rating records, not reviews and not people, so a review with several aligned goals contributes several. Read against # Reviews with goals ratings (or % Aligned goal rating) for the aligned share.
# reviews with aligned behavior ratings	Count of distinct behavior-rating records where Behavior Rating Alignment = Aligned	Number of behavior ratings where the worker and manager agreed on the behavior's rating (aligned), as opposed to differing. It measures agreement at the behavior level within reviews; a higher figure means workers and managers see individual behavior performance the same way. It counts behavior-rating records, not reviews and not people, so a review with several aligned behaviors contributes several. Read against # Reviews with behavior ratings (or the aligned behavior rate) for the aligned share.
% reviews with aligned goal ratings	Count of distinct aligned goal-rating records÷ count of all distinct goal-rating records	Share of goal ratings where the worker and manager agreed on the goal's rating, i.e. the goal-level alignment rate. It puts the aligned count in context so groups with different numbers of rated goals compare fairly; a higher rate means workers and managers largely see individual goal performance the same way, a low rate flags disagreement on goals. It works at the goal-rating level, not per review. Read against the behavior alignment rate to compare agreement on goals versus behaviors.
% reviews with aligned behavior ratings	Count of distinct aligned behavior-rating records÷ count of all distinct behavior-rating records	Share of behavior ratings where the worker and manager agreed on the behavior's rating, i.e. the behavior-level alignment rate. It puts the aligned count in context so groups with different numbers of rated behaviors compare fairly; a higher rate means workers and managers largely see individual behavior performance the same way, a low rate flags disagreement on behaviors. It works at the behavior-rating level, not per review. Read against the goal alignment rate to compare agreement on behaviors versus goals.
manager review goal distribution	Count of goal ratings at each rating-scale value÷ total goal ratings (in scope), across the goal rating scale	Share of manager goal ratings that fall at each value of the goal rating scale, showing how managers distribute their ratings on goals. A skew toward the higher scale values means generous goal ratings, a spread means more differentiated assessment. Because it is a share of the scoped total, filtering re-bases the percentages. It counts goal ratings, not reviews or people.
manager review behavior distribution	ount of behavior ratings at each rating-scale value÷ total behavior ratings (in scope), across the behavior rating scale	Share of manager behavior ratings that fall at each value of the behavior rating scale, showing how managers distribute their ratings on behaviors. A skew toward the higher scale values means generous behavior ratings, a spread means more differentiated assessment. Because it is a share of the scoped total, filtering re-bases the percentages. It counts behavior ratings, not reviews or people. Read against the goal distribution to compare how managers rate behaviors versus goals.
% let's discuss between manager and worker	Count of reviews where Let's Discuss Completed = Yes÷ count of all reviews	Share of reviews where the "Let's Discuss" step (the manager-worker conversation about the rating) was completed. It measures engagement with that discussion stage; a higher rate means more reviews included a completed manager-worker discussion, a low rate means the step is often skipped. Because it is a share of the total in view, filtering re-bases it. It counts reviews, not people.
rating changed by manager	Count of reviews, by whether the manager changed the rating (LL Rating Change = Yes / No)	Number of reviews split by whether the manager changed their rating during the review process versus leaving it unchanged. The Yes portion shows how often manager ratings move (for example after discussion or reflection); a large Yes share means ratings are frequently revised rather than fixed at first entry. On the donut each is shown as a share of the total. It counts reviews, not people.
rating changed manager	Count of reviews, by whether the rating changed during the challenge (Yes / No)	Number of reviews split by whether a challenge led to the rating actually changing versus staying the same. The Yes portion shows how often challenges succeed in altering the outcome; a large Yes share means challenges frequently overturn ratings, a small share means they rarely change anything. On the donut each is shown as a share of the total. It counts reviews, not people.
manager +1 review challenge	Count of reviews, grouped by published rating, then by the Let's-Discuss rating, then by the final rating (three-level)	Number of reviews tracing how a rating evolves through the escalation path: the published (post-moderation) rating, then the rating after the manager-worker Let's Discuss step, then the final rating (where the manager's manager, +1, is involved in a challenge). Each ring is one stage and the size is the reviews following that path, so where an outer ring differs from the inner one the rating changed at that stage. It shows both how much movement happens across the stages and in which direction. It counts reviews, not people.
Average Total Score	Average of each review's total score	Average overall achievement score across performance reviews in view, on the review's scoring scale. It summarizes how high reviews are scoring on average and re-bases with filters. Read against Average Total Score by Org Unit to see which units run above or below. Averages reviews, not people.
Average Total Score by Org Unit	Average of each review's total score, split by org unit	Average review total score for each org unit, so achievement can be compared across the organization. Same average as Average Total Score, broken out by org level. Read against the overall Average Total Score to spot units above or below the norm.
Evaluation Scores by org level	For each org unit and evaluation section, the average maximum score and average weighted score	A matrix of evaluation-section scores by org unit, showing the average maximum available and the average weighted score achieved for each section. Read against Average and Max Total Scores by org level for the roll-up.
Average and Max Total Scores by org level	For each org unit, the average total score, average maximum score, and score as a percent of maximum	A matrix summarizing achievement by org unit: the average total score, the average maximum possible, and the ratio of the two. Read against Evaluation Scores by org level for the per-section detail.
Number of reviews with Evaluation Section Score = 0	Count of reviews scoring zero, by evaluation section	Number of reviews that scored zero in each evaluation section, flagging sections left unscored. A high count can indicate incomplete evaluations. Read against Evaluation Scores by org level for the average scores. Counts reviews.
Career Development (20)
# career plan templates	Count of distinct of plans ID	Number of individual unique career development plan IDs that are either in Draft or in Published status.
# career plans	Count of assigned plan IDs (one per worker assignment)	Number of career plans handed out to workers; each assigned plan counted once.
career plans by workflow status	Count of assigned-plan IDs, split by workflow status (Self-Assessment / Manager Review / Completed)	Number of unique career development plans IDs that sit at each stage of the workflow. Every distributed plan is counted once and placed in its current stage: Self-assessment (the worker is filling it in), Manager review (it's with the manager), or Completed. The stacked/percentage version shows the same split as a proportion of all plans rather than raw counts.
# refused career plan	Count of plans where the "Refused" flag = Yes	Number of career plans employees refused, broken down by org level. A plan counts as "refused" when a refusal date has been recorded on it. This is the action done by the worker in the plan view when they check the box Career development plan refused by worker.
# career plans pending manager completion	Count of plans where workflow status = Manager Review	Number of assigned plans that are currently sitting with the manager; the worker has done their part and submitted, and the plan is waiting for the manager to complete it. A pile-up here points to a manager-side bottleneck.
# manager completions over time	Running total of plans where [manager-submit date] ≤ current date	Cumulative curve of manager sign-offs as they accumulate over time. Each point shows how many career plans managers had completed up to that date. A rising line means managers are steadily working through their reviews; a flat stretch means completions stalled. It's the manager-side mirror of the self-assessment-submissions curve.
# self-assessment submissions over time	Running total of plans where [worker-submit date] ≤ current date	Cumulative curve of worker self-assessment submissions as they accumulate over time. Each point shows how many workers had handed in their self-assessment up to that date. A rising line means workers are steadily completing their part; a flat stretch means submissions stalled. It's the worker-side mirror of the manager-completions curve.
# users having plans	Count of distinct workers who have at least one plan	Number of workers who have a career plan assigned. It counts workers, not plans, so someone with several plans still counts once. A rising count means career development is reaching more people; watch it against headcount, since a growing workforce can hold the count flat even as coverage slips.
% users having plans	Number of users having plans÷ count of all workers	Share of the whole workforce that has a career plan; i.e. the adoption rate. This is the count put in context: it answers "how much of the company career development reaches," independent of headcount size. A low or falling percentage points to gaps in roll-out rather than a problem with the plans themselves.
# completed plans	Count of plans where [workflow status] = Completed	Number of career plans that have reached the Completed stage, meaning both the worker's self-assessment and the manager's sign-off are done. It is the end-state counterpart to the pending-manager and pending-self-assessment tiles, which count plans still in flight. Rising means more plans are being carried all the way through.
% completed plans	Count of completed Plans÷ count of all plans	Share of all assigned plans that are Completed; i.e. the completion rate for career development plans. It puts the count in context so a large team and a small one can be compared fairly; a low or falling rate signals plans stalling before sign-off rather than never being started.
# plans pending self-assessment	Count of all plans − plans pending manager completion − completed plans	Number of plans still sitting with the worker, waiting for them to complete and submit their self-assessment. It is the first-stage counterpart to # plans pending manager completion and # completed plans, and the three add up to the total plan count. A high value means workers have not yet started their part, pointing to a worker-side delay rather than a manager bottleneck.
% plans pending worker submission	1 − (count of plans that have moved past self-assessment÷ count of all plans)	Share of all plans still awaiting worker submission. It puts the pending count in context so teams of different sizes compare fairly; a high or rising rate signals a roll-out where workers are slow to engage. "Moved past self-assessment" means any plan now in Manager Review or Completed, so this is the mirror of the worker-submission progress.
% plans pending manager completion	1 − (count of plans the manager has completed÷ count of plans that have reached the manager stage)	Of the plans that are in the manager's court (past self-assessment, so Manager Review or Completed), the share the manager has not yet completed. Unlike the count tile, its denominator excludes plans still with the worker, so it isolates manager throughput: a high or rising value means managers are slow to sign off on plans already handed to them.
# questions	Count of question IDs	Number of questions defined across the career-plan templates, that is, the individual prompts workers and managers fill in. It measures the size and depth of the plan forms themselves, not how many workers answered them; for responses see the answer-level tiles. A higher count means richer or longer templates.
# answers	count of answer IDs	Number of individual responses given to career-plan questions across all plans. Unlike # questions, which sizes the templates, this counts what people (workers + managers) actually filled in, so it reflects real engagement with the plans. Reading it against # Questions × plans shows how completely the forms are being answered; a low ratio means many prompts are being left blank.
question type usage	Count of distinct question IDs, split by answer type	Mix of question formats used across the plan templates, that is, how many questions are of each answer type (free text, rating, multiple choice, and so on). It describes how the templates are built rather than how workers responded, so it helps template designers see whether the forms lean on open text or structured inputs. A format that dominates may be worth reviewing if you want richer or more analyzable answers.
Word cloud - Answers from free text questions	Frequency of each word across the free-text answers (word size = how often it appears)	A visual tally of the words workers and managers typed into free-text plan questions, with more frequent words shown larger. It surfaces recurring themes in qualitative answers at a glance, without anyone reading every response. To be treated as a directional cue, not a metric: common filler words can dominate, and it shows word frequency, not sentiment or meaning.
Distribution of answers for multiple choice questions with drill-down	Count of chosen answer-options÷ total count of all chosen answer-options (in view), shown per question, drilling down to per answer-option	Share that each multiple-choice option represents out of all option selections, so you can see how workers answered the closed questions. At the top level bars are grouped by question; drilling into a question breaks it out by individual option, showing which choices dominate. Because it is a percentage of the total in view, filtering to a team or plan re-bases the shares to that selection, letting you compare answer patterns across groups.
word cloud - answers for multiple choice questions	Count of times each answer-option was chosen, per option (word size = number of selections)	Each multiple-choice option shown as a word, sized by how often workers picked it, so the most-chosen answers stand out at a glance. It is the structured-answer counterpart to the free-text word cloud: instead of tallying typed words, it tallies option selections, so every word is a real predefined answer rather than loose text. Larger words mean more popular choices across the plans in view.
Compensation (26)
Avg. salary increase	Average salary-increase percentage across workers who have a salary proposal	Average size of the proposed increase, as a percent of current salary, over workers who actually have a proposal (others excluded). It summarizes how generous increases are on average and re-bases when you filter to a team, job family, or grade. Read against Median increase to see whether a few large increases pull the average up. Counts workers, not users.
Median increase	Median salary-increase percentage across workers who have a salary proposal	The middle increase, so half of workers with a proposal get more and half less. Less sensitive to outliers than the average, so a gap between the two signals skew. Read against Avg. salary increase to gauge how lopsided the spread is.
Salary increase tiers	For each increase percentage band, count of workers in the band÷ total count of workers	Share of workers falling into each salary-increase band, so you see how increases are distributed rather than just their average. Bands come from the source data. Read against Avg. salary increase and Median increase for the center of that distribution. Counts workers.
Min. increase	Lowest salary-increase percentage among workers who have a salary proposal	The smallest proposed increase in view, as a percent of salary; can be negative if any proposal cuts pay. It marks the bottom of the range. Read against Max. increase for the full spread.
Max. increase	Highest salary-increase percentage among workers who have a salary proposal	The largest proposed increase in view, as a percent of salary. It marks the top of the range. Read against Min. increase for the full spread.
Average % Salary increase by job family / category	Average salary-increase percentage among workers with a proposal, split by job family and job category	Average proposed increase for each job family and category, so you can compare across the job structure. Same average as Avg. salary increase, broken out by the job hierarchy. Read against the overall Avg. salary increase to spot families above or below the norm.
Total salary increase amount by job level	Sum of the global salary-increase amount, split by job category and job level	Total money added to salaries by the proposed increases, broken down by job category and level as a running build-up. Unlike the percentage cards, this is an absolute amount converted to a single global currency. Read against Total proposed bonus amount for the two halves of the reward spend.
Average % Salary increase by job level / grade	Average salary-increase percentage among workers with a proposal, split by job level and grade	Average proposed increase for each job level and grade, so you can compare up and down the leveling structure. Read against the overall Avg. salary increase to spot levels above or below the norm.
Total proposed bonus amount	Sum of the proposed bonus amount across workers	Total value of proposed bonuses for the population in view, in local currency. It sizes the bonus spend in absolute terms and re-bases when filtered. It sums local-currency amounts, so mixing currencies across the selection can distort the total. Read against Total salary increase amount by job level for the two halves of the reward spend.
Average proposed % bonus	Average proposed bonus percentage across workers	Average proposed bonus, as a percent, over the population in view, independent of headcount. Read against Proposed bonus vs. On-Target Bonus (OTB) to see how proposals sit relative to target.
Proposed bonus vs. On-Target Bonus (OTB)	Count of workers, split by whether their proposed bonus is below, at, or above on-target bonus	Number of workers whose proposed bonus falls below, at, or above their on-target bonus, shown as shares of the workforce. It reveals whether the round funds bonuses above or below target. Read against Average proposed % bonus for the magnitude behind the split. Counts workers.
Min. proposed % Bonus	Lowest proposed bonus percentage among workers	The smallest proposed bonus percentage in the population in view, the bottom of the bonus range. Read against Max. proposed % Bonus for the full spread.
Max. proposed % Bonus	Highest proposed bonus percentage among workers	The largest proposed bonus percentage in the population in view, the top of the bonus range. Read against Min. proposed % Bonus for the full spread.
Avg. salary inc. % job level and performance rating	Average salary-increase percentage among workers with a proposal, by job level and performance rating	A matrix of the average proposed increase for each job level crossed with each performance rating, so pay increases can be read against both level and performance. Same average as Avg. salary increase, split two ways. Read against Average % Salary increase by job level / grade for the level-only view.
Bonus allocation overview by org. level	For each org unit: worker count, bonus spend, on-target bonus, and the min, average, and max proposed bonus percentage	A matrix breaking bonus proposals down by org unit, showing headcount, proposed bonus amount and its share of total spend, on-target bonus (OTB), and the spread (min, average, max) of proposed bonus as a percent of OTB and of salary. A per-unit view of how the bonus budget is distributed. Read against Total proposed bonus amount for the organization-wide total.
Workers with Proposal (count)	Count of distinct workers who have a proposed salary	Number of workers with a salary proposal entered (a non-blank proposed salary). It tracks how far the round has progressed. Read against Managers with No Proposals (count) for who still owes proposals. Counts workers.
Workers having proposal	For each proposal status (has a salary proposal or not), count of distinct workers ÷ total workers	Share of workers who have a salary proposal versus those who do not, shown as a donut whose two slices sum to 100%. It gives the proposal-coverage split at a glance and re-bases when filtered to a team, job family, or grade. Read against Workers with Proposal (count) for the absolute number of workers with a proposal.
Top 5 managers with most pending proposals	Count of workers without a salary proposal, by manager, keeping the five highest	The five managers with the most direct reports still lacking a salary proposal, for targeted follow-up. Read against % Workers having proposals by line manager for each manager's rate. Counts workers grouped by manager.
Managers with No Proposals (count)	Count of managers who have entered no salary proposals	Number of managers who have submitted no proposals for their reports yet. Read against % Managers with no proposals for the same as a rate. Counts managers.
% Managers with no proposals	Count of managers with no salary proposals÷ count of all managers	Share of managers who have entered no proposals, the manager-side completion gap. Read against Managers with No Proposals (count) for the count. Denominator counts managers.
% Workers having proposals by org level	For each org level, count of workers with a salary proposal÷ workers in that org level	Proposal-coverage rate per org unit, so laggard units are visible. Read against % Workers having proposals by line manager for the manager view. Counts workers.
% Workers having proposals by line manager	For each manager, count of their workers with a salary proposal÷ their workers	Proposal-coverage rate per manager. Read against Top 5 managers with most pending proposals for the absolute backlog. Counts workers grouped by manager.
% Workers by performance rating	For each performance rating, count of workers with that rating÷ total count of workers	Distribution of workers across performance ratings. Read against % Salary increase by performance rating to see how increases track with performance. Counts workers.
Pay range penetration (before review)	For each performance rating, count of workers in each pay-range-penetration band, using pay before increases	Distribution of workers across pay-range penetration bands (below, within, above range) by performance rating, on current pay before the round's increases. Read against Pay range penetration (after review) for the effect of the proposed increases. Counts workers.
Pay range penetration (after review)	For each performance rating, count of workers in each pay-range-penetration band, using pay after proposed increases	The same pay-range-penetration distribution recomputed with the proposed increases applied. Read against Pay range penetration (before review) for the before/after comparison. Counts workers.
Workers having bonus proposal	For each proposal status (has a bonus proposal or not), count of distinct workers ÷ total workers	Share of workers who have a bonus proposal versus those who do not, shown as a donut whose two slices sum to 100%. It gives the bonus-proposal coverage split at a glance. Read against Workers having proposal for the salary-side equivalent.
Pay Equity (EUPTD) (16)
Category Compensation Range	Count of distinct workers in the selected category	Number of workers making up the selected worker category, the population the category pay comparison rests on; a small count means the averages and distances rest on few people. Read against Average by Compensation Component and by gender for the pay levels computed over this group. Counts workers.
Distance	Average of each worker's pay distance from the category average, the male average, and the female average	How far a worker's compensation sits, in currency terms, from three reference points: their category average, the male average, and the female average. Positive means paid above the reference, negative below. Read against % Distance for the same gaps as percentages.
% Distance	Average of each worker's pay distance from the category, male, and female averages, expressed as a percent of that average	The same three gaps as Distance but as a percent of each reference, so they compare fairly across pay levels and currencies. Positive means above the reference, negative below. Read against Distance for the gaps in currency terms.
Average by Compensation Component and by gender	For each compensation component and worker category, average compensation for the category overall, for men, and for women	Average pay per component (base salary, bonus, and so on), broken out by worker category and shown side by side for the whole category, men, and women, so gender gaps are visible component by component. Read against % Distance for how far individuals sit from these averages.
# Male Workers	Count of distinct male workers in the category	Number of male workers in the selected worker category, the male sample behind the pay-gap figures. Read against # Female Workers for the gender balance. Counts workers.
# Female Workers	Count of distinct female workers in the category	Number of female workers in the selected category, the female sample behind the pay-gap figures. Read against # Male Workers. Counts workers.
% Unadjusted Pay Gap (Baseline: Male) by compensation component / worker category	For each compensation component and worker category, the unadjusted pay gap versus the male average	The raw (unadjusted) gender pay gap for each pay component and worker category, measured against the male average as baseline, as a percentage; positive means women paid below men. Unadjusted means no controls for role or level. Read against % Median Pay Gap (Baseline: Male) by compensation component / worker category for the median-based view.
% Median Pay Gap (Baseline: Male) by compensation component / worker category	For each compensation component and worker category, the median pay gap versus the male median	The gender pay gap based on medians rather than averages, per component and category, against the male baseline; medians reduce the pull of a few very high or low earners. Read against % Unadjusted Pay Gap (Baseline: Male) by compensation component / worker category for the mean-based view.
Averages and Unadjusted Pay Gap per Compensation Element and by category of worker	For each component and worker category: worker count, average pay overall, for women, for men, and the unadjusted pay gap	A table pairing average pay (overall, female, male) with the unadjusted gender pay gap for every compensation component and worker category, plus the headcount behind each. It is the detailed backing for the unadjusted-gap chart. Read against the medians table for the median-based equivalent.
Medians and Median Pay Gap per Compensation Element and by category of worker	For each component and worker category: worker count, median pay overall, for women, for men, and the median pay gap	The median counterpart of the averages table, pairing median pay (overall, female, male) with the median gender pay gap per component and category, with headcount. Read against the averages table for the mean-based view.
Key distribution metrics per compensation element and by category of worker	For each component and worker category, the minimum, 25th percentile, median, 75th percentile, and maximum category pay	The pay distribution for each component and worker category, from lowest to highest with quartiles and median, so the spread and skew of pay are visible. Read against the averages and medians tables for the gap figures over the same groups.
Compensation amount break down by gender and worker category	For each compensation component, the worker's own pay alongside the category, male, and female averages	For the selected worker, their pay in each component shown next to the category, male, and female averages, so their position against each benchmark is visible component by component. Read against Worker Vs Average Category Compensation Amount for the single-benchmark bar views.
Worker Vs Average Category Compensation Amount	The worker's compensation next to the category average	Compares the selected worker's pay with the average for their worker category. Read against % Distance for the same gap as a percentage, and the male/female comparison bars for the gendered benchmarks.
Worker Vs Average Male Compensation Amount	The worker's compensation next to the male average	Compares the selected worker's pay with the male average for their category. Read against Worker Vs Average Female Compensation Amount for the gender benchmarks side by side.
Worker Vs Average Female Compensation Amount	The worker's compensation next to the female average	Compares the selected worker's pay with the female average for their category. Read against Worker Vs Average Male Compensation Amount.
Worker compensation compared to key Category distribution metrics	For each component, the category minimum, median, average, and maximum pay	Plots the category pay distribution (minimum, median, average, maximum) across compensation components, so the selected worker's pay can be read against the full range. Read against the key distribution metrics table for the quartile detail.
Pay Communication (13)
Total number of communication rounds	Count of distinct communication rounds	Number of pay-communication campaigns in scope, each distributing documents to workers. It sizes how many cycles the figures cover and re-bases when filtered. Read against Total number of documents by comm round for how many documents those rounds produced.
Total number of documents	Count of documents (one per pay-communication document)	Total number of pay-communication documents in scope (pay statements or letters). It is the base for the release, unrelease, and read shares, and re-bases when filtered. It counts documents, not workers (usually one document per worker per communication).
Total documents not released	Count of documents whose status is Not Released	Number of documents never yet released to their recipient, the backlog still to go out (status code 2). Read against Total documents released to gauge how much has been delivered. Distinct from Unreleased (retracted) documents.
Total documents released	Count of distinct documents with status Released	Number of documents delivered to their recipient; measures delivery progress in absolute terms. Read against Total documents not released and Total documents unreleased for the full status split.
Total documents unreleased	Count of distinct documents with status Unreleased	Number of documents that were released and then pulled back, leaving them Unreleased (status code 1); separate from Not Released (never sent). Read against Total documents released for the share later retracted.
Total number of documents by comm round	Count of distinct documents, split by communication round	Number of documents produced in each round, so round sizes can be compared. Read against Total number of communication rounds for the count of rounds behind the bars.
Released status by comm round	For each communication round, count of documents in each status÷ documents in the round	Share of documents in each status (Released, Unreleased, Not Released) within every round, on a like-for-like 0 to 100% scale. Read against Total number of documents by comm round for the absolute counts.
Read status by comm round (released documents)	For each communication round, count of released documents in each read state÷ released documents in the round	Share of released documents read versus not read within each round; tracks engagement once delivered. Read against Released status by comm round for delivery versus readership.
Workflow step by comm round	For each communication round, count of documents at each workflow step÷ documents in the round	Share of documents sitting at each workflow step within every round, showing where documents are in the process. Read against Released status by comm round for how stage maps to release status.
Read status (unreleased documents)	Count of documents in each read state, limited to unreleased documents	Split of unreleased documents by whether they have been read, shown as shares. Read against Read status by comm round (released documents) for the released-side comparison.
Document creation by date	Count of distinct documents, by creation date	Number of documents created over time, tracing when documents entered the system. Read against Documents released over time to compare creation with delivery.
Documents released over time	Count of distinct documents released, by date	Number of documents released over time, tracing delivery progress by day. Read against Document creation by date and Documents read over time for creation versus release versus readership.
Documents read over time	Count of distinct documents read, by date	Number of documents read by recipients over time, tracing engagement by day. Read against Documents released over time for release versus readership.
Average Wait Time for Not Released	List of documents with recipient, round, status, workflow step, read state, creation/release/read dates, and per-document action counts	One row per document showing its recipient (worker, job, org), round, status, workflow step, read state, key dates, and how many times it was released, unreleased, read, or overridden. It is a detailed export table for audit and drill-down, not a single average. Despite the title, no average wait-time figure is computed here.
Right to Information (RTI) (33)
# Right to information (RTI) requests	Count of RTI requests	Total number of right-to-information requests in scope, each one a worker's ask to see their pay data. It is the base for the status and deadline breakdowns and re-bases when filtered. Read against # Open RTI requests and # RTI requests closed for the split. Counts requests.
RTI Request Details	List of RTI requests with their worker, manager, org, request status, deadline status, due date and remaining days, communication round, document name and release/read status	One row per right-to-information request, giving the full drill-down: who raised it and their org and manager, the request and deadline status, the due date and days remaining, and the associated document and its release/read state. It is a detailed export/audit table for case-by-case follow-up, not a computed metric.
# Open RTI requests	Count of RTI requests whose status is open (New, In Progress, or Pending document release)	Number of requests still being worked and not yet closed. Read against # RTI requests closed for the open-versus-closed split.
# Closed RTI requests	Count of RTI requests whose status is Closed (intended)	Meant to show how many requests are closed. As built the card is bound to the alphabetically first cost center, not a count, so it shows a cost-center value (see flag). Read against # Open RTI requests once corrected.
Document not released	Count of RTI requests whose pay document has not been released	Number of requests where the pay document has not yet gone out to the worker. Read against Document released for the released-versus-not split.
Document released	Count of RTI requests with status Closed	Number of requests where the pay document has been released to the worker (mapped to Request Status Closed). Read against Document not released for the split. The "released" label mapping to status Closed is worth confirming.
Open RTI request by deadline status	Count of distinct open requests, split by deadline status (Before warning, Warning, Overdue)	Distribution of open requests across their deadline urgency. Read against # Before Warning, # Warning, and # Overdue for the individual counts.
Closed RTI request by deadline met	Count of closed requests resolved before the deadline versus after	Split of closed requests by whether they were resolved within the response deadline. Read against Closed before deadline and Closed after deadline for the counts.
RTI requests remaining days (Warning and Overdue)	Requests with their remaining days to respond (table on Overview, scatter on the Deadline Monitor)	Shows each warning or overdue request and how many days remain (negative once overdue), so you can triage. It is a monitoring list/plot, not a single figure. Read against # Overdue for how many are past due.
# New RTI requests	Count of RTI requests with status New	Number of newly received requests not yet started. Read against # Open RTI requests for the open pipeline.
# RTI requests pending document release	Count of RTI requests with status Pending document release	Number of requests approved and waiting for the document to be released. Read against Document released for how many have gone out.
# RTI requests closed without document	Count of RTI requests with status Closed without document	Number of requests closed without a document being provided, for example rejected or withdrawn. Read against # RTI requests closed for the closed-with-document comparison.
# RTI requests closed	Count of distinct RTI requests with status Closed	Number of requests resolved and closed. Read against # Open RTI requests for the open-versus-closed split.
% RTI Requests unreleased at least once	Count of distinct requests split by whether their document was ever unreleased, as shares	Share of requests whose document was pulled back at least once. Read against Document released for the delivery picture.
RTI request status by country	For each work country, count of distinct requests in each release status÷ requests in the country	Share of requests in each release status per country. Read against # Open RTI requests by country for the absolute open counts.
# Open RTI requests by country	Count of distinct open requests, split by work country	Number of open requests in each country. Read against RTI request status by country for the status mix.
RTI request status by org unit	For each org unit, count of distinct requests in each release status÷ requests in the unit	Share of requests in each release status per org unit. Read against # Open RTI requests by org unit for the absolute open counts.
# Open RTI requests by org unit	Count of distinct open requests, split by org unit	Number of open requests in each org unit. Read against RTI request status by org unit for the status mix.
Open right to information (RTI) requests	Count of open RTI requests (intended)	Meant to show how many requests are open. As built the card is bound to the alphabetically first cost center, not a count, so it shows a cost-center value (see flag). Use # Open RTI requests for the correct figure meanwhile.
RTI requests received over time	Count of RTI requests, by creation date	Number of requests received over time, tracing inflow by day. Read against # Right to information (RTI) requests for the total.
# Before Warning	Count of open requests whose deadline status is Before warning	Number of open requests still comfortably before their warning threshold. Read against # Warning and # Overdue for the deadline pipeline.
# Warning	Count of open requests whose deadline status is Warning	Number of open requests approaching their deadline (warning window). Read against # Before Warning and # Overdue.
# Overdue	Count of open requests whose deadline status is Overdue	Number of open requests past their response deadline. Read against # Warning for those about to breach.
# RTI requests during warning period	Count of open requests whose deadline status is Warning	Same population and filter as # Warning (identical definition, see flag). Read against # Overdue.
Closed RTI requests	Count of closed RTI requests (intended)	Meant to show how many requests are closed. As built the card is bound to the alphabetically first cost center, not a count, so it shows a cost-center value (see flag). Use # RTI requests closed for the correct figure meanwhile.
Closed before deadline	Count of closed requests resolved within the response deadline	Number of closed requests that met their deadline (within SLA, request status closed). Read against Closed after deadline for the on-time rate.
Closed after deadline	Count of closed requests resolved after the response deadline	Number of closed requests that missed their deadline (past SLA). Read against Closed before deadline.
RTI request deadline status by country	For each work country, count of distinct requests in each deadline status÷ requests in the country	Share of requests by deadline urgency per country. Read against # Overdue for the overall overdue load.
RTI request deadline status by org unit	For each org unit, count of distinct requests in each deadline status÷ requests in the unit	Share of requests by deadline urgency per org unit. Read against RTI request deadline status by country for the country view.
Document release status	Count of distinct RTI requests, split by document release status	Number of RTI requests in each document release status (released, unreleased, and so on), so the release mix is visible at a glance. Read against RTI request status by country for the same split across countries.
Workflow step status	Count of distinct RTI requests, split by workflow step	Number of RTI requests sitting at each workflow step, showing where requests are in the process. Read against Document release status for the release-status view.
# Active Workers with RTI requests	Count of distinct workers who have raised an RTI request	Number of individual workers who have submitted at least one right-to-information request; a worker with several requests is counted once. Read against # Right to information (RTI) requests for total request volume. Counts workers.
% Active Workers with RTI requests	Count of distinct workers with an RTI request÷ count of active users	Share of the workforce that has raised an RTI request. Read against # Active Workers with RTI requests for the count. Numerator counts workers (Employee Id) while the denominator is active users, so the two sides mix populations (see flag).
# RTI requests in progress	Count of RTI requests with status In Progress	Number of requests currently being worked (status In Progress). Read against # Open RTI requests for the full open pipeline and # New RTI requests for not-yet-started ones. Counts requests.