1. Users
User Management is where logins are created, reset and retired.
Creating a user
-
Add User
Create the login itself.
-
Link it to the employee record
This is the step that is easy to skip and expensive to skip. Everything self-service — My Attendance, My Payslips, applying for leave — works from the employee behind the login. A login with no employee attached is not broken in an obvious way: those screens simply come back empty.
-
Grant roles
On User Roles. Grant the job, not the person — see the next section.
-
Hand over the password and require a change
Tell them to change it on first sign-in.
Retiring a user
When somebody leaves, deactivate the login the same day. The list can be filtered to active, inactive or all, and it opens on active — so deactivated logins are out of the way without being deleted, and their history stays intact.
A deactivated login fails exactly like a wrong password. That is deliberate — the sign-in page must not tell a stranger which accounts exist. But it means "my password is not working" from a returning employee is often not a password problem at all. Check whether the login is active before resetting anything.
Deactivating a login is not the same as recording a leaver. The login controls access; the employee record controls whether payroll pays them. Do both. A deactivated login whose employee record still says active can still be paid.
2. Who can see what
Access is granted to roles, and roles are given to users. Grant the job, not the person: when somebody changes position you move one role instead of auditing a list of individual permissions.
| Screen | Decides |
|---|---|
| User Roles | Which roles a person holds. |
| Menu Access Control | Which menus a role gets — and therefore what appears in the sidebar and as home-page tiles. |
| User Access | Per-user access where a role is not the right unit. |
Hiding a menu is not the same as denying access — and here it does both. In many systems a removed menu just hides the link, and anyone with the address still gets in. In ZakERP the screens, reports, charts and calendars are gated at their own addresses as well, so a copied link does not become a back door. Grant deliberately anyway: a permission you did not mean to give is not made safe by the menu being hidden.
Checking your work
The reliable test is not reading the grants — it is looking at the result. After changing somebody's access, have them sign out and back in, and check that the sidebar and home tiles show what you intended. Home-page tiles are generated from the menus actually granted, so they are an honest mirror of the grant rather than a second list to maintain.
3. Document numbers
Leave applications, purchase orders, payslips and the rest get their numbers automatically from numbering rules. Each rule sets a prefix, how many digits, and whether the counter restarts at the start of a year or a month.
Changing a prefix does not renumber what already exists. Existing records keep the numbers they were given, so from that point the table holds two shapes. That is usually acceptable — but decide it deliberately, because it cannot be undone by changing the prefix back.
If a counter is ever behind the records that already exist — after a data import, most often — use Sync to highest existing, which advances it past everything already in use. Never lower a counter by hand into a range that is already occupied; the system will refuse it, and it is refusing for a good reason.
4. The work calendar
The work calendar records which days are non-working: weekly offs and holidays. It is generated per year, and several things quietly depend on it.
- Leave applications answering "Include Holiday = No" need it, because without it the system cannot know which days inside a range to skip. It refuses the application rather than guessing.
- Attendance statuses use it to mark weekends and holidays instead of absences.
- Annual leave accrual depends on it.
Generate next year's calendar before the year starts. This is the single most common seasonal support call, and it always arrives as something apparently unrelated — a leave application refused in the last week of December, for dates in January. Put it in your December checklist.
5. Customisation Studio
The Studio is where you change what the system does without writing code: new fields, new screens, new reports, new dashboards.
Two habits make it safe.
-
Change it where it does not matter first
Build on a test installation, confirm it does what you meant, then move the change across. The Studio exports a set of changes as a bundle and imports it on the other server, so this is a copy rather than a retype.
-
Review before you apply
The Studio will show you what a change will do before it does it. Read that screen — it is the difference between a five-second check and an afternoon of undoing.
Resist customising in month one. The instinct is to make the new system behave exactly like the old spreadsheet. Some of those habits exist for good reasons; many exist only because the spreadsheet could not do better. Run standard for a month, keep a list, then build the third of it that turns out to matter.
6. Traps worth knowing
Employees carry the department by name. Renaming one leaves the people behind. If a department must be renamed, plan to update the employees with it.
Every leave request from that employee goes to the wrong person, and the employee is told the wrong name when they apply. Fix it on the employee record — never by asking someone else to approve informally.
Face-matched punching fails repeatedly against an old, dark or low-resolution photo, and it will be blamed on the system every morning until the photo is replaced.
One live session per user means two people on one login knock each other out — and every action either takes is recorded under one name. Refuse the request; issue a second login.
Duplicate employees, leavers still active, suppliers spelled four ways. Nothing warns you, and every transaction quietly inherits the mess. Ten minutes a month beats a clean-up project a year in.
7. A monthly routine
Half an hour, once a month, prevents most of what otherwise arrives as an emergency.
-
Confirm the backup actually ran
Not that it is scheduled — that it ran, and that the file is where you think it is. An untested backup is a belief, not a backup.
-
Reconcile logins against people
Every active login should be a current employee; every current employee who needs the system should have one, linked to their employee record.
-
Look for stuck approvals
Requests sitting at one level for weeks usually mean an approver who has left, changed role, or does not know they are one.
-
Scan attendance exceptions
Repeated Incomplete days for one person usually means a device that will not read their finger, not a person who never goes home.
-
In December, generate next year's work calendar
See section 4.