An employee self service app replaces the emails staff send to HR.
Four questions make up most of the traffic into a small HR team: how many holiday days do I have left, where is my payslip, can you change my address, and who signs this off. An employee self service app answers them with no person in the middle. It is one of the plainest internal business apps anyone builds, and one of the easiest to get wrong, because every answer it gives is personal data about the person asking for it.
This page covers what a staff portal app has to hold, which employee records have to exist anyway and for how long, what must never be written to the phone's own storage, and how approvals behave when the manager is also an employee.
See what may live on the deviceThe short version
The screens are simple, the visibility rules are the work.
A self service app has perhaps six screens: my details, my pay, my time off, my documents, a request form, and an approvals list for anyone who manages people. None of that is hard to draw. The work is deciding, field by field, who may read it, who may change it, and who only gets to ask.
The second piece of work is deciding what the phone is allowed to keep. An HR record holds the most sensitive data a company holds about anyone: a social security or national ID number, a home address, bank details, sometimes a medical note. A payslip sitting in a file on a lost phone is a different kind of incident from a cached lunch menu.
What is actually inside an employee record
Before drawing screens, list the fields. Most of them already exist, because an employer has to keep them. For each nonexempt worker the Fair Labor Standards Act requires full name and social security number, address including zip code, birth date if the worker is younger than 19, sex and occupation, the time and day of the week when the workweek begins, hours worked each day and total hours each workweek, the basis on which wages are paid, the regular hourly pay rate, total daily or weekly straight time earnings, total overtime earnings for the workweek, all additions to and deductions from wages, total wages paid each pay period, and the date of payment with the pay period it covers.
Retention is set out too. Payroll records are preserved for at least three years. The records that wage computations rest on, such as time cards, wage rate tables and work and time schedules, are kept for two years. So an HR self service app is not creating a new archive. It is putting a door on one that has to exist anyway.
That list is also a sorting exercise, and the sort matters more than the screens. Hours and pay rates are read only for the employee and come from payroll. A phone number or an emergency contact is safe to edit in place. A bank account, a legal name or a tax code is a request that a named person verifies before it reaches payroll, because a portal that writes straight into a payment field is a fraud route with a login screen on the front.
Outside the United States the statutory list differs, but the shape does not: a set of fields somebody is obliged to keep, a retention period, and a much smaller set the employee may change on their own.
What a self service app must not keep on the phone
This part decides the architecture, so here it is plainly. Payslips and pay documents, social security or national ID numbers, bank details, dependants, and anything medical or disciplinary should not be written to the device's own storage at all. Fetch them, show them, and let them go when the screen closes. The reasons are dull and all of them happen: phones are lost, borrowed and sold, device backups copy app files off to a computer or to cloud storage, crash reports and analytics payloads pick up whatever is in scope when they fire, and a screenshot of a payslip lands in the photo library, which is a different permission boundary from your app.
The storage that ships with React Native does not help here. AsyncStorage is unencrypted key value storage, so it is the wrong home for any of the above. Expo's SecureStore is the right home for short secrets: on Android values are stored in SharedPreferences encrypted with Android's Keystore system, and on iOS they are stored using keychain services as a generic password. It is sized for secrets rather than documents. Expo does not enforce a size limit, but large payloads can be rejected by the underlying platform, and historically some iOS releases refused values above roughly 2048 bytes.
Two keychain behaviours are worth designing around. On iOS, values written through SecureStore persist across app uninstallation if the app is reinstalled with the same bundle ID, so deleting the app is not a wipe. And unless you choose an accessibility level whose name ends in THIS_DEVICE_ONLY, an entry can be migrated to a new device when restoring from a backup. Neither is a bug. Both mean a session token can outlive what the person thought they just did.
The working rule that falls out of this: the session token and an account identifier go in the secure store, a holiday balance or a directory photo can be cached like any other cache and cleared on sign out, and pay documents are streamed per view from a short lived link. Log nothing personal on the way. A log line with a bank account in it is a copy of the bank account.
Expo docs, SecureStore platform value storage and limits
Try it
What the phone is allowed to keep
Tick what your app would hold on the device for offline use, then read what that choice costs when the phone is lost or backed up.
Nothing sensitive on disk
A lost phone gives up a token you can revoke and a number of days. That is the shape to aim for.
Leave, changes and the approval chain
A leave request looks like a form and behaves like a ledger. The balance on screen has to be the balance after pending requests, or two people book the same week and one of them finds out late. Accrual is the fiddly part: a fixed annual allowance, carry over with a cut off date, part timers counted in hours rather than days, half days, and public holidays that fall inside a booking. Get that arithmetic settled on paper before it goes on a screen.
Worked hours are a separate record and usually a separate app. Where people clock in and out, the raw data comes from an employee time clock app and flows into pay, while the portal shows only the result. The far end of the lifecycle splits the same way: the record starts in an employee onboarding app or in whatever process hires somebody, and the portal inherits it rather than creating it.
Approvals need one unglamorous feature before anything clever: a deputy. Managers take leave too, and a request stuck behind an absent approver is exactly why people go back to email. Give every approval a second route, show the employee where their own request is sitting, and put a due date on it so nothing waits silently.
Record the state changes as events rather than a status field you overwrite: requested, approved by whom and when, amended, cancelled. In March, a status field says approved and an event list says who approved it and on what day. Only one of those survives a dispute.
Getting it used by people who are not at a desk
Most of the audience for an employee portal app is not sitting at a laptop. Warehouse, retail, care and site staff have a phone in a pocket, often a personal one, and they will open this app maybe four times a year. That shapes the build: no training, no manual, no reliance on a password invented during an induction session, and a sign in that survives a six month gap without locking somebody out on the day they need a payslip.
One account per person, and never a shared device login. A shared account breaks the whole premise, because the value of the app is that what is on the screen belongs to the person holding it. If the shop floor has a communal tablet, that is a different app with a different design, and personal pay data does not belong on it.
Leaving is a feature, not an afterthought. When someone goes, access ends that day, the local cache clears at sign out, and the employer's copy of the record stays for as long as the retention rules say it must. An app that quietly keeps working for a former employee is the failure mode nobody remembers to test.
What each way of doing staff self service gives you
| Option | Works on a phone | Each person sees only their own record | Your own leave and approval rules | You decide what is stored on the device |
|---|---|---|---|---|
| Email and a shared spreadsheet | the inbox does | No | kept by hand | No |
| Payroll provider portal | usually | Yes | No | No |
| Full HR suite | Yes | Yes | the ones it ships with | No |
| Intranet page of PDFs | usually | No | No | No |
| A staff portal you build | Yes | Yes | Yes | Yes |
Building one around your own rules
HR suites are built for the median company and priced per employee per month. A firm with forty staff often needs a slice of one: the leave rules it actually has, the two approval chains it actually uses, and a document list with four things in it. The rest of the suite is usually the reason the project never starts, because somebody has to map every field in it before anyone can log in.
Newly is an AI app builder. You describe the app you want, including which fields are read only and which are requests, and it builds and ships a real React Native and Expo project you own. Plans are $25 a month and there is no free plan. iOS goes out through TestFlight and App Store Connect with your own Apple Developer account, and Android publishes to Google Play internal testing from the Deploy tab or builds a standalone APK. There are no built in payments, which for a staff portal is no loss, since a portal should not be taking money.
Settle the permission model before anything else, because every screen leans on it. Decide who may see which record first: a person sees their own, a manager sees the people who report to them, HR sees everyone, and the server refuses anything else rather than the interface hiding a button.
Questions people ask about employee self service apps
It is an app that lets staff read and update their own HR record without asking HR: holiday balance and requests, payslips and pay history, personal details, documents, and an approvals list for anyone who manages people. The employer keeps the same records it always kept. The app puts a controlled door on them, one person at a time.
Describe the questions your staff keep asking HR
List the ten things people email about, say who may read each field and who only gets to ask, and build the portal around those rules.
Start building