Delete mapped notices · Fieldmotion API

When to use this endpoint

Use Notice_deleteData for CRM2 single-row or bulk deletion. The endpoint always adds the current user as a filter, even when IDs or other fields are supplied.

Authentication and permissions

The request must authenticate with signed API-key fields or a logged-in CRM session. The handler requires login and performs no additional page or role-permission check.

The read or write is limited to the authenticated tenant. Notice endpoints that say “current user” use the authenticated session user ID within that tenant.

Parameters

Parameter	Type	Required	Description
`flagIsFiltered`	Integer-compatible	No	CRM2 bulk-delete control. Exact integer `0` replaces the submitted ID list with every current-user notice ID. A nonzero value retains the supplied mapped filters.
`id`	Integer-compatible or native array	No	One ID or IDs to delete. In the normal filtered/single-row flow, only IDs owned by the current user match.
`subject, body, meta, metaCreatedBy`	Scalar or native array	No	Additional exact mapped filters accepted by the generic delete helper.
`status, cDate, cDateUnix, dueDate, originalID, sDate`	Scalar or native array	No	Additional exact integer-converted mapped filters. `userID` from the caller is overwritten with the current user ID.

Example request

$result = FM_api('Notice_deleteData', [
	'id' => ['49018', '49019'],
	'flagIsFiltered' => '1',
]);

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 filter"}`	The request does not contain a mapped caller filter and does not explicitly request the established `flagIsFiltered=0` delete-all workflow.
`{"error":"Could not read records for deletion. Please retry."}`	The pre-delete selection fails.
`{"error":"Could not delete records. Please retry."}`	The hard-delete statement fails.
`{"error":"Could not record deletion audit."}`	Rows were already deleted but the bulk deletion audit helper reports failure.

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

Behaviour and edge cases

Unfiltered bulk deletion includes app-push notices. With flagIsFiltered=0, the endpoint selects every notice for the current user before deleting. It does not apply the CRM-visible filter used by the bell, so app-push rows are included.

If flagIsFiltered=0, any caller-supplied IDs are replaced. When the user has no notices, the generated empty-ID filter safely matches nothing and returns success.
With no flag, at least one caller-supplied mapped filter is required. Current-user ownership is always added but no longer counts as sufficient delete intent.
When flagIsFiltered is nonzero, it is removed before generic processing; submitted IDs and other mapped filters are combined with current-user ownership.
The route does not update users.meta.notices_latest or notices_seen. Header counts are recalculated on the next read.

Side effects

Hard-deletes matching notice rows, invalidates the notices cache, records each deletion in the tenant deletion audit, and writes a Core delete history event.

See it in Fieldmotion

CRM1

No direct CRM1 caller was found; CRM1 uses Notice_delete for one row.

CRM2

On Notifications, use a row’s delete action or Delete all displayed. Filtered bulk deletion sends the displayed ID array; an unfiltered confirmation sends flagIsFiltered=0.

Related endpoints

Notices_getDataTable supplies the displayed IDs and filters.
Notice_delete is the simpler unaudited CRM1 route.