In-Memory State Changes

The In-Memory State Changes mapping function detects whether specific fields of a ticket, event, or message have changed since the previous processing cycle.

It compares the current values of selected fields with their previous values.
If a change is detected in any of the monitored fields, the mapping returns true. If no change is detected, the mapping returns false.

This function is commonly used in polling integrations to ensure that updates are only processed when relevant data has actually changed.

Attributes for In-Memory State Changes Mapping

Attribute	Required	Description
From	Yes	Defines the identifier of the object being monitored, such as the ticket ID, event ID, or message ID.
To	Yes	The field where the result of the state change evaluation is stored (true or false).
Precedence	Yes	Defines the precedence used when mapping.
Function type	Yes	Defines the function type of the mapping. Must be "Enrichment/lookup function".
Function	Yes	Defines the type of mapping. Must be "In-Memory State Changes".
Fields	Yes	A list of fields separated by ; that will be checked for changes.
Capacity	No	Maximum number of objects stored in the internal cache used to track state changes. Default: 1000000.
Expiry	No	Time in seconds before cached state entries expire. Default: 3600 seconds.

---

How It Works

1. The From field identifies the object (for example a ticket or event).
2. The Fields parameter defines which fields should be monitored for changes.
3. During processing, the mapping compares the current values with the previously stored values.
4. If any field listed in Fields has changed, the result is: true. If none of the monitored fields changed, the result is: false

Discarding Unchanged Messages

If the To field contains DISCARD, messages that do not have a state change will be discarded.

This is useful in polling integrations where large numbers of records are retrieved but only actual updates should be processed.

Example behavior:

• Fields changed → message continues through the workflow
• No fields changed → message is discarded

This prevents unnecessary processing and reduces load on downstream systems.

Example

Fields configuration status;priority;assigned_to

Behavior:

• If status, priority, or assigned_to changes → result = true
• If none of these fields change → result = false

If the mapping uses: To = DISCARD

Then messages without changes will be automatically removed from the workflow.

Typical Use Cases

• Polling ServiceDesk systems for ticket updates
• Detecting changes in monitoring events
• Avoiding duplicate processing of unchanged records
• Reducing unnecessary API calls to destination systems

Options for state change

Mapping	How it detects changes
In-memory State Change	Uses an internal cache
Persisted State Change	Uses message history