---
summary: 'The attribute model behind signatures: names, sources, precedence and provenance.'
order: 2
title: Attributes
path: concepts/attributes
status: published
---

# Attributes

A signature is only as good as the data behind it. This page explains which attributes
templates can use, where their values come from, and how the console tells you why a signature
shows what it shows.

## One vocabulary: the Active Directory names

ScaiLine uses the Exchange/Active Directory attribute names as its vocabulary. In the template
designer you pick them as fields; you never need to know where a value is stored.

`givenName`, `sn`, `displayName`, `mail`, `proxyAddresses`, `title`, `department`, `company`,
`physicalDeliveryOfficeName`, `telephoneNumber`, `mobile`, `facsimileTelephoneNumber`,
`streetAddress`, `postalCode`, `l` (city), `st` (state/province), `co` (country), `employeeID`,
`manager`, `preferredLanguage`, `thumbnailPhoto`, `extensionAttribute1` to
`extensionAttribute15`, plus `custom.*` for anything specific to your organisation.

Why these names: Microsoft Entra ID's properties are renamed AD attributes, on-premises AD and
LDAP use the originals, and administrators already know them. For almost every source the
mapping is the same name or a single rename, so adding or replacing a directory source never
touches a template.

## Directory sources

| Source | Status |
|---|---|
| ScaiKey | Available. Reads the users assigned to the ScaiLine application, with groups and organisational units, and follows changes as they happen. |
| CSV | Available. Imports are currently run by ScaiLabs support; upload in the console is planned. |
| Microsoft Entra ID | Planned. |
| LDAP / Active Directory | Planned. Until then, sync your directory into ScaiKey. |
| Google Workspace | Planned. |

## ScaiKey holds the signature-only fields

Directories rarely hold everything a signature needs: a LinkedIn URL, a pronoun line, a
signature-specific title, the legal entity. A tenant administrator can install ScaiLine's
**attribute pack** under **Attributes**: it adds the attribute set above to your ScaiKey
directory as custom attributes on users and organisational units, together with a small
`scailine_*` pack (`scailine_linkedin_url`, `scailine_pronouns`, `scailine_title_override`,
`scailine_legal_entity`, …). The install uses your own administrator session, so it can only do
what you are allowed to do in ScaiKey.

ScaiKey's own fields map directly: `first_name` is `givenName`, `last_name` is `sn`, `email` is
`mail`, `phone` is the fallback for `telephoneNumber`, `avatar_url` is `thumbnailPhoto`, and the
manager and organisational unit come from ScaiKey's directory.

## Sources and precedence

For every attribute there is an ordered list of candidate sources. ScaiLine walks the list and
takes the first value that is not empty. Every organisation starts with working defaults; under
**Attributes** you see the effective list per attribute, can change it for your organisation, and
**Reset** returns to the default.

| Source | Meaning |
|---|---|
| `scaikey:<attribute>`, `csv:<column>` | A value from a directory source. |
| `inherit:ou` | Walk up the user's organisational units, nearest first. Define an office address or switchboard number once on the unit instead of on every user. |
| `location` | The office the user belongs to, derived from the organisational units. |
| `tenant_default` | A constant for the whole organisation. |
| `override` | Reserved for approved self-service changes (planned). |

## Provenance

Every value is stored with its source and the time it was fetched, and the console shows it per
attribute under **Profiles**. When someone says their title is wrong, you see at once where to
fix it.

## Manager

`manager` is stored as a reference and shown as a name. Coverage is often incomplete, so put a
manager line in a conditional block (*visible when the field is not empty*). When a manager is
renamed, the signatures of everyone reporting to them are recompiled automatically.