AJAX Search (Active Directory)
A type-ahead search against Active Directory, for choosing a person from your organisation's directory.
Where to find it
Architect Panel → Data:
- Datastores — the datastore, then Table Designer to add or edit a field
Architect Panel → Security:
- Authentication Methods — directory-backed sign-in
Architect Panel → Integration & Connections:
- Azure AD Tenants — directory connections
What it is for
Any field naming a member of staff — an owner, an approver, a reviewer, a contact — where your directory already holds the authoritative list.
The argument for it
- No second staff list to maintain. The directory is already correct and already maintained by somebody whose job that is.
- Leavers disappear from the picker without anybody remembering to remove them.
- Consistent naming, rather than three spellings of the same person.
It does not join
Like the URL search, the value comes from outside and there is no local record behind it, so reporting through it is limited compared with a local link.
If you need to report heavily on people — workload by owner, cases by team — consider whether directory provisioning into local user records gives you a better shape, and use those.
Plan for the directory being unavailable
The field depends on it. If the directory cannot be reached, the picker returns nothing, and a form requiring it cannot be completed.
Say so when it happens rather than showing an empty list, and think about whether the form should still be submittable without it.
Search on what people type
Colleagues search by name — usually surname, sometimes first name, occasionally both in either order. Make sure the search handles that, and consider including something distinguishing in the results, because two people share a name in most organisations of any size.
Scope what is searchable
A directory contains more than current staff — service accounts, shared mailboxes, disabled accounts, contacts. Offering all of it makes the picker noisy and lets somebody choose a mailbox as an approver.
Restrict to what should legitimately be chosen.
The value can go stale
Somebody stored as an owner today may leave tomorrow. The stored value does not update, so a record can name somebody who no longer works there — which is correct as history and unhelpful as a current assignment.
Where the field drives work allocation, plan for reassignment when people leave rather than relying on the field to notice.
Directory data is personal data
Names, e-mail addresses and job titles are information about your staff. Ordinary in this context, and still subject to the same care about who can see it and how long it is kept.
Worked example
A change request datastore uses directory search for the approver, restricted to enabled staff accounts and showing the department beside each name. When the directory is briefly unavailable the field explains why rather than appearing empty. A monthly check reassigns open requests whose approver has left.
Recommendations
- Restrict the search to accounts that should be choosable.
- Show a distinguishing detail — names repeat.
- Handle the directory being down explicitly.
- Plan for leavers named on open records.