An employee self-service portal is a signed-in internal web application where staff manage their own HR and routine requests: leave, expenses, personal details, payslips, documents and announcements. Plan it by choosing two or three request types to build first, designing roles and approval chains that the server enforces, protecting salary and personal data with stricter rules, and rolling out to a pilot group before the whole company.
Most employee portals start from a simple irritation: HR and managers spend hours answering the same questions and chasing approvals that live in email threads, WhatsApp messages and paper forms. The portal promises to fix that, and it can, but only when three things are right. The modules match the requests people actually make. The permissions match how your organisation is really structured, including its exceptions. And the rollout gets people to use it instead of reverting to email in the second week. This guide covers those three, in order. If you want to see how we approach a build, our employee portal development page covers scope, integrations and ownership.
Start from requests, not from a feature list
Collect a month of real requests before choosing modules. Ask HR, finance, IT and a sample of managers to list what they are asked and how often. The count is what justifies a module. Typical results:
- "How many leave days do I have left?" (very frequent, low complexity)
- "I need to take leave next week" (frequent, needs approval)
- "Can I get a salary certificate or employment letter?" (occasional, template plus approval)
- "I need to claim an expense" (frequent in some teams, needs receipts and finance approval)
- "Where is the policy on X?" (frequent, solved by documents and search)
- "I changed my address or bank account" (occasional, sensitive)
- "I cannot log in / I need equipment" (IT requests, may belong in an IT tool)
Rank them by volume times the effort to handle them manually. The top two or three form the first release.
Modules, with what each needs underneath
| Module | What staff do | What it needs underneath | Usually first? |
|---|
| Profile and directory | View and update their details; find colleagues | A staff master record, reporting lines, a change-approval rule for sensitive fields | Yes: everything else depends on it |
| Leave | See balances, request leave, see team calendar | Leave types and accrual rules, public holidays by location, approval chain, delegation | Yes |
| Expenses and claims | Submit with receipts, track status | Categories and limits, receipt storage, approval chain, export to finance | Often |
| Payslips and pay documents | View and download | Read-only feed from payroll, strict access, no editing | Often, if payroll can export |
| Attendance and timesheets | Clock in, submit timesheets, correct mistakes | Shift rules, device or location input, correction approval, export to payroll | If attendance is a daily pain |
| Documents and policies | Read policies, download forms, acknowledge | Versioned library, search, read receipts, owner per document | Often cheap and popular |
| Letters and certificates | Request employment letters | Templates with merge fields, approval, audit | Occasional |
| Onboarding and offboarding | New joiner tasks, leaver checklist | Task lists across HR, IT and facilities, due dates, owners | After the basics |
| Announcements and surveys | Read news; answer short polls | Targeting by site or department, read tracking | Anytime |
| Asset and equipment requests | Request and return items | Asset register, approval, handover record | Later |
| Performance and goals | Set goals, run reviews | Cycles, forms, calibration, strict visibility | Later: process must exist first |
A pattern to note: payroll calculation is not in the list. The portal sends approved data (leave taken, expenses approved, hours worked) to the system that pays people. Rebuilding payroll inside a self-service portal is a different and much larger project, and a ready-made payroll product may already cover it.
Permissions: model the organisation you actually have
A common mistake is to define four roles (employee, manager, HR, admin) and assume the problem is solved. Real organisations need more.
Roles and scope
Separate what a role may do from whose records it applies to.
| Role | May do | Scope |
|---|
| Employee | View own records; submit requests; cancel a pending request | Self only |
| Line manager | Approve leave and expenses; view team calendar and balances | Direct and indirect reports |
| Department head | View department summaries; approve above manager limits | Department |
| HR officer | Manage records, policies and leave balances; view sensitive data | Assigned sites or all |
| Finance approver | Approve expenses above a limit | Cost centres they own |
| Payroll officer | View pay documents; run exports | All, read-only |
| IT administrator | Create and disable accounts; manage settings | No access to HR content |
| Auditor | View audit log and reports | Read-only, all |
Scope matters as much as role. A manager must see her team and not the next team. The scope comes from the reporting structure in the staff master record, so that record has to be accurate and has to change when someone moves teams. Mark when a change takes effect, because a manager who has left a team should lose access from that date, not when someone remembers.
Approval chains
Write each chain as a table before it is built.
| Request | Step 1 | Step 2 | If the approver is away | If it waits too long |
|---|
| Annual leave up to a limit | Line manager | None | Delegate named in advance | Reminder, then escalate to department head |
| Annual leave above a limit | Line manager | HR | Delegate, then HR | Escalate to HR |
| Expense up to a threshold | Line manager | Finance | Delegate | Reminder to approver |
| Expense above threshold | Line manager | Department head, then finance | Delegate | Escalate |
| Change of bank details | HR (with identity check) | None | HR backup | Reminder |
Three rules prevent most disputes: nobody approves their own request (including through a delegate), delegation is explicit and time-limited, and every step records who acted, when and what they saw.
Sensitive data
Salary, bank details, medical notes, disciplinary records and identity documents deserve stricter treatment than the rest. Decide for each field: who can view it, who can change it, whether changes need a second person, and whether it is excluded from general search and from exports. Encrypt it, log every view, and keep it out of notification emails. Data protection rules differ by country; confirm with your legal adviser what applies to you. We design for a stated policy and do not claim a compliance certification for your system.
Sign-in and the joiner-mover-leaver lifecycle
Sign-in. Most organisations want staff to use their existing work account through single sign-on, typically over OpenID Connect or SAML with Microsoft Entra ID, Google Workspace or another identity provider. Your IT team registers the portal and controls who can sign in. Add multi-factor authentication through the identity provider rather than building your own.
Provisioning. Decide how accounts are created and removed:
- Joiners. Created from the HR master record when the contract is created, with a start date. The person gets access on day one, not before.
- Movers. Role and scope change when team, site or title changes. The change should flow from the HR record, not from a ticket to IT.
- Leavers. Access ends on the last working day, automatically, from the HR record or directory. Many organisations discover leaver access gaps only in an audit. Where the identity provider supports automated provisioning (such as SCIM), use it; otherwise agree a daily sync.
People without work accounts. Shop-floor, driver and site staff may have no email address. Plan an alternative sign-in, such as a phone number with a one-time code or a badge number with a PIN, and a shared kiosk if devices are limited.
Integrations that decide whether staff trust it
- HR master and payroll. Choose which system is the master for each field (name, grade, salary, bank details, leave balance). Two masters for the same field is the main source of "the portal is wrong" complaints.
- Attendance devices. Time clocks and biometric devices differ in what they can export. Confirm the export or API early.
- Directory. For org charts and group membership.
- Email and chat. Notifications and approve-from-email links need care: an approve link must expire and require a signed-in user, or it becomes a loophole.
- Finance. Approved expenses and cost centres to your accounting system. See system integration approaches.
Rollout plan that gets people to use it
- Write the policies. A portal can only automate a rule that exists. Settle leave types, carry-over, expense limits and approval chains first. The approval workflow design guide helps.
- Clean the starting data. Staff list, reporting lines, leave balances, cost centres. Errors here become the first support tickets.
- Pilot group. One department, a few managers, and some of the least technical staff. Run real requests through the portal for a few weeks while the old route stays open.
- Fix what the pilot finds. Typical findings: a missing leave type, a confusing label, a manager who needs delegation.
- Wave rollout. Department by department or site by site, each with a short briefing and a named person to ask.
- Close the old route. Announce a date after which leave requests by email are not processed. Without this, the portal becomes optional and usage stalls.
- Review at intervals. Check usage, request volume by type, time to approval, and the number of requests that still arrive by email.
Provide short, task-based help ("how to request leave") in the portal, in the languages your staff use, rather than a long manual.
Measuring success
Pick a few measures before launch and capture the baseline:
- Time from request to decision for leave and expenses
- Number of HR contacts per month for balance and document questions
- Share of requests submitted through the portal rather than email
- Requests returned for missing information
- Time to disable access after a leaver's last day
These show whether the portal is working without needing to track individuals' behaviour.
Delivery with Timeline Digital
An employee portal follows our five steps: Understand, Plan, Select Technology, Pilot, and Build & Scale. Roles, approval chains and sensitive-data rules are written in the Plan step and approved before development. The free pilot of 2 to 3 key modules is typically sign-in plus leave and one more request type. There is no fixed timeframe: the schedule for your employee portal is set from your requirements in the Plan step. The free pilot of 2 to 3 key modules is ready in about 2 days. The full project starts after you approve the pilot, and the scope, milestones and terms are agreed after it. Timeline Digital does not publish prices for custom software, because every project is custom.
About the author and publisher
Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan. This guide was written by Usama Asif to help HR and operations teams plan an employee self-service portal; it describes general practice, is not legal advice and is not a quotation.