Should HR Get Its Own Seats or Share the Project Workspace?

You are picking seats for a new system and someone asks whether HR should get its own. Here is the short version: give HR its own seats when the records they keep would be uncomfortable sitting in a view that project managers open every day, and share the project workspace when the only HR fact managers need is who is available next week.

That is the whole decision. Everything below is how to check which side you are on before you commit to a bill.

What managers actually need from HR data

Ask a project manager what they want from the HR system and the honest answer is usually one thing: availability. Who is off, when, and for how long. Almost every planning mistake that gets blamed on bad estimates is really a planning mistake about absence.

That is a narrow ask. It does not require salary, medical notes, disciplinary history, performance ratings or anything from a hiring file. A board that knows who is on leave solves the visibility problem on its own.

So the first test is simple. Write down the HR fields a manager would need to plan a month of work. If your list is short and none of it is sensitive, you probably do not need a separate HR workspace, and on a smaller team it is worth asking first whether a dedicated HR tool is worth it at all. You need a shared one with the sensitive fields kept out of the manager's view.

Where the privacy boundary sits

The boundary is not between departments. It is between two kinds of record.

The first kind describes a person's relationship with the company: pay, contract terms, warnings, medical certificates, grievance notes, hiring assessments. These have a small, named audience and a legal reason for being restricted.

The second kind describes a person's availability and role: their team, their manager, their working days, their approved leave, their skills. Managers need this to do their jobs, and hiding it causes more harm than sharing it.

Most arguments about seats are actually arguments about mixing these two. Once you separate them, the seat question gets easier.

Split HR data into records about a person's employment terms and records about their availability. Availability belongs in the shared workspace. Employment terms belong behind a smaller set of seats, whichever system you buy.

How each option changes the bill

SicherOne is sold per seat, and the modules are separable. That means the choice is not all or nothing, and it also means you can talk yourself into paying for more than you use.

Two shapes are common:

• Everyone shares one workspace. Project management, HR and agents run on one set of records. You pay for a seat per person who needs access, and permissions decide what each of them sees. The bill is driven by headcount, not by department.
• HR takes its own module and its own seats. Managers get project seats. HR gets HR seats. The two still connect through the same records, but the audience for the sensitive module stays small.

The second option costs less than people expect when the HR audience is genuinely small, and more than expected when half the company turns out to need HR access for approvals. Count approvers before you decide. Leave requests, timesheet sign off and hiring approvals all pull managers into HR workflows whether you planned for it or not. If your headcount moves in bursts, work the seat maths for a peak month as well as a quiet one.

The question that settles it

Run this in one meeting. List every person who would need to open the HR module in a normal month, and next to each name write what they need to do there. Approve leave. Check a start date. Update a record.

If most of those tasks are approvals and lookups, share the workspace and control it with permissions. Separate seats will duplicate access without adding protection.

If a meaningful number of those tasks involve reading records you would not want a project manager to stumble into, take the separate module. The extra cost buys a boundary that does not depend on somebody configuring permissions correctly every time a new person joins.

One more thing to check before you sign

If you plan to use AI agents against this data, decide the boundary first, not after. An agent that works with full context is useful precisely because it can see across records, which is exactly why the boundary needs to exist before you turn it on. In SicherOne a human approves agent output before it goes anywhere, so nothing ships unreviewed, but approval is not the same as access control. Access is still yours to set.

Teams with strict data rules sometimes want the models running on their own infrastructure as well. Private models can be self hosted, and that is worth raising in the same conversation rather than six months later when the policy question arrives.

Decide the boundary, count the approvers, then buy the seats. In that order the bill stops being a guess.