How to read the answers

hackÜ’s tools hide nothing, but several of their fields look like they say something simpler than they do. This page collects the cases where a hurried reading reaches the wrong conclusion — all of them verified against real data, not hypothetical.

A survey is shared between companies

list_surveys returns the surveys used by your company’s courses, but the survey itself is a shared object: the same survey can sit in the courses of several companies at once.

get_survey_results returns two numbers for that reason: responses (your company’s) and responses_all_companies (all of them). A real case: survey 679 has 15,359 responses from 6 companies, and only 11,318 belong to the largest of the six. Each question’s percentages are always calculated on the first number. Reporting the second one as if it were your company’s is reporting somebody else’s result.

Reviewed is not approved

In list_challenges, reviewed and approved are different things: reviewed means somebody looked at it; approved means they passed it. A challenge that was reviewed and not approved is a rejection, not something pending — it is already closed. Counting it together with the pending queue inflates the work that is left.

For “what do I owe the team”, filter by reviewed=false, or ask for include_summary=true to get the full breakdown in a single call.

“No evidence” is not “it did not arrive”

list_communication_deliveries returns per-provider flags (whatsapp_sent, whatsapp_delivered, whatsapp_read, whatsapp_failed, sms_sent) that are not mutually exclusive: the provider raises one without lowering the others, so the same row can end up marked several ways at once.

Real numbers, from a single campaign

• 39,151 rows are failed and delivered at the same time.
• 66,854 rows are failed and read at the same time.
• 69,535 rows are read without being delivered.

no_evidence — the send process closed and the provider never reported anything, neither success nor failure — is usually the largest group of all. It is not the same as failed, and it is not the same as delivered.

The groups overlap: adding them up does not give you the total number of recipients. Only recipients (with include_breakdown=true) is a real total. And subtracting failures from sends, the formula the dashboard uses, is not a real delivery rate either — the tool says so in its own description.

Seats: above 9,999 there is no configured limit

get_company_overview reports membership.unlimited_seats. When it is true, the seat number stored in the database is a placeholder, not a plan — do not quote it as if it were the company’s real limit.

0% progress in a pensum with no courses does not mean “nobody started”

get_pensum calculates enrolment.average_progress from the courses the pensum has configured. A pensum with no courses keeps the last value it had stored instead of recalculating — so a 0% there can mean “nothing configured”, not “nobody started”. Check pensum.courses before reading the number.

has_progress_data: false is unknown, not zero

In list_users and get_user, when hackÜ has not yet calculated a person’s progress, has_progress_data comes back false and the status is no_data. That is unknown, not 0% progress — they are different claims, and the second one is an accusation the data does not support.

Passing an evaluation depends on the evaluation

passed, in list_evaluation_attempts and get_evaluation_attempt, is the platform’s verdict according to that particular evaluation’s minimum score. Someone can get 4 out of 5 questions right and still not pass if that evaluation asked for more. You cannot recalculate passed by counting correct answers — you have to read it from the field.