Contact Details

Contact details — who knows a phone number, and who gets to change it

A person in FreeITSM is more than a login. Beyond an email address and a password, their record holds a job title, department, office, phone, mobile, employee ID and who they report to — the things an asset register, an approval chain and a service desk actually need in order to reach somebody.

There are four ways those details get filled in, and the whole design is about keeping them straight:

Who fills them in	Where	What they may change
An analyst	Tickets → Users or Assets → Users	all seven
The person themselves	Self-service portal, My Account	job title, office, phone, mobile - whichever of those an administrator allows on System → Portal profile
A directory	automatically, on every import	all seven, and nothing else may touch them
A CardDAV address book	automatically, on every import	five of the seven - not employee ID, and not manager

Where a person comes from

Tickets → Users and Assets → Users name it. Select somebody and their details say, for example, Details from: Baikal - address book (Tickets) or Kept up to date from the address book Baikal (Assets); somebody who only signs in through single sign-on says Signs in with instead. In the Assets list, the flag reads Address book or Directory accordingly.

Both lists also have a Source filter - everyone, only the people added in FreeITSM, or just the people from one directory or address book, with a count beside each. It only appears once at least one person is linked to one, and the counts only include people in the companies you can see.

Which details go read-only, and when

A record kept up to date from somewhere else shows those details greyed out, because the next import would overwrite anything typed here — an edit that silently reverts an hour later is worse than one that says no.

Which details depends on where the person came from, and this is not cosmetic:

Source	Read-only	Still yours to fill in
LDAP / Active Directory	all seven	—
CardDAV address book	the five it holds	employee ID and manager
CardDAV with write-back on	none	all seven

🔴 The middle row was wrong until recently, and the bug is worth knowing about. Every managed record locked all seven fields regardless of source — but a contact card has nowhere to keep a payroll number or a reporting line, so a CardDAV import never sets those two. They were greyed out and refused on save on behalf of an import that would never populate them: permanently unfillable, while the help text cheerfully said the import left them alone.

The bottom row follows from the reason itself. Fields are locked because the next import would overwrite them — and an address book with write changes back switched on does not have that problem, because what you type is sent to the card. The justification disappears, so the lock does too. See CardDAV contact sync.

---

An analyst editing somebody

Either people screen will do — Tickets → Users if you came in from a ticket, Assets → Users if you came in from a piece of equipment. Both open the same editor (includes/person_editor.php), so it never matters which door you used. Manager access beside Edit opens the full-screen page for what that person can see as a portal manager.

Select a person, choose Edit, and fill in what you know. Everything is optional. Three of them earn their place beyond tidiness:

• Office tells you which site somebody is at before you set off looking for them, and is one of the fields a directory fills in for you (physicalDeliveryOfficeName). ⚠️ It does not feed the ticket asset picker — that searches an asset's own location, from asset_locations, and never reads users.office.
• Employee ID is the join key the day somebody reconciles FreeITSM against a payroll system that has never heard of an email address.
• Manager records the reporting line - type part of a name to find them. It doesn't route approvals today - catalogue request approvals go to a designated analyst - but when portal managers are switched on, a person's manager can see their tickets in the self-service portal.

Blank fields are left out of the person's detail panel rather than shown as a column of dashes, so what you see is what somebody actually answered.

---

Somebody keeping their own details current

A signed-in portal user opens My Account from their initials in the top-right, and can now maintain job title, office, phone and mobile themselves, alongside their preferred name and their password.

This exists because the alternative is worse. A phone number that changed is a phone number the service desk cannot reach, and routing every correction through a ticket means most of them never get made. Letting the person fix it themselves is both faster and more likely to be right — they know their own mobile number better than anyone.

They see a note saying only the IT team can see these details. That is worth leaving in place. People are reasonably cautious about typing a mobile number into a web form, and the honest answer — it goes to the service desk, nowhere else — is what makes them willing to do it.

Choosing which ones

System → Portal profile has a tick box for each of the four. On a new or upgraded system all four are ticked, which is what the portal has always offered. Untick one and it disappears from the portal form; nothing already stored is removed, and analysts can still change it. The setting can only narrow the four - the three below cannot be switched on from it.

What the portal deliberately does not offer

Department, employee ID and manager are not editable by the person themselves, and the reasons are different in each case:

• Manager — nobody should choose their own approver. Nothing routes along the reporting line yet, so this is not a hole today; it would quietly become one the day approvals start following the chain, by which point a portal full of self-chosen managers would already be in place.
• Employee ID — a payroll number is a claim about who you are in another system, not a contact detail.
• Department — an organisational fact the service desk maintains. Somebody moving themselves between departments is other people's data changing under them.

The line is "what does this person know better than the service desk?", not "what is harmless?".

---

When a directory is the source of truth

Where somebody was imported from LDAP or Active Directory — see Directory sync — the same details are read-only everywhere: on both analyst screens and in the portal. Each screen says so, in place, rather than letting an edit through.

That is a deliberate refusal rather than an oversight. The next sync would overwrite anything typed locally, so an edit accepted now and reverted overnight is precisely how somebody concludes FreeITSM lost their change. Refusing it immediately is the kinder answer, and it points at the fix: change the value in the directory, and it reaches FreeITSM on the next run.

Everything that is not the directory's stays editable on those records — the person's preferred name, their portal password, their company, their theme. Only the seven person fields are locked.

---

Why this is worth bothering with

The short version: the people in FreeITSM should not be an island.

The longer version came from issue #133, where an operator running his own CardDAV address book pointed out that setting FreeITSM up had meant typing his customers in a second time, and that the two lists would drift from that moment on. He also made a data-protection argument: if customers can correct their own details, the correction becomes theirs to make rather than the service desk's obligation to chase.

He was right, and the useful discovery was that the portal did not let anybody edit their own contact details at all — so the self-correction his argument rested on did not exist yet, before any question of syncing it anywhere. That gap is what this page describes, and it was worth having on its own merits. ✅ FreeITSM now speaks CardDAV in both directions — see CardDAV contact sync.

✅ His data-protection argument is now answered, as a choice for each organisation. Write-back sends an analyst's correction to the address book. His scenario was a customer correcting their own details in the portal. That is now possible too, but off by default, because it lets customers write into the operator's address book: tick Let them change these too, and send their change to the address book on System → Portal profile. It only reaches address books with write-back switched on.

With it on, a customer's change is sent to the address book first and saved in FreeITSM only if the address book accepts it - the opposite order from an analyst's edit. An analyst told "the address book refused this" can do something about it; a customer cannot, and a local save the address book refused would be put back by the next import, which is exactly the vanishing edit this page is about avoiding. A refusal (the server is unreachable, or the same detail was changed on the card since the last import) changes nothing anywhere and tells the person so. Each write is in the address book's write log, marked as the person's own change from the portal.

---

See also

• Tickets — the analyst people screen, in context
• Directory sync — importing people, and the rules that keep it safe
• Self-Service Portal — everything else a portal user can do
• CardDAV contact sync — importing these details from an address book
• CardDAV write-back internals — how a change here reaches the address book, and what it will not do
• CalDAV and CardDAV — the analysis this came out of, and CalDAV, which is still open
• Contact details — Developer Guide