How a screen works

Every screen in PeopleNest is built the same way. Learn the pattern once and you can work a screen nobody has trained you on.

There are more than two hundred screens. Nobody learns two hundred screens. What people learn is this page, and after that each screen is only a different set of fields in a shape they already know.

A header, and lines below it

Nearly every screen has two parts.

The header is the top of the screen: the things that are true of the whole document. On a leave request it is the person, the leave type and the dates. On a salary structure it is the structure's code and name.

The lines are the grid underneath: the many things inside the one. The days of a shift pattern. The wage types in a salary structure. The employees on a roster. The rate bands of a contribution scheme.

Some screens have more than one grid, each on its own tab, because a document can have more than one kind of line. A salary structure has one grid for the wage types a person gets and another for the accounts each of those wage types posts to.

The header comes first and the lines are keyed after it. On some screens the header is what produces the lines: fill in the header, save, and the lines appear ready to be edited rather than typed from nothing.

The document number fills itself

A screen that produces a document has a number, and you do not type it. The number is given to the document when you first save it, from the numbering set up for that screen. Until then the field sits empty or shows that it will be filled.

This is why you cannot reserve a number in advance, and why two people keying at the same time never collide: the number is taken at the moment of saving, not at the moment of opening.

Setup screens behave differently. A wage type, a department, a leave type: those you name yourself, because the code is meaningful and you will be reading it for years. Pick the code carefully, because changing it later means changing everything that points at it.

Fields that are filled for you

Some fields are not yours to type. Three kinds:

Filled from the thing you just picked. Choose an employee and his name appears beside his number. Choose a wage type and its description appears. These are there so the grid reads like a sentence instead of a row of codes. Leave them alone.

Filled from a record elsewhere. Several screens read a default from the record you have named and put it in front of you, so that a position can carry its usual salary structure and an assignment can start from it. Where that happens the screen page for that screen says so, field by field.

Filled and locked. A field that the screen has worked out cannot be overtyped, because overtyping it would make the document disagree with itself. If a field is greyed and you believe it should not be, do not look for a setting on the screen first. Which fields are mandatory, disabled or hidden is itself configured, per company, and a locked field is usually locked on purpose.

Fields you pick from a list

If a field points at something that exists elsewhere in the system, you do not type it, you pick it. The field opens a list of what is already set up, you search it, and you choose.

This is the single most useful habit to teach an HR officer. An empty list is not a broken screen. An empty list means the thing you are trying to pick has not been set up yet, and the answer is to go and set it up, not to find a way of typing it in.

Many of those lists only offer records that are finished and live. A department that has been keyed in but not released will not appear in the list of departments, which is why a consultant who keys everything in and releases nothing finds that none of it can be used.

Dates: how a change keeps the history

PeopleNest does not overwrite. When something about a person or a policy changes, the old version is closed on a date and a new version opens the next day. Last year's payslip is still explainable, because the record it was calculated from is still there.

You will meet the pattern in two shapes.

Date From and Date To. This is the common one. The Employee Organization Assignment is the clearest case. A person's department, position, grade, salary structure and policy profile all sit on an assignment with a Date From and a Date To, and every module that needs any of them reads the assignment covering the date it is asking about. The assignment a person is on right now is the one with no Date To.

So a transfer or a promotion is not an edit. It is a new assignment starting on the day the move takes effect. You do not have to close the old one by hand: saving the new one closes the previous one on the day before. Two rules protect the history:

• A Date From earlier than the person's joining date is refused.
• A Date From cannot be moved into a stretch of time that payroll has already been run for.

Effective From and Effective To. A few screens hold rates that change over time and keep every rate on its own line, each with the dates it applies between. Contribution Scheme works this way: when the employee share goes from 5 percent to 6 percent, you close the 5 percent line and add a 6 percent line from the next day. Two lines covering the same date are refused, because a run that found two rates would have no way of choosing.

Either way, the instinct to resist is "just change the number". Changing the number silently rewrites history.

Saving, and releasing

Saving and finishing a document are two different acts.

Save writes what you have keyed. The document exists, it has its number, and you can come back to it. A saved but unreleased document is a draft: it is not yet offered to the lists other screens pick from, and no run will read it.

Release says the document is finished. That is the point at which it starts to count. Several setup screens also carry an Active tick of their own, and a run will generally only look at a record that is both released and ticked active. You will hear the phrase "ready to process" in configuration conversation: that is the system's own name for the released state, not a tick you have to find.

That distinction is worth labouring with a client, because it explains the two commonest complaints during an implementation. "I set it up and the payroll ignored it" is almost always a document that was saved and never released. And "it let me save rubbish" is usually true: many checks fire on release rather than on save, precisely so that a half-keyed document can be parked.

Posting is not the same as releasing. Posting is specific to payroll, it happens on its own screen, Post Payroll, and it is the act of handing the month's totals to the accounts. A payroll can be run, looked at, and discarded. Once it is posted, the accounting entry exists, and undoing it means a reversal with its own date rather than a deletion.

What approval does

If a screen has an approval route configured, releasing the document does not finish it. It sends it.

1. You release the document. It goes out to whoever the approval route names for that screen and that action.
2. They see it in their inbox and approve, reject or hold it.
3. A stage clears when enough of its approvers have approved. More than one person can sit on a stage, and the route decides how much each of them counts for.
4. When the last stage clears, the document becomes live, and only then does anything else happen because of it.

That last step is the one that surprises people. The work the document causes happens at approval, not at save. An approved leave request is what writes the leave against the person; the request on its own changes no balance. A rejected document stays on the screen, with its rejection, and causes nothing.

Approval is configured per screen and per action, so a client can require approval to create a record but not to change it, or the other way round. A screen with no route configured goes live the moment you release it.

If something looks wrong

• "The list is empty when I click the field" - what you are trying to pick has not been set up, or has been set up and not released.
• "I filled it in and saved it and the run ignored it" - the document is still a draft, or it carries an Active tick that was left unticked.
• "It will not let me change this date" - payroll has already been run across that date. Correct it with a new dated record instead.
• "The field is greyed out and I need it" - field behaviour is configured per company. It is a setting, not a defect, and not something to work around on the screen.
• "He approved it but nothing happened" - check whether the route has a later stage still waiting. The document only acts when the last stage clears.