Designing an Enterprise Permission & Profile Architecture for a Talent Intelligence Platform.

Redesigning the system foundation to support enterprise-grade security, granular role management, and data visibility control.

01
PillarEnterprise-Grade Security
02
PillarGranular Role & Data Scope
03
PillarNo Data Leakage by Design
04
PillarScalable for Future Talent Solutions
RoleLead Design Architect
DomainB2B Enterprise · Talent Intelligence
MarketJapan · UAT stage
StatusShipped · NDA-redacted
FocusIdentity · Permission · Visibility
Business Impact
6×
Enterprise Contracts in Japan
during early UAT stage
  • Enabled enterprise-grade permission architecture.
  • Increased client trust through visibility transparency.
  • Reduced sensitive data exposure risk.
  • Established a scalable foundation for future workforce products.
01 / The shift

From ATS to Talent Intelligence Platform.

The product had to evolve beyond hiring - into a platform that carries a person across their entire workforce lifecycle. That meant rebuilding the underlying identity model from the ground up.

Before
Traditional ATS
Focus · Hiring
  • Application tracking
  • Single candidate record
  • Linear hiring funnel
  • Recruitment data only
1 Candidate
= 1 Profile
= All Recruitment Data
After
Talent Intelligence Platform
Focus · Talent Lifecycle
  • Internal mobility
  • Workforce planning
  • Reskill / upskill
  • Cross-department visibility
  • Future opportunities
1 Talent
= Multiple Applications
= Multiple Opportunities
02 / The problem

Legacy architecture could not meet enterprise security requirements.

One profile carried every piece of data about a person - and every role with profile access could see all of it. Enterprise customers, especially in Japan, would not sign without structural separation and verifiable controls.

1 Profile = All Data
  • Personal Information
  • Resume
  • Interviews
  • Feedback
  • Notes & Emails
  • Offer & Compensation
  • Documents
Problems
  • Hiring managers saw sensitive compensation data.
  • No separation between global talent data and job-specific data.
  • No scalable permission model.
  • High risk of data leakage across roles.
  • Could not support enterprise compliance & trust.
03 / The breakthrough

Separate resources. Separate purpose. Separate visibility.

We split the monolithic profile into two distinct resources - Talent (the person, evergreen) and Application (the job-specific process, time-bound) - each with its own permission contract.

Resource A
Talent
Global Identity
  • Core profile
  • Skills & experiences
  • Resume
  • Certifications
  • Global notes & activities
  • Application history
Resource B
Application
Job-Specific Process
  • Job information
  • Interviews
  • Evaluations & feedback
  • Hiring workflow
  • Offer process
  • Job-related notes & emails
ONE TALENT  →  MULTIPLE APPLICATIONS  →  MULTIPLE JOBS
04 / Multi-layer permission architecture

Control access at every level.

Six layers of permission, evaluated in sequence - from the highest-level "what resource can you touch" down to the field-level "can you export this value." Every screen reads from the same contract.

1
Resource Permission
What users can access - Talent / Application / Job
2
Scope Permission
Which data users can access - Department / BU / Custom Scope
3
Section Visibility
Which modules / sections are visible
4
Field Visibility
Which fields are visible / editable
5
Record Visibility
Which records / items are visible
6
Action Permission
Which actions users can perform - view / edit / export / delete …
05 / Safe rendering pipeline

Backend enforces. Frontend renders safely.

Permission decisions happen server-side, then the API returns only what the user is allowed to see. The frontend never holds data it shouldn't render - so there is no hidden-but-loaded data to leak.

1
User opens a profileRequest includes role, scope, context
2
Backend checks permissionsResource + scope + rules
3
Filter tabs, sections, fields, records & actionsSix-layer contract evaluated
4
Return safe UI configOnly allowed data crosses the wire
5
Frontend renders allowed data & actions onlyNo client-side filtering required
Result
No hidden-but-loaded data.
What users can't access is never returned. Audits become a query against the contract - not a project.
06 / Shared UI, dynamic visibility

One layout. Different visibility.

The same Application Detail page renders differently depending on the viewer's role. Sections, fields, and tabs disappear at the contract layer - not the component layer.

Recruiter
Full Access
Jane Cooper
OverviewApplicationsInterviewsOfferNotesDocuments
  • Personal Information visible
  • Experience visible
  • Skills visible
  • Compensation visible
  • Offer Letter visible
  • Internal Notes visible
Hiring Manager
Restricted
Jane Cooper
OverviewApplicationsInterviewsNotes
  • Personal Information visible
  • Experience visible
  • Skills visible
  • Internal Notes visible
Interviewer
Limited
Jane Cooper
OverviewInterviews
  • Personal Information visible
  • Experience visible
  • Skills visible
07 / Field-level permission example

Compensation field in Application detail.

A worked example for a single high-sensitivity field - compensation - across five enterprise roles. Each role has its own view, edit, and export rights, evaluated independently.

Role Can view Can edit Can export
Recruiter
Hiring Manager
Interviewer
HRBP
Executive Viewer
Allowed ✗ Not allowed · One field, five roles, three actions - fifteen independent decisions.
08 / UI implementation highlights

Where the contract meets the interface.

Four surfaces that translated the permission architecture into something administrators and end users could actually operate day to day.

A · Admin
Role Management
Create custom roles with granular permissions.
Hiring Manager
Recruiter
Interviewer
HRBP
Executive Viewer
B · Admin
Field Visibility Settings
Control visibility for each field in each resource.
Phone number
Email
Date of birth
Current salary
Nationality
C · Viewer
Application Detail (Restricted)
Only allowed sections & fields are shown.
Application for
Senior Product Designer
Interviews
Feedback
Offer & Compensation - not visible
D · Viewer
Notes Visibility
See only notes you have permission to view.
Internal note by HR
visible to: HR, Recruiter
Hiring note by Manager
visible to: Manager, HR
Private note - not visible to you
09 / What's next · Future expansion

Built a foundation for future talent solutions.

Every product on this list inherits the same identity model and permission contract. New surfaces no longer rebuild visibility from scratch - they extend it.

01
Internal Mobility Marketplace
Surface opportunities to existing employees, scoped by org.
02
Workforce Planning & Analytics
Cross-org talent supply and demand modeling.
03
Learning & Development
Skill-aware learning paths bound to talent identity.
04
AI-powered Talent Recommendations
Permission-respecting recommendations across roles.
05
Skills Intelligence & Assessment
Evergreen skill graph attached to talent, not applications.
06
Succession Planning & Bench Strength
Executive views with strict scope & visibility controls.
Key takeaway

This project was not just about building a feature - it was about designing a secure, scalable system foundation that enterprises can trust with their most sensitive data. By aligning UX, system architecture, and permissions, we unlocked the next chapter of our product and won the trust of leading enterprises.

Skills demonstrated

Six disciplines, one structural decision.

01System Thinking
02Enterprise UX Architecture
03Permission System Design
04Information Architecture
05Security & Data Governance
06Cross-functional Leadership