“HR can see it” is an incomplete permission rule. It does not say which HR employee, which people they support, which information they need or when the responsibility ends. The same problem appears in rules for managers, finance partners and service teams. A familiar role label can hide a very broad access decision. Role-based visibility has to answer those questions.
The practical unit of access is a responsibility in context. A regional HR partner may need employment details for one population. A manager may need information relevant to an active reporting relationship. A service-desk analyst may need the facts required to complete an approved task. These responsibilities overlap, but they do not justify identical views.
A role-based model is useful when it expresses these distinctions. It becomes less useful when a large role name substitutes for the analysis that should determine the permission.
Decide what a user is trying to do
Start with a concrete task. A colleague looking for an expert needs professional information that helps judge relevance. A manager reviewing a lifecycle request needs the employee context and decision details appropriate to that request. A payroll specialist has a different purpose and may use a separate system.
The GDPR’s data-minimization and purpose-limitation principles provide a legal foundation for making these distinctions where the regulation applies. They do not prescribe one universal software role matrix. GDPR, Article 5
A practical access specification should connect the task to the necessary fields and population. It should describe why the access exists in language an operational owner can understand. If the explanation is simply “this role might need everything,” the design still has work to do.
The specification should also identify information that belongs outside the directory altogether. Restricting a field is not always the right answer; excluding unnecessary information may be the more appropriate choice.
In role-based visibility, scope matters as much as the role
Organizations often focus on vertical differences between employee, manager and administrator. Horizontal scope can be equally consequential. A manager’s access should relate to the people and responsibilities they actually manage. A country HR team should not automatically receive the same access as a global specialist.
Business units, relationships, locations, or a controlled assignment can define scope. Each choice needs a reliable source. If the source is incomplete, the permission design should not silently expand access as a convenience.
A role can also have several scopes. A person might manage one team and support a separate temporary project. The system should preserve the reason for each grant so that removing one responsibility does not remove or perpetuate the other incorrectly.
This is where simple lists of names become difficult to maintain. The organization needs a way to connect access to the responsibility that justifies it, with clear handling of additions, removals and conflicts.
Role-based visibility does not make sensitive content appropriate
The Hamburg authority’s 2020 H&M enforcement case concerned extensive employee information about private circumstances, including health and family matters. The case illustrates the consequences of inappropriate collection and use as well as access arrangements; it is not evidence that adding more permission roles solves every privacy problem. Hamburg data protection authority
A collaboration directory should therefore resist the assumption that more detail always produces a better profile. Employees need to understand why information is present and how the organization uses it. Private circumstances should not enter general people-search or recommendation processes merely because a technical integration makes them available.
Where a specialist process legitimately requires sensitive information, that process needs its own purpose, audience and safeguards. A general HR label does not supply those decisions.
The design review should ask whether someone could complete the same task with less detail. Sometimes a status or confirmation is sufficient, while the underlying sensitive record remains in the specialist system.
Permissions must change when responsibilities change
Under role-based visibility, access should have a beginning and an end. A person promoted to manager may acquire a new scope. A manager moving to another team may lose the old scope while retaining a limited handover responsibility. A temporary project assignment may expire without changing the person’s permanent role.
These transitions require explicit rules. Removing access immediately may interrupt a justified handover; retaining it indefinitely may create unnecessary exposure. The organization needs to choose the appropriate interval and record the reason for any extension.
Exceptions should have owners. If an administrator grants temporary access to resolve an operational issue, the record should identify the purpose and review or expiry condition. Otherwise the exception becomes difficult to distinguish from a permanent entitlement.
Periodic review remains useful, but it should complement event-driven changes. Waiting for an annual review to notice that a responsibility ended months earlier is a weak substitute for connecting permissions to the underlying change.
A field-level model needs consistent output behavior
Microsoft’s public HR data-lake account describes differentiated and column-level access in its own analytics environment. It is a concrete example of controlling access within a data platform, not a claim that one configuration automatically covers every connected application. Microsoft’s HR data-lake account
The role-based visibility lesson for a directory is to trace each output path. A field hidden on a profile should not reappear through a search result, export, cached preview or generated answer available to the same user. The system needs to enforce the rule wherever it retrieves and releases information.
Aggregates need attention too. A summary for a very small group can reveal information about an individual without displaying a named record. The appropriate limits depend on the information, purpose and population.
Testing should compare paths using the same user and scenario. If the profile and export produce different access outcomes, the organization needs an explicit reason. Treat inconsistent behavior as a defect in the control design, not merely a display issue.
AI does not remove the need to govern the source
Microsoft states that Microsoft Copilot operates within the user’s source permissions. That means excessive permissions remain excessive; it also means a separate application’s visibility policy should not be assumed to control unrelated retrieval paths. Microsoft Copilot privacy documentation
For role-based visibility in an AI-assisted people service, identify the identity used for retrieval, the sources queried and the policy applied before the answer is produced. The answer should not include information that the user could not appropriately retrieve for that purpose.
Actions require a further check. Being allowed to view a manager’s name is not the same as being authorized to change the manager. Being able to discover an agent is not the same as being permitted to invoke all its tools.
This separation should be understandable in the interface. A user can be told that a responsibility is visible while a requested action needs another authorization. Clear boundaries are preferable to a broad promise that the assistant can “do anything with your people data.”
Operate role-based visibility as a service
A permission model needs an owner who can explain and maintain it. HR should own the meaning and appropriate use of employment information; security and IT should help implement and test the controls. Operational managers should validate that the access supports the tasks people actually perform.
Useful reviews examine specific transitions and exceptions. Can a former manager still see the previous team’s restricted information? Does a temporary assignment expire? Can a regional user export records outside the approved scope? Can an administrator explain why an exceptional grant exists?
Measures should focus on these outcomes, not the number of roles configured. More roles can improve precision or create an unmanageable catalog. The difference depends on whether the model remains understandable and tied to real responsibilities.
Apply the boundary where work happens
TeamConnect AI can connect shared people context with governed directory and agent experiences. TeamJML AI can carry the consequences of role and employment changes into lifecycle actions. In a combined design, retained responsibilities should remain explicit so that a move removes only access that is no longer justified.
The customer still needs to define the purposes, populations and review rules that the software applies. These decisions should be tested across the profile, workflow, export and AI paths that users actually rely on.
The strongest permission rule is one an owner can explain without referring only to a configuration screen: this person can access this information for this responsibility, within this scope, until this condition changes. Building that explanation into the operating model makes access easier to review and harder to leave behind when the organization moves on.
References
- Regulation (EU) 2016/679. 2016.
- Hamburg data protection authority: H&M service-centre decision. 2020.
- Enabling advanced HR analytics and AI with Microsoft Azure Data Lake. 2023.
- Data, Privacy, and Security for Microsoft 365 Copilot. Accessed September 18, 2026.