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.