Fieldmotion API Getting started

Tasks

Update mapped task data

POST /a/Task_updateData

Update supplied mapped task fields with field history, mention notices, and notification-service events.

When to use this endpoint

Use Task_updateData for CRM2 layout, inline, calendar, and Kanban edits. It changes only mapped keys present in the request.

Authentication and permissions

The request must authenticate with signed API-key fields or a logged-in CRM session. The handler calls the normal login guard but performs no additional task, page, role, ownership, or privacy-permission check.

All reads and writes use the authenticated tenant. CRM1 and CRM2 apply task visibility and editing permissions in their interfaces, but these handlers do not repeat those client-side rules.

Parameters

ParameterTypeRequiredDescription
idInteger-compatibleYesOne active task ID. The shared helper nominally accepts an ID array, but this wrapper’s previous-user, mention, and notification logic assumes a scalar; use one ID per call.
type / status / privacy / minutesInteger/float-compatibleNoMapped task type, status, privacy, and stored time. Values are coerced without related-row/allowlist checks.
details / resolution / subjectStringNoEditable text. Details is marked required by the layout map, so an explicitly blank details value is rejected; newly added @username tokens can create notices.
user / userIDNative picker object / integerNoAssigned user. Picker user.id expands to userID. Supplying either also writes the prior assignee into meta.previousUser; it does not refresh assigned_date.
customer / customerIDNative picker object / integerNoCustomer identity. Picker customer.id expands to customerID.
assignedDate / createDate / lastEdited / dueDateDatetime stringNoMapped datetimes. Blank values become SQL null; an actual change also appends current last_edited, overriding a supplied historical value in the final assignment list.
createdBy / appId / editedIdInteger / integer / stringNoMapped creator/mobile/edit fields. Layout readonly/hidden flags are not server-side restrictions.
meta / customValues / metaPreviousUserString / JSON-compatible / integerNoComplete metadata, custom JSON, or the nested previous-user metadata value. Automatic previous-user handling can overwrite a submitted metaPreviousUser when assignment is supplied.
noRecord / noRecordCustomNative arraysNoField/custom keys whose audit metadata is marked hidden.
_pollAnyNoRemoved before mapped persistence.

Example request

$updated = FM_api('Task_updateData', [
	'id' => '318',
	'subject' => 'Confirm revised access details',
	'dueDate' => '2026-10-03 10:00:00',
	'status' => '1',
]);

Example response

{
  "ok": 1
}

Errors and unusual responses

ResponseCondition
{"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 absent.
{"error":"missing or invalid parameter: details"}Details is explicitly supplied as blank.
{"warning":"no updated fields."}No supplied key maps to a stored task field.
{"warning":"No data."}No active task matches the scalar ID for the requested mapped columns.
{"warning":"No Change."}All supplied mapped values compare equal after type/JSON normalization.

Legacy application errors may be returned with HTTP 200. Check the decoded response for error, not only the HTTP status.

Behaviour and edge cases

  • Mapped keys are type, details, resolution, userID/user, assignedDate, status, customerID/customer, createDate, lastEdited, createdBy, appId, editedId, privacy, meta, subject, dueDate, minutes, customValues, and metaPreviousUser. Unknown keys are ignored; active rows only are selected.
  • Numeric types are coerced; JSON is compared structurally; blank datetime/JSON values become null. Read-only/hidden layout flags are not enforced as authorization.
  • Although the shared updater supports ID arrays, this wrapper is not array-safe: its previous-user lookup and notice link integer-coerce a nonempty ID array to 1, while notification dispatch receives the array rather than one object ID. It also returns only aggregate success. Integrations should not use multi-ID input here.

Side effects

  • On a real change, updates mapped columns/current last_edited, invalidates the task cache, and writes one audit-history entry per changed mapped field.
  • Creates CRM notices for newly added @username tokens in subject, details, or resolution, linked to Task Main.
  • Calls the notifications service with update and time actions. It does not call Task_sendAssignedNotification; assignment changes therefore do not use the legacy reassignment-mail path.

See it in Fieldmotion

CRM1

No direct CRM1 caller was found; CRM1 uses focused setters and Task_update.

CRM2

Open Tasks in list, calendar, or Kanban view. CRM2’s configured Task Create/Update layouts use the mapped Task_createData, Task_getLayoutDetails, and Task_updateData routes.

Related endpoints