Entra ID user attributes: the right access starts with good employee data

Not every field matters equally. These are the attributes that directly affect accounts, permissions, licences and workflows.

These are exactly the attributes that change regularly. And when nobody updates them, IT often only notices when an onboarding or an approval gets stuck.

`employeeHireDate` and `employeeLeaveDateTime` are the two fields Lifecycle Workflows schedule on. A joiner workflow runs a number of days before or on the start date, a leaver workflow on or after the leave date. The time counts too. Workflows never run before the time in the field, and the tenant processes them on its own schedule, which runs every three hours by default. Microsoft therefore recommends a time early in the day for the start date and late in the day for the leave date.

Writing employeeLeaveDateTime is better protected than the other fields. An app needs the User-LifeCycleInfo.ReadWrite.All permission, and anyone setting the field by hand in a delegated session needs the Global Administrator role. Reading it works with the Lifecycle Workflows Administrator or Global Reader role. If you do not know this, you can spend a long time looking for the reason a script cannot set the field.

`manager` points to another user object; it holds no name. You set it with a separate call, and it is only right once the manager has an account of their own. The org chart in Microsoft 365, the approvals in access packages, the tasks in Lifecycle Workflows that email the manager and the dynamic rule Direct Reports for all read this reference. After a reorganisation it is the field that stays wrong the longest.

Connect-MgGraph -Scopes "User.ReadWrite.All"

$upn = "jan.jansen@bedrijf.nl"
Update-MgUser -UserId $upn `
  -Department "Financiële administratie" `
  -JobTitle "Medewerker crediteuren" `
  -EmployeeId "100482" `
  -UsageLocation "NL" `
  -EmployeeHireDate "2026-12-01T05:00:00Z"

$manager = Get-MgUser -UserId "petra.smit@bedrijf.nl"
Set-MgUserManagerByRef -UserId $upn -BodyParameter @{
  "@odata.id" = "https://graph.microsoft.com/v1.0/users/$($manager.Id)"
}

Sometimes you need more than the standard fields, a cost centre for example. Microsoft offers two places for that. They look alike and are often confused.

If you use the fifteen extension attributes, record somewhere which one serves what purpose. The names say nothing, and a second administrator who finds extensionAttribute7 "free" unknowingly overwrites the cost centre that three dynamic groups run on. Microsoft also points out that you should not put sensitive personal data in them, such as a national identification number or medical data.

In a hybrid environment this is the first thing administrators run into. A user synchronised from Active Directory has AD as its source. You then change fields such as department, jobTitle and the extension attributes in AD; in Entra ID they are read-only for that account, and the next synchronisation would overwrite your change anyway. How that sync works and what source of authority per object means is covered in Entra Connect or Cloud Sync.

A one-off check helps, but it is better still when changes from HR are passed on automatically.

Start with an overview of active accounts where one of the driving fields is missing. Those are the people for whom the automation is already failing silently.

Connect-MgGraph -Scopes "User.Read.All","User-LifeCycleInfo.Read.All"

$velden = "Id","UserPrincipalName","AccountEnabled","Department","JobTitle",
          "UsageLocation","EmployeeId","EmployeeHireDate","UserType"

Get-MgUser -All -Property $velden -ExpandProperty Manager |
  Where-Object { $_.AccountEnabled -and $_.UserType -eq "Member" } |
  Where-Object { -not $_.Department -or -not $_.JobTitle -or -not $_.UsageLocation -or
                 -not $_.EmployeeId -or -not $_.Manager } |
  Select-Object UserPrincipalName, Department, JobTitle, UsageLocation, EmployeeId,
    @{ n = "Manager"; e = { $_.Manager.AdditionalProperties.userPrincipalName } } |
  Export-Csv .\ontbrekende-attributen.csv -NoTypeInformation -Encoding UTF8

1. 1Run the overview and sort by department. Empty fields are rarely scattered at random: often it is one team, one site or everyone who started after a certain date.
2. 2Look at the spelling. Count how many people there are per department. "ICT", "IT" and "I.C.T." side by side means three dynamic groups that each miss some people.
3. 3Record which system is the source for each field. For department, job title, start date and manager that is almost always the HR system, not the administrator who creates the account.
4. 4Repeat the check every month. A field that was right at creation is often wrong after the first transfer.