User accounts and profiles
Deactivate a user account
/a/User_deactivate
Suspend a tenant user’s active status while retaining their profile and linked records.
When to use this endpoint
Use for an existing user who should stop being active. This is a status change, with no deletion, reassignment or job cancellation.
Authentication and permissions
Authenticate with signed API-key fields or a logged-in CRM session. Session requests use the dispatcher’s CSRF protection when configured; signed requests follow the API-key authentication flow.
Client administrator access is required. With hierarchy enabled, the dispatcher also validates the resulting access relationships and outstanding Job assignments.
The dispatcher applies configured TeamAccess user-record scope before the handler. An explicit target outside that scope returns an error; omitted targets use the current user for the scope check. Active/deleted filtering and additional target checks are described below.
Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
id | Integer string | Yes | Target user ID in the authenticated tenant. Parsed with intval; this is a single-record operation, with no pagination or sort controls. |
Example request
$result = FM_api('User_deactivate', [
'id'=>'1042',
]);Example response
{
"ok": 1
}Errors and unusual responses
| Response | Condition |
|---|---|
{"error":"not logged in"} | No authenticated tenant context is available. Invalid signed credentials can be rejected by the dispatcher before the handler runs. |
{"error": "missing or invalid parameter: id"} | id is omitted, null, or converts to an integer below 1. |
{"error": "only admins can do this"} | Caller is not a client administrator. |
{"error": "you cannot deactive your main FieldMotion account"} | Target is the account’s main identity; message spelling/casing is literal. |
{"error": "you cannot deactivate yourself"} | Target is the caller. |
{"error": "user does not exist"} | No tenant row matches. |
Legacy application errors may be returned with HTTP 200. Check the decoded response for error, not only the HTTP status.
Behaviour and edge cases
- Owned tenant and global rows must exist before mutation. The account’s main identity and the current caller cannot be deactivated. Already-inactive targets remain accepted.
- No active filter or capacity check is added for deactivation. Target ownership is verified in the authenticated account before updating status.
- When department hierarchy and team access is enabled, the dispatcher wraps this User write in its access-relationship validation and can reject changes that would strand outstanding Jobs. This does not make file storage, session updates or separate global identity writes one atomic operation. Without that wrapper the handler itself has no enclosing transaction; read back saved state after an uncertain failure.
- No collection filtering, pagination, ordering or batch result is provided. Parameters on this page describe the supported scalar/encoded input; malformed nested values are not a supported contract.
Side effects
- Updates active=0 and edit markers in both identity stores; clears employees/local caches, logs the change, recalculates tenant licence counts and clears cached employer data.
- Does not explicitly invalidate existing browser sessions or tokens; it does not remove the user’s jobs, departments, skills or files.
See it in Fieldmotion
CRM1
Open Users → Main and click Deactivate. Filter for User_deactivate; CRM1 sends the selected id and then reloads the profile.
CRM2
No direct caller was found. The CRM2 Activate/Deactivate widget submits active through User_updateData.
Related endpoints
User_activate— Restore active status after a suspension.User_setPermissions— Configure general/admin permissions separately.