Employees

Employees are Custom Link’s other master-data entity, covering operator and driver records. For clients, see Clients.

When to use

Situation	Command
Look up employee/operator records	RequestEmployees
Create or update an employee	StoreEmployees

Retrieving employees

RequestEmployees follows the same filter shape as clients — retrieve by Id, number, or search.

Response fields (TEoEmployeeMx)

Field	Type	Description
EmployeeId	key	Internal database Id.
Number	string	User-assigned employee number (not the database key).
Name	string	Employee’s name.
AddressHome	address	Home address.
ConnectivityHome / ConnectivityWork	connectivity	Home: fax, mobile, phone, email. Work: mobile, phone.
IsActive	boolean	True = visible, False = invisible.
Deleted	boolean	True = in the trash bin, False = not deleted.
DrivingLicense	string	Driving license number.
Planning	boolean	True if this employee is a planner.
Management	boolean	True if part of management.
VehicleNo	int	Default vehicle number for this employee.
ContractStart / ContractEnd	dateTime	Employment contract dates.
Permissions	permissions	This employee’s Custom Link/TMS permissions.

Creating or updating an employee

StoreEmployees follows the same convention as clients: an EmployeeId/Id that is zero or negative creates a new record; positive updates the existing one.

Response uses the shared EoStoreResultList shape.

Thinner documentation upstream

Employees have less published example detail than clients in MendriX’s own reference material. Validate your payload against GdxEoStructures.xsd (TEoEmployeeMx) and confirm required fields with your MendriX contact before building against this command.

Gotchas

• A Custom Link token’s access to Employees is all-or-nothing — if the token’s section is denied (DenyAll), every RequestEmployees/StoreEmployees call fails with a Security: no permission for request <ClassName> error, the same as clients. Administration-level scoping still applies independently and can narrow results without an error.
• StoreEmployees is not rejected for skipping a prior retrieve — the server updates the DB row directly, the same as StoreClients. But unlike clients, there is no server-side fetch of the existing row before storing — the payload you send is written as-is, so omitted fields can overwrite existing data. This makes retrieve-before-update more important for StoreEmployees than for StoreClients.

Related commands

• Clients — the other master-data entity.
• GdxEoStructures.xsd — TEoEmployeeMx field definitions.