Load User

Reads one user record out of Clarive and puts it in the stash, so the rest of the rule can test the person rather than guess. Typical uses are pulling an address before Send a notification, checking whether an account is still active before a workflow moves on, and turning a login name into the resource id that other ops want.

It only reads. To change what a user is allowed to do, use Managing User Roles.

Fields

User

Which user to read. The list starts searching once you have typed three characters and matches on either the user id or the full name, showing each person's full name with their user id beside it. What gets stored is the user id, never the full name and never the address. The form will not let you save the op with the box empty.

Only enabled accounts are offered in the list, and system accounts are never offered. Neither restriction applies to the lookup itself, so typing the id of a disabled account still reads the record back.

The field also takes text you type yourself, which is how variables get in. ${username}, ${topic.owner} or a plain id such as foo_user are all accepted, and ${var} placeholders expand against the stash before the lookup runs.

At run time the lookup is an exact, case-sensitive match on the user id. A full name, an email address, a partial id or an id with different capitalisation all find nothing, and finding nothing stops the op with a message naming the value it looked for. A variable that resolves to an empty string produces that same not-found failure rather than a missing-user error, which is worth remembering when the value comes from a topic field that may be unset.

One user per op. To walk a list of people, put this op inside FOREACH CI and pass the loop variable in.

Mid only?

Off by default. Off, the op returns the user's whole record. On, it returns a single value, the user's mid, and nothing else.

Turn it on when all you need is the id to hand to another op that expects a resource, such as an owner or an assignee. Leave it off when the rule has to look at the person's details.

A user who does not exist fails the op either way. The checkbox does not make the lookup more forgiving.

What lands in the stash

Nothing reaches the stash unless you fill in Return Key in the op's options. Without it the record is read and dropped.

With Mid only? off, the key you name holds a map. The entries you can count on:

Entry	Holds
account_type	regular for a person, system for an internal account
active	1 when the account is enabled, 0 when it is not
created_on	when the account was created
date_format_pref	a date mask such as DD/MM/YYYY, or format_from_local when the person never picked one
email	the address
groups	the user groups the person belongs to, as resource ids
language_pref	the interface language
mid	the resource id
project_security	one entry per role-and-scope pair, each naming the role, the scope resource and the kind of scope
realname	the full name
time_format_pref	a time mask such as HH:mm, with the same format_from_local default
ts	when the record was last changed
username	the user id

Both format entries hold a marker rather than a mask until the person opens their preferences and picks a format, so a rule that formats a date with the value has to handle format_from_local.

The rest of the person's preferences ride along, timezone and country among them, together with the bookkeeping fields every resource carries. Treat anything not in the table as present-if-set rather than guaranteed.

Read the parts you want with dotted paths: ${user_doc.email} in a notification field, user_doc.active as the variable in IF var condition THEN.

Setting Return Key to = merges the record into the top of the stash instead of nesting it. That looks convenient and rarely is: it drops entries named username, mid, email, groups and active over whatever the rule already had under those names, and several of them are names other ops depend on. Use an ordinary key.

With Mid only? on the return is a single value, so = has nothing to merge and gives you a stash entry literally named =.

What is left out

The stored password and the user's API key are stripped before the record reaches the rule. No setting brings them back.

Failure and rollback passes

A user who cannot be found stops the op. What that does to the rule is up to the op's Error Handling setting. Throw Errors ends the rule. Ignore Errors carries on and leaves the Return Key untouched, so the key stays unset, or keeps whatever an earlier op put there. Pick Ignore Errors when a missing account is a normal outcome you plan to test for afterwards.

The op changes nothing, so it has nothing to undo, but it does run again on a rollback pass unless you untick Run Rollback. It re-reads the record at that point, so a rule that alters the user in between sees the later values on the way back.

Combining with other ops

Load the person, then branch on them. active, groups and project_security are the entries rules test most, with IF var condition THEN doing the comparison and FAIL nested inside when the answer is wrong.

Feed email into Send a notification when the recipient is decided by the rule rather than by a role.

Turn on Mid only? and hand the result to an op that wants a resource id, such as the owner field on Create a new topic.

Pair it with Managing User Roles: load first to see what the person already has, change second, and read the returned record to confirm.

Examples

Pull the details of the person who triggered the rule and keep the address for a later notification.

User         ${username}
Mid only?    off
Return Key   requester

Refuse to continue when the account named on a topic has been disabled.

User         ${topic.owner}
Mid only?    off
Return Key   owner_doc

IF var condition THEN
  When: Any
    owner_doc.active   EQUALS   0

Turn a login name into a resource id for an op that expects one.

User         foo_user
Mid only?    on
Return Key   assignee_mid