Employee objects
Employee configuration maps an M-Files user account to an object in the vault that stands for the person. It is a short section — an object type and the lookup property on it that points at a user — but several features are unavailable without it.
The vault needs the object type and the property before either can be named here. See Vault structure, which also covers why exactly one employee object should point at each user account.
While no employee configuration is set, the application status in M-Files Admin carries a warning recommending one. It is a warning rather than an error: portals still load.
What the mapping is used for
Section titled “What the mapping is used for”Comments are attributed to an employee object rather than to a user, so the author’s name links to a real object a reader can open, and mentions resolve to the same person.
Elsewhere, a column holding a user in a list or multi view is rendered as the employee object behind that user rather than as a plain user lookup, so it opens and behaves like any other object reference.
Avatars
Section titled “Avatars”Image property is optional, and is the only part of this section that is. It names a text or multi-line text property on the employee object, and what goes in it is the picture itself, encoded as base64. Converters for this are widely available online.
Two forms are accepted. A complete data URI beginning data:image/ is used as it stands.
A bare base64 string is inspected for its first few characters, which is how the type is
established, and only PNG and JPEG are recognised that way — a bare GIF, SVG or WebP falls back
to a placeholder avatar rather than showing.
Keep the picture small. The whole string is stored as a property value on the employee object and fetched once per author, so a full-size photograph costs more than the comment feed it appears in.
Only the comment feed draws avatars. Leaving the property unset costs nothing else.
What the caches mean in practice
Section titled “What the caches mean in practice”The mapping from user to employee object is cached in the vault application. A user who is not in the cache is looked up on demand, and a user with no employee object is remembered as a miss for an hour — so a newly created employee object can take that long to be recognised.
Cache Update Frequency governs a different cache: the list of vault users that mention search reads. Raising or lowering it does not affect how quickly a new employee object is picked up.
If the object type or the user property cannot be resolved in the vault — an alias that no longer exists, an object type that was deleted — the cache is not built at all and every employee feature is unavailable. The vault application log says so by name. Correct the references and restart the vault; the cache is rebuilt on the next start rather than on save.
Settings
Object type
This is the object type that is used for employees.
User property
This is the property that is used to store the user reference.
Image property
This is the property that is used to store the employee's image.
Cache Update Frequency
This is the frequency at which the user cache is updated. Default: Once per hour.
Employee configuration settings, generated from CtrlPortals 3.26.9.53.