AWRA OpsHub Search
Beginner Certificate on pass

HR: Employee Management

Build the foundation of HR: employee records that are separate from user logins, with departments, positions, an org chart, contracts, documents with expiry reminders, bulk import, and optional login provisioning and de-provisioning.

4 lessons 40 min 5-question assessment 75% to pass

What you’ll learn

  • Explain why an employee record is not the same as a user account, and when to link one
  • Create, organise, and bulk-import employees with departments, positions, and managers
  • Manage contracts, documents with expiry, contacts, compensation, and payout details
  • Provision a login for an employee and safely disable it when employment ends

Course content

4 lessons · 40 min of reading
01
Lesson 1 of 4 Reading 9 min

Employees are not user accounts

The single most important idea in AWRA HR is that an employee record and a user login are different things. An employee is a first-class record of a person you employ — their identity, role, pay, and history — and it exists whether or not that person ever signs in to the app. A user account is a credential that lets someone log in and do work. Most of the people an organisation employs (field staff, cleaners, drivers, casuals) never need an account, so forcing "employee = user" would be both wasteful of seats and wrong about how work actually happens.

Keeping them separate has concrete consequences that run through the whole module. You can run leave, attendance, and payroll for someone who has no login at all. One human can be an employee in your organisation and, say, a vendor contact somewhere else, without those identities colliding. And an employment change — suspending, terminating, or rehiring — never silently flips someone's access, because access is a deliberate, separate decision. When an employee is linked to a login, that link is one-to-one: a single account maps to at most one employee record.

Practically, you begin in Human Resources → Employees, which lists everyone with search, status filters, and counts. Each person carries an employee number and can be tied to a department, a position (with a grade), and a manager. Reaching for "just give them a login" as the first step is the classic beginner mistake; the right instinct is to create the employee record first and only provision access later, for the few who need it. Hold that model — record first, login maybe — and the rest of HR falls into place.

Key takeaways

  • An employee record is independent of a user login; most staff never need an account.
  • You can run leave, attendance, and payroll for employees with no login at all.
  • Employment status changes never automatically change a linked login — access is a separate decision.
  • When linked, the employee↔login relationship is one-to-one.
02
Lesson 2 of 4 Reading 8 min

Structure: departments, positions, and the org chart

Structure is what turns a flat list of names into something you can manage and, later, roster and pay correctly. Departments group people by function and are reused from the wider platform, so HR does not invent a parallel list. Positions are job titles carrying a grade, and they feed the employee form so you assign a consistent title rather than free-typing one. Both are light to set up but pay off everywhere downstream — filtering the register by department, rostering a team, or reading a headcount by function.

The reporting line is modelled by giving each employee a manager, who is simply another employee. Because that relationship points from a person to their manager, AWRA can walk it in both directions: a manager's direct reports, and the whole tree beneath them. The org chart, reached from the Employees header, draws that tree with a depth guard so a bad loop cannot run away. It is the fastest way to sanity-check that your reporting lines are what you think they are before you rely on them for approvals.

A useful discipline is to set department, position, and manager at the moment you create someone, not "later" — because later is where data quality goes to die. These three fields are cheap to fill in during onboarding and expensive to backfill across a whole workforce. When you import in bulk (next lesson), department and position are matched by name, so agreeing on those names up front keeps the import clean.

Key takeaways

  • Departments are reused from the platform; positions are titles with a grade that feed the employee form.
  • Each employee can have a manager (another employee), which defines the reporting line.
  • The org chart is drawn from manager relationships, with a depth guard against loops.
  • Set department/position/manager at creation time — bulk import matches department and position by name.
03
Lesson 3 of 4 Practice 11 min

Contracts, documents, and sensitive details

A profile holds more than identity. Employment contracts record type, start and end dates, a basic salary, currency, and terms — and that basic salary is the figure payroll uses later, so contracts are not just paperwork, they are an input to money. An employee can have more than one contract over time; the active one is what counts. Documents attach to either the employee or a specific contract, each with an optional expiry date, and AWRA sends reminders before a document lapses so an expiring work permit or certificate does not quietly slip past.

Two further record types round out the person. Contacts capture emergency contacts and next of kin. Compensation and payout details capture the allowance/benefit/deduction package and the bank or mobile-money account a salary is paid into — and because those are sensitive, the account numbers are encrypted at rest and only ever shown in full through a single, audited "reveal" for users who hold the specific permission; everywhere else they appear masked. Statutory identifiers (a tax PIN, social-security, and health number) are stored per the employee's work country, not hard-coded to one country.

The practical workflow is to treat the profile as the system of record and keep it current: attach the signed contract as a document, set expiry dates on anything that renews, and enter payout details once so payroll can use them. The reason to be disciplined here is that everything downstream trusts it — payroll reads the contract and payout account, and the expiry reminders only help if the dates are actually filled in.

Key takeaways

  • A contract's basic salary is the figure payroll uses; the active contract is what counts.
  • Documents attach to an employee or a contract and can carry an expiry date with reminders before lapse.
  • Bank/mobile-money numbers are encrypted and shown in full only via a single audited reveal; elsewhere masked.
  • Statutory identifiers are stored per the employee's work country, not fixed to one country.
04
Lesson 4 of 4 Practice 12 min

Bulk import and provisioning access

To onboard many people at once, use Import. You download a template, fill it in, and upload it for a dry-run preview that validates every row — flagging unknown values and within-file duplicates — before anything is written. The commit is deliberately all-or-nothing and transactional: if any row is invalid, nothing is imported, so you never end up with a half-loaded workforce that you then have to reconcile by hand. Departments and positions resolve by name and a blank employee number is generated, which is why agreeing names beforehand matters.

When a specific person genuinely needs to sign in, provision a login from their profile's System Access card. This follows the platform's convention: it creates an account with a random password and a must-change-password flag, emails a welcome, links the account to the employee, and lets an admin pick the role — with guards for a valid email, no existing link, the plan's seat limit, and email uniqueness. It is a deliberate act for the few who need access, not a default for everyone.

Offboarding closes the loop. Terminating an employee can automatically disable the linked login and force an immediate sign-out, using the same active/inactive flag and session mechanism the platform already enforces — a checkbox on the status change lets you opt out for the rare case where you want to keep access briefly. Crucially, AWRA does not auto-re-enable a login when you undo a termination; re-granting access is a separate, deliberate step, so access never silently returns.

Key takeaways

  • Bulk import previews and validates every row; the commit is all-or-nothing so a bad row imports nothing.
  • Provisioning a login is per-person and guarded (email, seat limit, uniqueness) — not a default.
  • Terminating an employee can auto-disable the linked login and force sign-out (opt-out per action).
  • Access is never auto-restored on undoing a termination — re-granting is a separate deliberate step.

Finished the material?

Take the 5-question assessment and earn your certificate — 75% to pass.

Take the assessment

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center