beqom PaySuite 28.3 - Feature release notes
This article details the latest improvements introduced in version 28.3 of the beqom PaySuite application, their benefits for our end-users, and their principles of use.
Compensation Management
Default sorting for the Planner
So far, the Planner grid has loaded rows in a fixed order, and changing the arrangement of workers has meant reordering them by hand at the start of every session. Compensation administrators can now define a default row order per actor in the Actors & round access step under Workbench > Compensation Management > Compensation Rounds. A new Default sorting option enables configuring up to three sort criteria drawn from columns visible to a given actor, dragging these criteria into order, and previewing the result live. Planner > Compensation then loads already arranged to that default.
The HRBP, Compensation Manager, Compensation Advisory, and Auditor roles keep full control from there. A Sort drawer in the toolbar allows criteria to be viewed, added, removed, or reordered, with a one-click Reset to default. Clicking a column header sorts the grid by the column, with each further click cycling it between ascending, descending, and no sort at all. The personal sorting applied holds across round tabs for the session, and reverts to the actor's default on re-entry or when the actor changes through View as. This removes the repetitive re-sorting often associated with large populations, while still letting an administrator decide how a population is presented by default, such as performance rating first and salary second within it. The configuration is also copied automatically with round duplication. Changing the default on a round already published requires a new draft, so an existing round is not altered outright.
Default sorting tab for the compensation manager direct
Sort drawer with two active criteria and the option to add more
Demo
Configurable decimal precision for Planner widgets
Planner widget values have always rounded to whole numbers, regardless of what they represent. A new Decimal display precision field is available for Widgets under Workbench > Compensation Management > Compensation Rounds > Team planner view and for Planner widgets & validation within Workbench > Compensation Management > Compensation Rounds > Budget. It accepts a whole number from zero to eight and defaults to zero. Both the Preview in the widget form and the widget's rendering in Planner > Compensation update immediately to reflect it.
Every value the widget shows, including budget, spend, and the Sum and Average figures, follows this setting, though Count is displayed as a headcount and Utilization % keeps its existing format. Rounding happens only at the final step, on the number actually shown, never earlier in the calculation. This preserves the true meaning of metric widgets such as average scores or per-head figures, rather than rounding them away. In addition, it lets two widgets built over the same budget definition show different levels of detail. The setting affects display only: aggregation, currency conversion, and budget validation stay unchanged. Therefore, a spend of 30,000.4 against a budget of 30,000 still counts as over budget, even if a widget set to zero decimals shows both numbers as 30,000. Existing widgets remain set to zero decimal places, so their rendering does not change after the upgrade. Locale-specific separators for decimals and thousands are also unaffected.
Decimal display precision field in a widget's configuration
Demo
Help tip on Planner widgets
With this release, administrators can attach a short explanation to any Planner widget, shown as an information indicator in the widget's title.
We have added a Help tip toggle and text field to the Edit widget drawer in Widgets under Workbench > Compensation Management > Compensation Rounds > Team planner view and to Planner widgets & validation within Workbench > Compensation Management > Compensation Rounds > Budget. With the toggle enabled, a note of up to 100 characters is required, and the Preview reflects unsaved edits before they are applied. The help tip is set per widget entry rather than per widget type, so two widgets built from the same budget definition can carry different text or none, and it displays identically to everyone regardless of language. The indicator then appears on the widget in the Planner > Compensation, in both collapsed and expanded states, with a note visible on click. Because the wording stays under administrator control and can differ per widget, whoever views the widget can see what it aggregates and how to read it without needing external documentation.
Help tip toggle and text field in the widget editing panel
Widget help tip as a note in the Planner
Demo
Planner widgets updated with Refresh data
The Refresh data button in the Planner > Compensation toolbar has updated the worker grid without touching the widgets displayed alongside it, leaving the two out of step until the page was reloaded in full. Currently, it re-reads every rendered widget together with the grid, across every widget type, so both stay aligned without a full reload.
Each widget refreshes independently, so the fastest one shows its new numbers without waiting for the others. Filters, worker search, Browse by selection, and the selected currency are preserved throughout. The refresh also brings in anything entered by others or added through a republish. If a widget cannot refresh, it simply keeps showing its last known values instead of a zero, and it does not block the grid or the other widgets. The refresh remains read-only and stays within each role's existing access scope, introducing no new visibility.
Refresh data button updating all visible budget widgets at once
Demo
Performance Management
Worker list drawer for Talent Review 9-box cell
In Planner > Talent Review, the 9-box grid has shown how many workers sit in each cell, but not who they are, so identifying everyone captured there, including the additional workers folded into a crowded cell's summary bubble, has required leaving the grid altogether. Any populated cell can now be opened directly to reveal a drawer with a full list of workers placed in it.
The resulting view lists every worker in that cell by name, status, organization, and country, and works independently on both grids of a dual-grid template, since each places workers by its own pair of axes. What appears reflects the placement rules already governing each view: on the manager side, only direct reports rated on both axes are shown, with a status that tracks the manager's own progress, while on the HRBP side the same list is scoped to a given HRBP's population, with HR ratings taking precedence and an inherited manager rating standing in until one is provided. Rather than trusting the raw count alone, a manager or Talent HRBP can see who sits behind a category and its distribution before drawing a conclusion from the grid.
The view remains available once a review has closed, so a distribution can still be checked afterward; only the status labels shown in it change. It is read-only throughout, so ratings and other calibration actions still happen elsewhere. A cell with no workers in it, for example because of a search or manager filter, simply cannot be opened.
Worker list opened from a 9-box grid cell
Talent Review questionnaire questions targeted at HRBPs
Until now, a question on a Talent Review template belonged to the manager alone. In version 28.3 of the application, template owners can target a question at the Talent HRBP instead, or at both roles together. This way, each role sees and answers exactly what belongs to it throughout the review.
In the Questionnaire step within Workbench > Performance Management > Talent Review Templates, the existing Response permission field on a question, previously left to default, is now a mandatory choice between Manager, HRBP, and Manager & HRBP. It still defaults to Manager, and everything else about a question, its text, answer type, mandatory flag, and translations, is configured the same way regardless of which role it targets. A question can be added to an already published template, though it only reaches the live review once republished, and once a question exists on a published template its response permission is locked to protect answers already submitted against it.
In Planner > Talent Review, a manager sees every question on the template but can only answer Manager questions and the manager's half of a shared one; HRBP questions stay hidden behind a label until the review closes, and a shared question shows only the HRBP role rather than a name. A Talent HRBP correspondingly sees the manager's submitted answers alongside HRBP and shared questions, can answer only the HRBP side, and finds any still-unsubmitted manager answer withheld until it is submitted. Submission is validated against each role's own mandatory questions only, so an unanswered HRBP question never blocks a manager, and an unanswered manager question never prevents an HRBP from submitting.
Once an HRBP submits a worker, the manager can no longer edit or submit that worker's questionnaire, though the manager's own earlier answers, or any draft never submitted, remain visible only to the manager, marked as not submitted. After the process itself closes, both roles see the full set of questions and answers from either side, read-only, and the HRBP's identity becomes visible to the manager for the first time. Where more than one HRBP works the same process, an HRBP question keeps a single shared answer rather than one per HRBP, editable by whichever HRBP opens it until someone saves a change, at which point authorship transfers to them. This lets calibration capture the HRBP's own judgment directly in the review record alongside the manager's, rather than only in a separate channel, while keeping each side's input hidden from the other until it is appropriate to reveal it.
Response permission options on a Talent Review question
Manager view of a questionnaire with HRBP answers hidden
HRBP-only questionnaire fields on a worker's Talent Review
Total goal count in the Manager dashboard
The Goals column under Planner > Manager dashboard has given a manager five status icons to scan, but never a total, so a direct report's overall count had to be worked out by hand. That total now appears directly ahead of the five icons, calculated automatically every time the column loads.
The total follows the same eligibility rules already applied to the five counters: individual goals owned by the direct report, in the Pending approval, In progress, or Completed status, whose period has not yet fully ended, aggregated across all qualifying goal plans. Organizational and well-being goals are excluded. A direct report with no eligible goals displays a total of zero, alongside all five icons at zero. It appears on a manager's own dashboard and, read-only, on the dashboard of anyone further down their reporting line. As a result, a manager gets a quick sense of a direct report's overall goal load before looking into the breakdown behind it, without any change to how the five status icons themselves are counted or displayed.
Goal breakdown from the Manager dashboard total
Per-tenant Manager dashboard toggle
Not every tenant runs performance management: some rely on the platform for compensation only, where the Manager dashboard's performance figures in the Planner serve no purpose. With this release, administrators can switch the page on or off at tenant level from Workbench > Platform Setup > Feature Enablement, matching how the Home and Compensation toggles already work.
The setting is enabled by default, so nothing changes unless an administrator turns it off, and doing so takes effect on a manager's next refresh or navigation, without requiring a new session. Where it is disabled, a manager lands on the next active Planner page instead, and the Manager dashboard no longer appears in navigation at all, keeping the experience limited to what is actually relevant to that tenant.
Manager dashboard toggle in Feature Enablement
Longer Measurement criteria descriptions on goals
Five hundred characters has rarely been enough to state a measurable outcome together with its conditions and thresholds, especially next to neighboring fields on the same form that allow 10,000. The Description field on a Measurement criteria entry currently accepts up to 5,000 characters, closing most of that gap.
The limit applies per Measurement criteria entry, so one using its full allowance does not reduce what is available to any other entry on the same goal, and it holds consistently across individual and organizational goals, in both Passport > Goals and Planner > Goals, as well as on the Workbench > Performance Management > Goal Management page. Existing descriptions saved under the previous limit display unchanged and can be extended, and a long description now renders in full wherever it is read back, on the goal view page and in a generated PDF alike, with no truncation or show-more control breaking up the text. This way, workers, goal creators, managers, and Goals professional users have room to state an outcome in one place, instead of compressing it to fit an arbitrary limit or splitting it across other fields not meant to hold it.
Character counter on the Measurement criteria Description field
Pay Transparency
HTML rendering in template variable values
A template variable value has been printed as it was sent, so a value containing HTML markup showed the raw tags on the page instead of the formatting they described.
Version 28.3 of the application renders this markup instead of printing it. Rather than as the literal tags, a value carrying paragraph breaks, bold text, or similar formatting appears exactly that way in the resulting document. This applies wherever a document is produced, during generation, in preview, and in the check that validates templates on publish, for example in Planner > Pay Information or Workbench > Pay Transparency > Templates. The rendering reaches values nested inside objects or repeated inside a table or list, not only a top-level variable. Supported formatting covers common needs, for instance paragraphs, line and section breaks, bold, italic, underline, strikethrough, headings, lists, tables, links, and basic text styling. Anything that could act as a script or an unsafe link is stripped out before rendering. This lets the substance of a letter carry its own formatting, such as a bolded figure or a note broken into paragraphs, without relying on a workaround built into the template itself.
Nothing changes for a value with no HTML tags. It reaches the document as before, including any ampersand, angle bracket, or line break it contains, with no configuration or migration needed to keep it working.
Other and Unknown gender aggregates in pay information letters
Article 7 of the EU Pay Transparency Directive calls for gender pay reporting that goes beyond a simple male and female split. In PaySuite, the pay information letter's aggregated figures have covered only those two categories, alongside the totals for each worker category.
New placeholders for worker counts and compensation averages now cover Other ({{category_count_other}}) and Unknown ({{category_count_unknown}}) gender categories as well, built the same way as the Male and Female placeholders. They are available within any worker category a template uses to group its figures. Averages can be drawn from the same three compensation sources already supported: contracted, paid, or historical compensation. The application rounds and formats them according to the tenant's own number settings, just as it does for the existing averages. This gives a template the fuller gender breakdown that Article 7 calls for, without introducing a separate calculation model alongside the one used for Male and Female.
A worker with no compensation value recorded is left out of the average entirely, while a worker whose recorded compensation is zero is still counted toward it. Where a category has no workers at all in a given gender, its count returns as zero and its average as blank (NULL), rather than as a false zero. None of this affects a template that does not use the new placeholders: existing Male, Female, and category-level totals calculate as before, and the new figures appear only once a template is edited to include them.
Authorization
Security groups with access control lists
Previously, a security group's data scope was defined only through broad attributes such as country, organization, or legal entity.
With this release, a security group can carry an explicit list of Worker IDs, known as its access control list (ACL). An integration can create a security group together with that list, update the list later, and retrieve an individual security group to review the list currently configured on it. Users are then assigned to that security group through the same flows already used for any other security group, including assignment through the API. Once an ACL-based worker population is in place, it works in any product or authorization flow that already supports security groups, without a separate integration path.
A security group carries only one kind of data scope at a time: either the existing attribute-based scope or an access control list, never both together. When a security group is evaluated, its list determines the worker population available to the users assigned to it, and updating that list replaces it outright rather than adding to what was already there.
Access control list security groups are created and maintained entirely through the Security Group APIs, and the worker list configured on a given group can be retrieved through the individual security group retrieval endpoint.
This enhancement provides precise control over which workers a security group's users can reach for populations that attribute-based scoping alone could not represent. It lets a worker population maintained in an external system be synchronized directly into PaySuite instead of recreated manually. It also keeps the role and worker population together within the same security group authorization model already used elsewhere.