HRPortal, end to end.

A single deployment of HRPortal serves many vendor companies at once. Each company is a tenant, and every record a tenant owns is tagged with that tenant’s id, so one company can never see another’s people, projects, or timesheets.

The heart of the product is a strict, server-enforced state machine. A timesheet moves through a fixed set of statuses, and who may move it — and when — is decided on the server. The interface only ever shows the actions you are actually allowed to take; it can never be tricked into skipping a step.

Two rules hold throughout: a week is editable only while it is a draft or has been sent back, and any exception hours (extra time or PTO) must carry a written comment before the week can be saved or submitted.

Everyone signs into the same workspace, but what they see and may do depends on their role. A role is assigned by an institution admin (or HR manager) and re-read from the database on every request, so a change takes effect immediately.

A timesheet always sits in exactly one status. The forward path runs from draft to a fully approved invoice; at the two review steps it can instead be sent back, which returns it to the employee for correction.

Open a week from the dashboard to reach its grid. Each row is one day, split into three hour columns:

• Regular — standard hours worked on the project.
• Extra — overtime or extra-time hours. Requires a comment.
• PTO — paid time off such as vacation, sick, or holiday. Requires a comment.

Whenever you log Extra or PTO hours, an exception-comment box appears for that day. The week cannot be saved or submitted until every exception has a comment — the same rule the server enforces, mirrored in the grid so you catch it instantly.

Save draft stores your progress and keeps the week editable. Submit for approval first saves, then advances the week to Submitted and hands it to your client manager. The optional Submission notes field carries general context to your approvers.

Approval happens in up to two steps, and reviewers only ever see the weeks that are theirs to act on.

Client managers review submitted weeks for their projects. They either Approve as manager, advancing the week to Client Approved, or Send back with a required reason, which returns it to the employee as Sent Back.

Client HR gives the final Approve invoice on client-approved weeks. This is the terminal step: the week becomes Invoice Approved and locks permanently. HR can also send a week back if something is wrong.

A reason is always mandatory when sending back, so the employee knows exactly what to fix before resubmitting.

The Admin console is open to institution admins and HR managers. It has three areas:

• Users — add people directly or invite them by email, change roles, and activate or deactivate access. HR managers can manage everyone except other admins.
• Settings — the institution profile plus timesheet rules: the approval workflow (single or dual approval) and invoice reconciliation preference.
• Audit — a running, read-only trail of significant actions, each stamped with who did it and when.

Invitations carry a single-use token link; a recipient sets their own password when they accept. Every meaningful change is recorded in the audit trail, for example:

Passwords are stored only as a salted scrypt hash, never in plaintext. A successful sign-in establishes a sealed (encrypted) session cookie that holds just your user id; your role and tenant are re-read from the database on every request, so access changes apply at once.

Multi-factor authentication protects institution admins. After accepting an invitation, an admin must enter a 6-digit code emailed to them before they are signed in. Codes are hashed, single-use, expire after ten minutes, and allow at most five attempts.

Authorization is never trusted from the browser. Every workflow action re-checks, on the server, both that the timesheet belongs to your tenant and that your role may take that action.

Onboarding and workflow events — invitations, MFA codes, password resets, and every timesheet status change — are sent through a provider-agnostic email service with version-controlled templates.

When no email provider is configured, messages are still rendered and recorded with a logged status rather than delivered, so preview deployments work without any secrets. Configuring a provider in the environment switches the same messages to real delivery, no code change required.

HRPortal runs on managed Postgres. Every tenant-owned row carries a tenant id, and reads are always constrained to the signed-in user’s tenant. A request for a record outside your tenant simply returns not found — the platform never confirms that another tenant’s data even exists.

The schema is the single source of truth for the relational model, and it only ever evolves forward through generated migrations. Existing, applied migrations are immutable; corrections always roll forward as new ones.

The fastest way to explore every role is the built-in demo tenant. On the sign-in screen, choose Load demo data to seed a sample company (Northwind Consulting) with users, projects, and timesheets — it is safe to run more than once. Then pick any demo account to step into that role; the shared password is shown on the page.

Each demo account lands in a workspace tailored to its role: an employee sees their own weeks to fill in, a client manager sees weeks awaiting review, and an admin sees the institution console.