Docs › TekReady

Section — Active Directory

Last updated 2026-07-14

Section — Active Directory

What this section captures

The Active Directory section defines how user records flow from the customer’s AD (or Entra ID) into the ITSM tool. It answers two questions:

Which AD attributes map to which ITSM user fields? (e.g. sAMAccountName → Login, mail → Email, department → Department.)
Which AD attributes are the key fields used to identify and deduplicate users on import?

Why it matters

Get the mappings wrong and the ITSM tool ends up with duplicate users, or with fields the help desk needs for routing tickets sitting empty. Get the key fields wrong and a renamed user is treated as a brand new person, breaking ticket history.

How to fill it in

Add a row for every AD attribute the customer wants to surface in the ITSM tool. For each row, set the source AD attribute name and the target ITSM field.
Use the Key field tick-box on the row(s) that identify a user uniquely. Typically objectGUID or sAMAccountName.
Set a Role on each key field row to tell the import job whether the key is primary (used for matching) or secondary (used for tie-breaking).

Common patterns

Mostly on-prem AD	Use `objectGUID` as the primary key field. It survives renames and re-OUs better than `sAMAccountName`.
Entra ID / hybrid	Use `userPrincipalName` as the primary key, with `mail` as a secondary tie-breaker.
No AD at all	Leave the section empty and submit it — manager will approve as “not applicable”. User records come from the ITSM tool’s built-in directory.

Approval implications

This section follows the standard four-state approval lifecycle: Draft (editable) → Submitted (locked, awaiting the customer’s Manager) → Manager Approved (locked, awaiting the Partner approver) → Final (fully signed off and locked). A reviewer can reject the section back to Draft, with a reason, at either approval step.

Once Final, no further field mappings or key-field changes can be made without a reviewer rejecting the section back to Draft. This is intentional — user-record behaviour is foundational to the rest of the ITSM build, so changes shouldn’t slip in unannounced.