Roster attributes and cuts

Roster attributes let you cut a poll's results by department, location, tenure band and manager without asking respondents any of those questions. You import the values from the headcount spreadsheet the organisation already keeps, they're attached to each person's ballot when you send it, and once the poll has closed, your browser can filter results by them behind the same floor that guards every other cut: five, or the poll's minimum group size if that's higher; use them when the self-reported version is unreliable, or when four demographic questions would eat a fifteen-question survey.

Good to know

The only new thing the server learns is a department beside an email it already held, in a table our own operations role can't read. The link it must never have, response to person, still doesn't exist; what changes is what your browser can do with the results, and that's where the floor does its work.

#When to use it

A consultant running an engagement against a client's real org chart, not against how people describe their own team.
A pulse where "which department are you in" gets a different answer from the one HR would give.
Any survey where the questions are precious and four of them shouldn't go to demographics.
A recurring series where you want the same cuts every wave without re-asking.

If you'd rather ask respondents, the self-reported route is Demographic cohorts and minimum thresholds. The two are separate dimensions and never merge; a roster cut is labelled "Department (roster)" so you always know which claim you're reading.

#Importing a roster

Attributes ride a contact list. When you create a list from a CSV, the dialog reads the header row and looks for four columns.

Department from a header reading department, dept, team, division, business unit or function.
Location from location, site, office, country, city, region or workplace.
Tenure band from tenure band, tenure, length of service, service band or years of service.
Manager from manager, line manager, reports to, supervisor or manager name.

A sheet with no header row has no attributes. Guessing which text column is a department would silently mislabel a whole roster, so the dialog doesn't. Every match is shown on the review step, where a line like "department: 6 values · location: 3 values · tenure band: 5 values · manager: 14 values" tells you what it found, followed by the note that a group smaller than five stays out of any chart.

Two rules at import:

Tenure band is a label, not a date. The dialog suggests a vocabulary ("< 1 year", "1-2 years", "2-5 years", "5-10 years", "10+ years") and doesn't enforce it. Band it in your spreadsheet before you import. We don't take a hire date because a date is more sensitive than the band, and we don't need it.
A manager is a name. A manager cell that looks like an email address is skipped and the review step names the row. A manager's address would sit inside ciphertext an admin can hand to someone outside the workspace, so it's refused rather than carried.

Values are trimmed, capped at 80 characters, and matched case-insensitively. "Engineering" and "engineering " are one group, displayed with the casing seen first.

#What happens when you send

Roster attributes are attached at send time, and only on email magic-link distribution. That's the one method with a per-recipient ballot to attach anything to. Access codes are deliberately not tied to an address, and an open link has no recipient at all, so on those polls the distribution panel says: "Roster cuts need email magic links. Access codes aren't tied to an address on purpose, so there's no ballot to attach a department or a manager to."

Before anything is attached, the roster you're sending to is collapsed so that no combination of values can point at one person. This is the part worth understanding, because it's where the protection lives.

Why "minimum five" on its own isn't enough. The floor of five stops a chart from showing a group of four. It does nothing about a combination. If one person on the roster is the only one who is in Legal, in Dublin, with more than ten years, reporting to Chen, then a chart of Legal is fine, a chart of Dublin is fine, and the response that carries all four values together is still one identifiable person to anyone who can read responses individually. Four authoritative attributes make a much sharper fingerprint than four self-reported ones, because HR picked them.

Why it has to happen before sealing. A ballot, once encrypted in the respondent's browser, can't be reopened by anyone but a key holder and can't be re-sealed by us at all. Whatever protection exists has to be applied before the ciphertext is written, or it doesn't exist.

So at dispatch, over the roster being sent to:

Each attribute is checked on its own. Any value shared by fewer than five people on the roster is dropped from everyone who has it. A department of three vanishes as a department.

Then the combination is checked. If the full set of values on somebody's ballot would be shared by fewer than five people, the least useful attribute is dropped from those people, in a fixed order: manager first, then tenure band, then location, then department. The count is redone and the step repeats until every non-empty combination is shared by at least five.

A dropped value is simply absent. It's not replaced by "Not reported", because a "not reported" bucket is itself a group, and it's exactly the group of people whose real value was too rare to show.

The floor is counted over the roster you're sending to, not over who eventually answers. That's the only set known at send time. It composes correctly with the floor on the chart: a department of six where two people answer gives a group of two, which the results page then refuses to show.

Right after sending, a message tells you what the collapse did. Either "Roster attributes attached to 38 of 40 ballots. Groups smaller than five are left out so nobody can be picked out of a chart", or, if nothing survived, "No roster attributes were attached. Every group was smaller than five, so nothing could be sealed without making somebody identifiable." You find out now, not three weeks later when a cut is empty. Sending to one person at a time, as an exit pool usually does, attaches nothing, because a roster of one can't clear five.

