FSM Search Filters and Retrieval

Note:

This topic is intended for administrators and developers who define search filters and control record retrieval.

A filter condition normally contains a search field, an operator, and the comparison value. Combine conditions with and or or. Use nested arrays to make the intended grouping explicit.

The following CRM Task filter restricts results to tasks assigned to the current employee that have a linked case:

          [
  ["assigned", "anyof", "${user.internalid}"],
  "and",
  ["case.internalid", "noneof", "@NONE@"]
]

The valid operators and comparison values depend on the field type. For example, a List/Record field typically uses an internal ID with anyof. A checkbox uses a value such as "T" or "F" with is. Search joins must be available for the searched record type.

Template tags can supply values from the current context. Ensure that a tag resolves to a value accepted by the filter. For substitution and value-type rules, see FSM Expressions and Template Tags.

This topic covers:

Mapped Filter Objects

A filter object can use names defined in the same map. For example:

            {
  "record": "task",
  "filters": {
    "caseId": "${event.supportcase}"
  },
  "map": {
    "id": "internalid",
    "caseId": "case.internalid[record]"
  }
}

Here, the caseId map identifies the search field and its List/Record format. The helper uses that information to build the filter. Use this example only where the event supplies a linked case ID. For more complex conditions, an explicit filter expression makes the operator and grouping clearer.

An explicitly supplied filter array replaces an inherited filter array when configuration is merged. Include every condition that must remain. In particular, preserve restrictions that associate records with the current job, employee, customer, or asset.

Overriding a product-supplied search can change downstream processing as well as the displayed results. Consider the affected processing paths and configuration choices when changing filters or mappings. For example, changes to Consumable inventory options can expose unavailable or inconsistent stock details. With automatic fulfillment enabled, resulting processing errors can exclude related case work from later processing. An override doesn't necessarily fail. For the capability-specific risks and choices, see Inventory Search Overrides and Processing Risks in Configuring FSM Consumable Processing.

Parent Relationships

For a resource that uses article.parent, FSM supplies a parent filter when article.filters is not already supplied. If you configure your own filters, include the required parent restriction yourself. Setting article.parent still supplies the parent value for new records. This property doesn't add the parent restriction to an existing custom filter expression.

Other Filter Forms

The following table lists the filter forms accepted by the standard search helper.

Value	Resulting Condition
An internal ID, such as `123` or `"123"`.	`internalid anyof` that ID.
An array of internal IDs, such as `[123, 456]`.	`internalid anyof` those IDs.
`true`.	`internalid noneof @NONE@`. This condition doesn't restrict the search to active records.

Value

Resulting Condition

An internal ID, such as 123 or "123".

internalid anyof that ID.

An array of internal IDs, such as [123, 456].

internalid anyof those IDs.

true.

internalid noneof @NONE@. This condition doesn't restrict the search to active records.

For context that may be missing, prefer an explicit filter expression with a nonmatching ID value, as in ["internalid", "anyof", "${ event.supportcase || 0 }"]. A direct filters: 0 enters the helper's default-filter path. This setting doesn't mean a search for internal ID zero. Preserve the other record restrictions needed for the intended behavior.

FSM Search Filters and Retrieval

Mapped Filter Objects

Parent Relationships

Other Filter Forms

Additional Information

Related Topics