Loading

User Search

A search that picks a user of the platform itself.

Where to find it

Architect Panel → Data:

  • Datastores — the datastore, then Table Designer to add or edit a field

Architect Panel → Security:

  • Permissions — the groups a chosen user belongs to

Architect Panel → Data:

  • Datastores — the record the user is being attached to

What it is for

Any field naming somebody who uses the system: an owner, an assignee, a reviewer, an author, a manager.

Why not a text box

Because a typed name is not a person. It cannot be matched reliably, it appears in three spellings, it does not change when somebody's name changes, and no report can group by it with confidence.

A user search stores a reference to the actual account, which is what makes "cases by owner" a query rather than an approximation.

It joins, so it reports well

Single-select and joinable — so ownership and assignment reporting works properly, and the chosen user's other attributes are reachable from the record.

Platform users, not directory objects

This searches accounts in the platform. Where your users come from a directory and are provisioned in, those accounts are here and this is the right field.

The directory search is for naming somebody who may not be a platform user at all. If the person needs to use the record, this is the one you want.

Assignment implies access

The thing most often missed. Naming somebody as owner does not give them permission to see the record.

If ownership should confer access, that is a record access role — the two work together, and the field alone changes nothing about what they can reach. An application that assigns work without granting access produces people who have been given something they cannot open.

Restrict who can be chosen

Not every account should be assignable. Filtering to a relevant group — the team who handle this kind of work — keeps the list short and prevents work being assigned to somebody who cannot do it.

Leavers

A disabled account can still be named on historical records, which is correct — the history should say who owned it. What needs attention is open work: records still assigned to somebody who has left need reassigning, and nothing does that automatically.

Make it part of your leaver process, and check for it periodically.

Show enough to choose

Names repeat. Including a department or a role in the results avoids the wrong Sarah being assigned, which is otherwise found out days later.

Worked example

A case datastore uses a user search for the owner, filtered to the caseworker group and showing each person's team. Ownership grants access through a record access role, so assigning a case gives the owner the ability to open it. The leaver checklist includes reassigning open cases.

Recommendations

  • Never store a person as typed text.
  • Pair assignment with a record access role if ownership should grant access.
  • Filter to the relevant group.
  • Reassign open work when somebody leaves.