Project management
When HR and Project Work Belong in One Login
Published 9/26/2026 · Updated 9/26/2026 · Dayzen
This is a decision page. The product homes are /hrms and /pms. They should stay the product homes. This article only covers when sharing a login helps, and when it does not.
Key takeaways
- What one login actually means
- When one login is the better fit
- When a separate project tool is still reasonable
- What must stay separate even in one login
HR software and project software answer different questions. HR asks who works here, how they attend, and what they are paid. A project asks what the team is delivering, who owns each task, and what is blocked. The buying question is not "which product has more modules." It is whether the same people should open both through one login, in one organization.
This is a decision page. The product homes are /hrms and /pms. They should stay the product homes. This article only covers when sharing a login helps, and when it does not.
What one login actually means
One login means a person has one account for the organization. They can open HR records they are allowed to see, and they can open projects they are allowed to see, without a second password and a second user list.
It does not mean the records are the same. An employee profile is not a task. A leave request is not a project status. Attendance punches are not minutes logged on a task. Sharing a login shares the person. It does not merge the data.
Dayzen is built as that pair: an HR system and a project system in one organization. People who belong to the organization can be given a project workspace and a project role. That role is not their HR role. How project access works is the project side of that split.
When one login is the better fit
Choose one login when most of these are true:
- The people doing the work are employees of the same organization, not a rotating set of outside accounts.
- Managers already look up the same person for "are they here?" and "what are they delivering?"
- You are tired of inviting the same hire into two products and deactivating them in only one.
- You want attendance kept as attendance, and task time kept as task time, with a clear reason they are separate.
The last point is the one teams skip. They hear "one system" and assume project hours become a timesheet or a payslip. In Dayzen they do not. Project time tracking vs attendance explains the two records. Attendance stays an HR feature.
When a separate project tool is still reasonable
One login is a poor fit when:
- The delivery team is mostly contractors who must not see HR records, and you do not want them in the organization at all.
- The project method depends on a specialist tool you already run well, and the only pain is a second password.
- You need payroll calculated from project time. Dayzen does not do that. Buying it for that reason would be a mistake.
- You need invoicing from tasks. A project in Dayzen is not a billing system.
A dedicated project tool can be the right call in those cases. The cost is the second user list: joiners, leavers, and guests maintained twice.
What must stay separate even in one login
Write these down before anyone calls the tools "integrated":
| Record | Where it belongs | What it must not become |
|---|---|---|
| Attendance punch | HR attendance | A task timer |
| Leave | HR leave | A project status |
| Task timer or manual minutes | The task | A payslip |
| Project role | The project workspace | The HR permission set |
| Employee profile | HR | A task assignee list with pay data |
Project permissions and HR permissions are different lists. A person can be allowed to approve leave and still have no access to a client project. A person can run a project and have no access to salaries. If a vendor demo blurs those, ask which record is which.
A practical decision
A 40-person company has HR in one product and delivery in another. Every hire is entered twice. A resignation is processed in HR on Friday and the project account is still active on Monday. Managers keep a private sheet of "who is on which account" because the two directories drifted.
That is the case for one login. The company does not need every HR workflow redrawn as a task. It needs one person record, then a project role that is granted on purpose.
Contrast a four-person studio that already lives in a board tool, has no HR administrator, and does not track attendance. Forcing an HR suite on them so they can have projects is the wrong order. Start from the project. Add HR when there are employees to record.
What to ignore in the sales conversation
Ignore module counts. Ignore a promise that "everything syncs." Ask three questions:
- Is the person one account?
- Can project access be narrower than HR access?
- Does task time stay off the attendance record and off payroll?
If the answers are yes, yes, and yes, one login matches the way Dayzen separates the two products. If you need task time to become pay, you need a different design, and you should not buy this pair for that.
A joiner and a leaver
Walk one hire and one resignation before you decide.
The hire starts Monday. In a split setup, HR creates the employee, IT creates an account in the project tool, and a manager forwards a link. If any step is late, the person attends and cannot see the work, or they see the work and do not exist in HR. One organization login does not remove the need to grant a project role. It removes the second identity. The manager still has to add them to the right workspace. That grant should be a small, deliberate step, not a copy of their HR permissions.
The resignation is the sharper test. HR records the last day. The project account should end with that person, not next week when someone remembers. One login makes "this person has left" a single fact. It still does not close their tasks. Someone must reassign work that is still open. One login does not do that reassignment for you, and it should not silently move task minutes into a final payslip.
If those two stories are already smooth in your current tools, the second password may be acceptable. If either story depends on a private checklist titled "accounts to update," the checklist is the argument for one login.
What a demo should show
Ask to see one person open HR and a project without a second account. Then ask to see a project they cannot open. Then open a task timer and an attendance day side by side and confirm they are different screens. That is the whole demo that matters for this decision. A tour of every HR module, or every project view, belongs on the product pages, not in the buying argument.
If the demo can only show the happy path where the new user is an administrator of both, it has not answered the question. Administrators always see more. The test is a manager who can approve leave, or not, independently of whether they can edit a client project.
Conclusion
HR and project management software belong in one login when the same organization employs the people and you want one account for them, with two kinds of records. They do not belong in one login so that attendance, payroll, and task time collapse into a single number. Keep the person shared. Keep the records separate. Use /hrms for the person and /pms for the work.
Related articles
Project management
How to Create a Custom Project Role
A custom project role is a named set of permissions on a workspace, assigned to a member. It answers "what may this person do here?" The map of access layers, organization versus workspace versus a share, is how project access works. This page is the narrower job: create one role and apply it. The example is a reviewer who can comment and must not edit tasks.
Dayzen
Project management
Project Channels, Section Channels, and Private Channels
A channel is a room with a scope. The scope decides who is in it. Dayzen has four scopes: the workspace, one project, one section, or a custom list of members. Pick the smallest room that still includes everyone who must hear the conversation. A custom list is how you make a private channel. It is not a direct message feature with an inbox of its own.
Dayzen
Project management
Project Chat vs Task Comments
Project chat and task comments are both places to write. They are not interchangeable. A channel is the conversation for a project, a section, or a chosen group. A comment is a note on one task, including a reply in that task's thread. Put the decision where the next person will look for it. If they will look at the task, comment. If they will look at the room, use the channel.
Dayzen
