Integrations for performance
The performance engine can score work that happens outside the HRM: pull requests and code reviews on GitHub, and support tickets in WHMCS. This page covers connecting both, mapping their logins to your employees, and the triage tools built on top.
Everything here lives under Admin → Integrations (/admin/integrations). The whole surface — including background polling — is available only on plans that include the performance feature.
Connection setup (credentials, repos, polling) needs company.settings. Anything that decides whose ledger points land in — linking identities, triaging flagged reviews, voiding scores — needs performance.manage instead. The seeded HR Manager and Super Admin roles hold both.
GitHub
Open Admin → Integrations → GitHub (/admin/integrations/github).
- Paste a personal access token with read access to the repositories you want tracked. The token is encrypted at rest and never shown again — the page displays a masked value.
- Pick the repositories to track from the list the token can reach.
- Optionally mark a subset as AI-graded: for those repos the reviewer's written comments (never the code) are also sent for a text-quality grade — catching rubber-stamp approvals and claims that don't match the changed files.
- Test the connection, then leave polling to the hourly cron or press Poll now.
What gets scored per repository:
| Signal | Points behavior |
|---|---|
| Merged pull request | Author credit, scaled by a difficulty estimate from the change size (lockfiles and vendored files excluded). |
| Code review | Timeliness against the review SLA × a depth factor. A requested review that misses its SLA entirely records a penalty — reversed if the review eventually lands. |
| Voluntary review | Reviewing without being asked never scores below half credit and can never go negative, no matter how old the PR is. |
| Rescue review / merge | Stepping in for an unresponsive assigned reviewer earns bonus credit. |
| Issues worked / closed / commented | Never scored — surfaced only as attachable evidence for daily reports. |
A PR nobody touches never updates, so it would normally fall out of the polling window. The poller separately re-scans every open PR that still has outstanding review requests, so a request that is simply ignored earns its no-show penalty once the SLA lapses.
WHMCS
Open Admin → Integrations → WHMCS (/admin/integrations/whmcs).
- Enter the API URL of the install (its base address). It must be a public
https://address — local hostnames, raw IPs, and internal domains are rejected, because the server calls this URL on a schedule. - Enter the API identifier and secret (and the optional access key, if your install requires one). All three are encrypted at rest.
- Set the WHMCS timezone — see below.
- Optionally enable AI grading: the replying agent's own messages (never the customer's) are graded for reply quality.
The scored signal is the first staff reply on each ticket: response speed against the WHMCS SLA, times the AI quality grade when enabled. Later replies surface as attachable daily-report evidence but are not scored.
The WHMCS timezone setting
WHMCS reports timestamps in whatever time zone its PHP configuration uses — not UTC, and not necessarily your workspace's time zone. This field tells the HRM how to read them.
To find the right value: open any recent ticket in the WHMCS admin and check a reply's displayed time. If it shows the actual local wall-clock time the reply happened, enter that zone (e.g. Asia/Karachi). If it shows a time offset from local reality, the install is writing a different zone — enter that one. If WHMCS is genuinely writing UTC, leave the field empty: empty means "read as UTC."
With the wrong value, response-time windows shift and replies get grouped under the wrong day — evening tickets can show up on the next day's report suggestions, and the incremental poll can miss tickets entirely for installs behind UTC.
Linking identities to employees
Open Admin → Integrations → Identities (/admin/integrations/identities). Every GitHub login and WHMCS agent username the polls encounter appears here, initially unlinked. Nothing is scored for an unlinked identity — its events wait, parked.
Link an identity to an employee and the backlog of parked events is scored immediately and attributed to them. Matching is case-insensitive, so login-case differences can't strand events. Only active (non-deleted) employees can be linked; unlinking stops future attribution but never rewrites history already on the ledger.
Flagged reviews and the void
When AI grading is on for a repo, reviews the AI judged as rubber_stamp, unsubstantiated, or inconsistent queue up under Admin → Integrations → Flagged reviews (/admin/integrations/github/flagged-reviews) for a human decision.
Each row shows the review, the AI's note, documented test cases, and the points earned. If you agree the review didn't merit its score, Void score appends a reversing ledger entry (after a confirmation — the ledger is append-only, so a void is itself a visible record, not an erasure). Rows already voided are labelled.
This is the same appeal principle as the daily-report verdict override: the AI proposes, a person decides, and every correction leaves a trail.
Polling and reliability
Both integrations poll hourly (plus the manual Poll now buttons). Requests time out rather than hang, a rate-limited GitHub token pauses the run instead of hammering the API, and one broken repository doesn't stop the others. Connection pages show the last poll time and the last error, if any.