A resend hands the same person the same values, even if you've edited the roster since. One employee never appears under two departments in one wave.

#What respondents see

Nothing new. The attributes travel to the respondent's browser with their ballot and are sealed into the encrypted response there, beside the answers. They're not shown, not editable through the form, and never sent to us in readable form. The response record on our side is still ciphertext with no timestamp and no link to a person.

#Cutting results by roster

Breakdowns only appear after the poll closes. While it's collecting, the results tab says when they unlock, with the date: "Breakdowns by group unlock when this poll closes on [date]." We hold them until then because comparing a group before and after new responses arrive could reveal one person's answers. An always-on poll, such as an exit pool or a speak-up channel, never shows them.

Once the poll has closed and your browser has decrypted its results, the results tab offers Filter by roster beside any demographic filters, with one selector per attribute that actually arrived. A dimension nobody carries isn't offered, because the roster was collapsed before sealing and only the decrypted responses know what's left.

Each roster dimension shows a coverage line: how many of the responses in view carry a value for it at all. Without that number a department chart summing to 32 of 40 reads as eight people who didn't answer, which is a different and wrong story. The eight had a value too rare to keep.

A cut below the poll's cut floor (five, or its minimum group size if higher) stays locked, with no count. The same floor as a self-reported cohort, on a new path, tested separately. At close, every cut is also checked once against the poll's release batches, and one that could be worked out by subtracting others is withheld the same way, with no reason given. You'll see "Checking breakdowns" while that runs.

At close every answer is released, so a roster cut covers the whole final group. How batched release works.

Share a slice doesn't carry a roster filter yet. If you open the dialog with a roster cut active it says so and starts from all responses. Before close, it shares the whole result only. Roster cuts reach outsiders through the published document instead.

#The cut catalog

When you publish results after the poll has closed, the signed document carries a fixed catalog of cuts, computed in the same pass from the same decrypted responses that drew your charts. A document published while the poll's open carries no cuts, so republish after close to add them. The catalog holds:

One cut per value of each roster attribute present.
One cut per option of each self-reported demographic question on the poll.
Three standard pairs: department by location, department by tenure band, and location by tenure band. Manager is in no pair. A manager already sits inside a department, so the pair adds nothing a single cut doesn't say, and manager pairs would almost never clear the floor.
A coverage cut per dimension, over every response carrying any value for it.

Every cut clears the poll's cut floor and the same batch check as the results tab. A cell that doesn't is left out entirely rather than marked, for the same reason a dropped value is absent rather than bucketed. The catalog is trimmed to a fixed cap of cuts if a roster is very large, so one document degrades instead of failing to publish.

There is no ad hoc slicing in the document. Your live filter stays in your browser; the catalog is what leaves it.

#Why a cut can be missing

The poll hasn't closed yet, or it's an always-on poll (an exit pool or a speak-up channel), which never shows breakdowns.
Fewer people in that group among the responses than the cut floor (five, or the poll's minimum group size if higher). The chart is locked, or the cut isn't in the catalog.
The batch check withheld it, because it could be worked out from other cuts. No reason is shown.
The value was dropped at send time, because fewer than five people on the roster shared it or shared the combination it was part of, or because the ballot was sent to one person on their own.
The poll was sent by access code or open link, so nothing was attached.
The person wasn't on the contact list you sent to, so their ballot carried no attributes.
The catalog reached its cap. Cuts are trimmed in a stable order, so the same responses always give the same catalog.

#Across waves of a series

Each wave attaches the roster as it stood when that wave was sent. Somebody who moves from Support to Engineering between wave 2 and wave 3 counts in Support for the first two and in Engineering from the third. Nothing else is possible: an earlier wave's ballots are sealed and can't be rewritten, and suppressing "movers" would need to know which response moved, which is the link that doesn't exist.

What you get instead is an honest caveat. Every send stamps a fingerprint of the collapsed roster, and on the series trend page a wave whose roster differs from the previous wave's carries the note: "The roster changed between this wave and the one before it, so some people are counted under a different department, location or manager." The first wave never carries it, and a wave that attached no roster isn't read as a change.

#Limits and gates

Magic-link distribution needs an active plan or trial, so roster cuts do too.
Four attributes, fixed. No custom columns.
Email magic links only. Access-code and open-link polls attach nothing and say so.
Breakdowns appear only after the poll closes, and never on an exit pool or a speak-up channel.
The floor of five applies at send time over the roster. Every chart and catalog cut needs five, or the poll's minimum group size if that's higher. Neither can be lowered.
Values are capped at 80 characters; a manager that looks like an email address is refused.
A respondent's sealed values aren't authenticated. Someone could edit their own before submitting and move their answer between two groups that both already clear the floor. That's the same property self-reported demographics have always had.
Attributes on lists synced from Slack come only from what a CSV supplies.

See also Aggregate results and anti-inference controls. Each page covers the adjacent settings and workflow steps.