Who updates employee profiles: employee, manager, or HR

Who may change an employee profile is a different question from what the profile contains. If everyone can edit everything, the directory stops being a system of record and becomes a shared notepad. If only HR can change a phone number, you drown in tickets for facts the employee already knows. Split updates by risk: employees maintain low-risk contact details, managers request structure changes for their team, and HR (or a named data owner) applies identity, job, pay-critical, and status changes.

This is a RACI for profile edits, not a second overview of the employee management product, and not a duplicate of employee self-service in HR. Self-service is how people reach their own data. This page decides which fields they are allowed to change when they get there.

Why ownership has to be field-level

A slogan such as “employees own their data” sounds respectful and fails on the first promotion. Designation, department, and manager are company facts. PAN, bank details, and employment status are high-impact facts. Preferred name and personal phone are closer to the employee. One permission for the whole profile cannot express that mix.

Write the RACI against fields or field groups, not against the word “profile.” Review it when you add a new field. If you later collect emergency contacts or work location, decide who creates, who updates, and who only views. Default to least write-access, then open a field when a job truly needs to maintain it.

A practical RACI

Field group	Employee	Manager	HR / data owner
Preferred name, personal phone, emergency contact	Updates	Views team as policy allows	Audits exceptions; corrects if abused
Work email, work phone (if company-issued)	Requests or views	Views	Updates after IT / HR process
Legal name, date of birth, identity numbers	Requests with proof	Does not edit	Applies after document check
Department, designation, rank, location	Views	Requests for their team	Applies; keeps job history
Reporting manager	Views	Requests; does not silently rewrite another team	Applies; prevents loops and blanks
Bank details (if stored)	Requests through a controlled channel	Does not view or edit	Applies with tight access
Compensation-related fields	Views what policy shows (for example a payslip)	Does not edit others’ pay	Payroll / HR owner only
Status (active, inactive, exited)	Does not edit	Signals a team change; does not set status	Owns
Employee ID	Views	Views	Issues once; corrects only as a controlled exception
Documents on the file	Uploads what self-service allows	Does not open identity scans by default	Classifies, retains, restricts

Your labels can differ — People Operations, HRBP, Payroll Admin — but each row needs one account that may apply the change. “Anyone in HR” is not a name. Shared admin logins make the trail useless.

What employees should update

Employees are the cheapest, most accurate source for facts about their own contact life: a new personal number, a changed emergency contact, a preferred name they actually use. Let them update those in self-service so HR is not retyping WhatsApp messages. Put a light review only where abuse would hurt operations (for example a preferred name used to evade a directory search).

Employees should not be able to rewrite their designation, give themselves a new manager, or set their record to exited. Those are employment events. They can request a correction (“my joining date is wrong”) with a comment and, where needed, a document. HR applies or rejects it. That request-versus-apply split is what keeps self-service from becoming self-authorization.

For how self-service should feel as a channel — fewer tickets, more of the employee’s own transactions — read employee self-service for HR teams. Pair it with this RACI so “self-service” does not get interpreted as “editable master data.”

What managers should request, not silently apply

Managers see operational data for their team: who is on the team, who reports to whom, who is on leave. They should not see company-wide compensation or other teams’ identity documents. When a reporting line or location should change, the manager is often the person who knows first. Let them raise a structured request. Do not let them drag a person into their team on an org chart with no HR confirmation if that move also changes department budgets, approvals, or payroll cost centres.

Managers must not silently rewrite another team’s reporting line. Poaching in the org tree is how two leads both think they own a headcount. If a matrix exists, dotted-line requests need the same discipline as solid-line ones: named requester, named approver, HR apply.

Managers also should not “helpfully” edit legal names, bank accounts, or identity numbers for a teammate. That help is how sensitive data leaks into a manager’s laptop trail. Point the employee to self-service or HR.

What HR must own

HR (or a split of HR and payroll admins) owns the fields that define employment: identity numbers collected for a stated purpose, employee ID issuance, job assignment, status, and compensation-related values. They also own applying manager-requested structure changes and keeping job history when those changes are transfers or promotions rather than typo fixes.

Ownership includes saying no. A hiring manager who wants a unique designation for every person, or a blank manager “until later,” is asking to damage the directory. HR’s job is to apply valid changes and reject ones that break uniqueness, reporting trees, or access rules.

When HR uses a five-step add-employee wizard — as in Dayzen, with validation for email, employee ID, PAN, and Aadhaar fields — that is still an HR-owned create, even if later contact fields pass to the employee. Creation is not self-service. Corrections after join follow the RACI above.

RACI in words: responsible, accountable, consulted, informed

• Responsible does the typing or the request.
• Accountable is the single owner if the field is wrong in an audit.
• Consulted is asked before a sensitive apply (payroll for bank changes, IT for work email).
• Informed sees the result (manager notified that a transfer was applied).

Example: a bank-detail change. Employee is responsible for submitting. HR or payroll is accountable for applying. Nobody else is consulted unless your finance SOP requires it. The manager is not informed of the account number; they may be informed that the person completed a required form, if that matters for onboarding status only.

Example: a department transfer. Manager is responsible for requesting. HR is accountable for applying department, maybe cost centre, and reporting line together. The employee is informed. Payroll is consulted if the move changes how pay is costed. The losing manager is informed so their team list is not a surprise.

Audit trail and “who changed this?”

A RACI without a trail is a poster. When a designation flips the night before payroll, you need to know whether it was HR applying a promotion or an over-permissioned manager. Prefer named users. Prefer field-level history on job-critical attributes. Prefer requests that survive as records, not chats that vanish.

Dayzen employee profiles hold personal details, job history, assets, and documents in one directory. Job history is the natural place to see assignment changes over time. It is not a substitute for deciding who is allowed to write those changes. Permissions and profile ownership work together: the product can store the data; your RACI decides the writers.

Edge cases that break a sloppy RACI

Founders and “everyone is an admin”

Early teams often give every founder full HR rights. That is convenient until someone edits their own title or another person’s status as a joke. Even in a small company, keep one or two named people as accountable for master data. Founders can still request.

Contractors and vendors

If contractors sit in the same directory, they should not inherit employee self-service for fields you do not collect from them, and their managers should not gain pay-field access “because they approve timesheets.” Scope the profile shape and the write rights to the employment type.

Rehires and legal-name changes

The person may remember an old ID and an old email. They still should not mint a new employee ID or overwrite historic legal name without HR. Requests plus documents, then apply.

Bulk imports

A spreadsheet upload is an HR-owned write, not an employee write. Validate it as if every row were an admin action. Bulk is how a wrong department lands on two hundred people at once.

How this sits next to Dayzen

Dayzen employee management is the people system of record: searchable directory, profiles, departments, designations, ranks, org tree, and the add-employee wizard. It does not, by itself, announce your RACI. You still decide which roles may edit which groups of fields. For the product surface, see employee management in Dayzen. For the channel employees use to reach their own transactions and allowed profile fields, see employee self-service.

Self-service reduces tickets. It does not replace HR ownership of master data. Managers should not silently rewrite another team’s reporting line. Pay, identity, and status changes need an owner and a trail. Write that down at field level, then match system permissions to the paper RACI so the directory remains something you can trust.