HR guidance is usually a tour of screens. The screens are not the hard part; the hard part is deciding how accrual pro-rates for a part-year joiner before somebody invents an answer in the moment.
These are written around those decisions, with the configuration second and the edge cases named rather than implied.
Sequenced, not alphabetised. Each one ends with something configured.
Each of these ends up at the same place: write the rule down before the first exception arrives, because the invented answer becomes precedent and nobody can say what the policy is two years later.
Payroll and leave policy are the two where that matters most, which is why both guides spend more time on the decision than on the software.
Permissions is the quiet one. Access granted for a report and never removed is how people data leaks internally, and it is invisible until somebody audits it.
Every guide is written to be finished rather than to be impressive: the screen each decision happens on, and the thing that goes wrong if you skip it.
Nest tools →If you are implementing, read setting up payroll first and follow the order in it. Entering people before components exist is the most common cause of a bad first run.
If you are already live, read permissions for people data. It is the one most teams have never audited.
No. They are written to be useful against whatever you run today. Several describe decisions that apply to any nest-shaped system, not just ours.
Each has an owner and a review date. Where something has changed, the guide is updated rather than supplemented, so there is one current version rather than a thread of corrections.
Because the limits are the useful part. A guide that recommends everything is a brochure, and the decisions worth taking care over are usually the ones with a real cost either way.
Half an hour with your own data usually saves reading three of these. The guides will still be here afterwards.