Where Leave Approvals Live in SicherOne and Who Can See Them

Someone asks for four days off. Where does that request go, who acts on it, and what happens to the project board once it is approved? In SicherOne a leave request moves through three states, request, approved, reflected, and it lives on the same records as the project work the whole time. That last part is why the board updates without anyone retyping anything.

The other question people ask is who can read the reason. The short version: dates are visible to the people who plan work, and the reason is visible to far fewer people than that. The two fields are not treated the same way.

The path a request takes

Request. The person picks dates and submits. The request carries the dates, the type of leave, and a reason field. From the moment it exists it is visible to the approver, and the dates become a soft marker rather than a fact.

Approved. An approver acts on it. This is a human decision. An AI agent inside SicherOne can prepare the context around a request, such as what work sits on those days and who else is already out, but it does not approve leave. A person does, and the approval is recorded against them.

Reflected. The approved dates land on the shared records, which means the project board sees them without an export or a sync step. Tasks owned by that person during those days are flagged. Anyone planning the week reads real capacity rather than a headcount, which is how you catch two teams booking the same person for the same week.

The third step is the one that usually goes missing in teams running two separate systems. HR has the approval. The board does not. A manager plans around a person who is not there, and finds out on the day. The same gap swallows what recruiting learned before a new hire starts.

Who sees the dates

Most people who need to plan work need the dates. That is not sensitive information in the way a reason is. If you are assigning work for next week, knowing that three of your team are out on Thursday is the basic input. Who can cover for them is the second input, which is what a skills matrix that stays current is for.

So dates travel further than reasons by default. They show on the board, in capacity views, and in the context an agent reads before it suggests a schedule.

Who sees the reason

The reason field is narrower. Leave reasons can include medical detail, family situations, and things people would tell an HR lead but not a project manager, let alone a whole team.

The sensible default, and the one worth checking in your own configuration before you roll anything out, is:

• The person who submitted it, always.
• The approver acting on that specific request.
• The HR role, for records and for any statutory obligation that applies where you operate.
• Nobody else by default, including peers, including the wider management line.

Rules about what an employer may record and who may see it vary by country and sometimes by sector, so confirm your setup against local requirements rather than assuming a default is compliant.

A quotable version

Leave approvals in SicherOne move from request to approved to reflected on the board, on one set of shared records. Dates travel to everyone who plans work. Reasons stay with the person, their approver, and HR.

What agents can and cannot do here

Agents in SicherOne read the same records everyone else does, within the same permissions. That means an agent asked to find a meeting slot will see that someone is away, because it can see the dates. It does not need the reason to do its job, and it should not be given access to fields it does not need.

An agent can draft. It can summarise the week, prepare a note about coverage, or point out that a deadline sits inside someone's approved leave. Everything it produces goes to a person for approval before it ships. Leave decisions in particular stay with humans, because the input is not just policy and dates, it is a judgement about a person's circumstances.

Before you configure anything

Two questions to settle first, because they are much harder to change later.

Who counts as an approver, and is it one person or a chain? A chain is safer for larger teams and slower for everyone. Decide before people start submitting.

What happens to the reason field after the leave has passed? Records you keep are records you are responsible for. If you have no reason to keep it, decide the retention rule up front rather than discovering years of it later.

Get those two right and the rest of the path takes care of itself, because the records are already shared. The board does not need to be told anything. It already knows.