Private employee self-service, bounded by role
Describe the resources employees need, the requests they submit, what managers review, and which fields HR may see. Playcode builds the authenticated workflow and helps you test invitation expiry, cross-account privacy, session revocation, retention, export, and deletion before real employee use.
No credit card required · No coding needed
Quick answer
Employee portal software gives authenticated staff a private place for approved resources, requests, acknowledgements, and role-specific actions. With Playcode, you describe the employee, manager, and HR visibility rules, then build and test invitations, sessions, offboarding, retention, export, and deletion as one database-backed workflow.
Used by people at
Counts registered accounts using corporate email domains from the companies above. Playcode is a self-serve product, not a contracted vendor to these brands.
Prove one resource and request lifecycle before expanding the portal
Separate the signed-in person, employee record, manager relationship, HR role, invitation, and session. List the exact profile, resource, request, and acknowledgement fields each relationship may read or change.
Keep sensitive employment, payroll, benefits, health, and regulated records outside the first portal. A smaller allowlist is easier to test and safer to operate.
Ask Playcode to build time-limited invitations, authenticated sessions, resource metadata, a versioned acknowledgement, one employee request, a manager review state, and the protected HR action needed to close it.
Test every list, detail, update, acknowledgement, export, and download decision signed out, as the intended employee, as another employee, as the direct manager, as an unrelated manager, and as HR.
Publish over HTTPS with fictional accounts. Expire an invitation and session, revoke every active session during offboarding, export only allowlisted employee data during the approved retention window, and delete it after the window ends.
Use bounded IDs and reason codes in audit events, not invitation tokens, private notes, document contents, or credentials. Rehearse record repair separately from whole-app recovery.
Your website is live!
Employees get clarity without turning every internal record into a shared directory
Start with private self-service records, not a replacement for every HR system
Use server-enforced field allowlists and current reporting relationships so a role name alone never grants broad access to every employee record.
Issue single-purpose, time-limited invitation tokens, store only their hashes, make exact acceptance retries safe, expire sessions, and revoke all active access when employment ends.
Track title, audience, version, owner, retention, and authorized storage reference separately from the document bytes and their download path.
Move one request through submitted, manager review, HR review, and resolved states with expected versions, idempotency, and bounded audit events.
Record which employee acknowledged which approved resource version and reject an attempt that silently refers to an outdated version.
Allow a named owner to export approved fields during a defined retention window, then delete the employee-scoped records after the window expires.
Model identity, relationships, visible fields, lifecycle, retention, and recovery as server contracts rather than hidden controls.
A login does not explain who is an active employee, who manages whom, which HR role is current, whether an invitation expired, or whether an old session was revoked.
Ready when: You can change a manager, expire one invitation, revoke every session for one offboarded employee, and preserve unrelated employee records without editing browser-only flags.
Profile visibility, private request notes, manager summaries, HR notes, resource metadata, acknowledgements, export, and deletion need different readers and actors.
Ready when: The matrix gives a result for signed out, employee self, another employee, direct manager, unrelated manager, and HR across list, detail, update, acknowledgement, export, and deletion paths.
An employee portal should not collect payroll, benefits, health, or regulated records merely because the database can store them. Resource metadata also does not secure file bytes by itself.
Ready when: Every collected field has a purpose, reader, retention owner, export rule, deletion rule, and storage boundary. Unneeded sensitive fields are absent from the schema, fixtures, logs, and screenshots.
Create separate records for identity, employee membership, manager relationship, role assignment, invitation, and session. Give invitations a purpose, unguessable token whose hash is stored, and expiry; open sessions only from a server-authenticated identity; give sessions expiry and revocation timestamps; make employment status authoritative on the server.
The same portal URL produces signed-out, invited, active, expired, revoked, offboarded, and denied states without conflating an email address with current access.
Accept one fictional invitation twice, reject a different email, cross its expiry boundary, expire one session, and revoke two open sessions during offboarding.
Resolve the current identity, active employee status, manager relationship or HR role, requested record, field allowlist, and action before returning or changing data. Return only selected fields rather than loading a full private record into the browser.
An employee sees only their allowlisted view, a direct manager sees only manager fields for direct reports, and HR access stays explicit. Another employee and unrelated manager receive no private record.
Replay known employee and request IDs across two ordinary accounts, two managers, HR, and a signed-out request; inspect the raw server payload, not only hidden interface elements.
Version each approved resource; bind acknowledgements to that version; validate requests on the server; use a scoped idempotency key and input fingerprint for creates; and require expected versions for every review transition.
An exact retry returns the original request or acknowledgement, changed input under the same key conflicts, and a stale manager or HR decision cannot overwrite the newer record.
Submit the same fictional request twice, alter it under the same key, race two review versions, acknowledge the current resource, and attempt an acknowledgement against the previous version.
Store authorized resource metadata separately from file bytes. If a provider is added, keep credentials server-side, validate upload and download boundaries, commit the core request first, and track notification or storage failure as a retryable secondary state.
A provider outage cannot duplicate or erase the employee request, a known storage reference is not a permission grant, and an operator can retry the failed side effect without repeating the durable action.
Fail the storage or notification adapter after the core record saves, inspect one stable request ID, retry only the failed side effect, and attempt the resource path from another employee account.
Run the fictional employee flow on the final URL, offboard the employee, revoke every session, export only allowlisted subject data during the approved retention window, delete it after expiry, and document when to repair one record versus restore the whole app.
The intended flow works once, old sessions are denied immediately, exports omit manager or HR-only notes, deletion waits for the named window, and operators have a bounded recovery decision.
Use private browsing and two fictional employees, hold two sessions open during offboarding, compare the export field list, cross the retention boundary, verify deletion, and inspect bounded audit events for private payload leakage.
Choose: Use the smallest role baseline, then require the current relationship, record scope, visible field, and action on the server.
Tradeoff: Relationship-aware checks add explicit rules and fixtures, but stop a manager label from becoming access to every employee or request.
Choose: Choose the simplest path that satisfies the approved file, size, location, retention, and access requirements. Keep portal authorization and resource metadata explicit either way.
Tradeoff: First-party app storage keeps the initial workflow smaller. A provider may match an existing system, but adds credentials, limits, outage handling, and a separate download-authorization boundary.
Invite one fictional employee, sign in, open one approved resource, acknowledge its current version, submit one request, review it as the direct manager, and resolve it as HR.
Expected: One active membership, acknowledgement, and request exist; each role sees its allowed fields; and the audit trail records bounded IDs and state changes.
Request the employee profile, resource, request, and export while signed out, as another employee, and as an unrelated manager; then submit a stale acknowledgement and stale request version.
Expected: Every unauthorized path is denied server-side, no private fields appear, and stale versions change no resource, acknowledgement, or request state.
Accept the same invitation twice, repeat the same request and acknowledgement keys, change input under an existing key, and retry a failed notification after the request saves.
Expected: Exact retries return the original result, changed fingerprints conflict, record counts stay single, and only the failed side effect retries.
Use two fictional employee accounts and two open sessions on the published HTTPS URL, then expire one session and offboard the intended employee.
Expected: The intended account completes the workflow once, the other account stays isolated, and every old session is denied after expiry or offboarding.
Change the resource and request types without weakening the access rules
Resources, access requests, acknowledgements
Give staff one authenticated view for approved operating resources, equipment or system-access requests, and version-bound acknowledgements.
Private updates and manager review
Route employee requests through the current manager relationship while keeping HR-only fields and unrelated employee records out of the view.
Invitation and offboarding control
Issue time-limited invitations, inspect bounded lifecycle events, revoke sessions at offboarding, and apply named retention and deletion decisions.
Mobile self-service records
Let authenticated staff find approved resources, submit one bounded request, and see its current state without exposing a broad company directory.
The concept separates employee, manager, and HR perspectives around a private resource, submitted request, manager review, acknowledgement, invitation, and revoked session.
The dependency-free ZIP passes a fresh-extraction 14-test suite for field visibility, signed-out and cross-account denial, hashed invitation tokens, session identity and revocation, scoped retries, versioned requests and acknowledgements, retention-bound export, deletion, and bounded audit output. SHA-256: e73f5af19ff3600c740dee51e5934f40e41613d64bc6cd7ccd16b57cc9808637. It is reference proof, not a public Playcode deployment or packaged HR product.
The difference appears in field visibility, lifecycle, and offboarding behavior
| Employee need | Shared intranet or folder | Playcode employee portal |
|---|---|---|
| Identity and access | Possession of a link stands in for current permission | Invitations, sessions, employment state, relationships, and actions are checked |
| Visible employee fields | One broad profile or directory view | Employee, direct-manager, and HR field allowlists stay separate |
| Requests | Form submission disappears into email or chat | Versioned states, idempotent creates, current owner, and bounded audit events |
| Acknowledgements | A generic checkbox detached from content changes | Each acknowledgement binds employee, resource, and approved version |
| Offboarding and retention | Account removal leaves old sessions or links unexplained | Sessions revoke, exports stay allowlisted, and deletion follows a named window |
Playcode AI runs the same frontier models that power ChatGPT and Claude - and orchestrates them like a team: it plans the work, delegates to sub-agents, runs long jobs in the background, and reviews its own changes.
The latest models from every major lab, in one picker. Switch anytime.
Big jobs split across specialists - one explores your code, one writes, one audits - working in parallel.
Long builds and migrations keep running while you keep talking. They report back when done.
Have a design in Figma? Paste a screenshot - or a page you like, or a bug - and it builds from what it sees.
Tuned by years of iteration to write production software - structured, typed, maintainable - not throwaway prototypes.
Under every project is a codebase the agent keeps production-grade. And you are never locked out of it: open the file explorer and edit any file yourself - server included. No AI required.
Complete states, secure boundaries, structured code - the bar is what a professional agency would ship.
Browse the whole project - frontend, backend, configuration - and edit directly in the built-in editor.
Invite your developer with the right role, or export the project code and files. Nothing is trapped in Playcode.
Playcode is built for organizations, not just solo builders. Workspaces hold your projects, people, and billing; roles and teams decide exactly who sees what.
Create a workspace per company, client, or department - each with its own members, projects, and subscription.
Admins manage, editors build, viewers watch. Set roles on the whole workspace, on a team, or on a single project.
Group people into teams and give each team its own projects - or a whole folder of them. Private projects stay private, even inside a shared workspace.
Send a project to any email - a client, a contractor - with exactly the access you choose. No extra seat needed.
Work on one project together. Write in the same AI chat together. Every message, edit, and setting is fully synchronized - live, for everyone, on every device.
Everyone works in the project at the same time - even in the code editor - without lock-outs or "who has the latest version".
Start on the laptop, check from your phone: the same live state follows you everywhere you sign in.
Changes arrive over a live connection the instant they happen. Reloading the page is a habit you can drop.
Every click applies immediately on your device. Syncing happens behind you, not in front of you.
Connection dropped? Your changes queue locally and replay the moment you are back.
The queue survives closing the tab. Nothing you did is lost while you are away.
"I built my entire portfolio site in 20 minutes. My clients think I hired a designer. Already got 3 new inquiries this month."
"We switched from Wix to Playcode. The AI actually understands what we need instead of giving us cookie-cutter templates. Saved us thousands."
"I update my property listings from my phone while showing apartments. Clients are impressed when I tell them I built the site myself."
Start small. Upgrade when you're ready.
Try the AI website builder and see results
Everything you need to build
Cancel anytime. No hidden fees.
Credits are used when AI helps you. Simple edits cost less, complex features cost more.
Most users never run out. 100 credits = lots of building.
Yes. Describe the employees, manager relationships, HR role, private resources, request states, acknowledgements, invitation rules, sessions, retention, export, and deletion path in plain English. Playcode builds real code while you guide the workflow through chat and visual editing. Test every private path before real staff use it.
No. This owner is for authenticated employee self-service: private resources, requests, acknowledgements, and role-specific actions. A broad employee directory, org chart, company intranet, or news feed has a different search job and privacy surface and is deliberately excluded here.
No replacement is claimed. Keep payroll, benefits, health, regulated employment records, legal decisions, and provider-controlled functions in their approved systems. Build only the bounded self-service workflow whose data, access, retention, export, and deletion rules your organization can name and test.
The server should verify the signed-in manager role, current employee-manager relationship, requested record, visible field allowlist, and action for every request. Test the same known employee and request IDs as the direct manager and an unrelated manager, then inspect the raw response fields.
Offboarding should change the authoritative employee status, revoke every active session, revoke unused invitations, deny protected requests immediately, and start the named retention path. Export only approved subject fields during that window, then delete the employee-scoped records when the authorized window ends.
Yes, if the workflow includes it. Bind each acknowledgement to the authenticated employee, exact resource ID, and current approved resource version. Reject a stale version, make an exact retry return the original record, and decide how a later resource version requests a new acknowledgement.
The app can use Playcode persistent file storage within current plan limits or a separately configured provider. Resource metadata is not the file bytes or permission by itself. Validate file type and size, authorize each access on the server, keep provider credentials server-side, and define retention and deletion.
No compliance or legal conclusion is claimed. Data minimization, field allowlists, session revocation, bounded audit events, retention, export, deletion, and two-account tests are engineering controls. Your organization must identify applicable law, policy, employment obligations, record owners, review, and approved systems before collecting real data.
The project code can be exported. Treat code export, employee-subject export, resource-file handoff, provider data, and whole-app recovery as separate contracts. Use an explicit subject-data allowlist and test that manager summaries, HR notes, invitation tokens, credentials, and storage references stay out of the employee export.
Still have questions? Contact us
Describe the role, field, resource, request, acknowledgement, invitation, offboarding, retention, and deletion rules. Playcode builds the first working version so you can verify every boundary before real employee use.
An employee portal with private resources, requests, and acknowledgements...Build My Employee PortalNo credit card required. AI credits included.