Custom record field query

Don't use custom record fields for filtered aggregations, they calculate across entire dataset regardless of UI filters.
https://docs.appian.com/suite/help/25.3/custom-record-fields.html?utm_source=chatgpt.com#sync-time-evaluations
You can try below 2 methods.
Display the source eventPoint field directly in grid and apply date range filters in a!recordData() query(custom fields bypass grid filters)
Query filtered records using date filters, then calculate sum in the interface instead of custom field.

I suggest you to move the logic to get sum of the points in the interface instead of the record. Custom Record field cannot relate to the filtered set by user , they work with entire dataset.

keerthis065835 said:

How to handle single row data calculation in appian records

I tried referencing the eventPoint field directly in the grid and applied date range filters using a!recordData(). However, I’m only getting the first 10 rows of data, even though there are over 500+ rows for that date range. Is there any restriction causing this?

I hope you are using 25.2 as it has default limit of 10.
You can increase this limit using a!relatedRecordData() parameter.

As mentioned, custom record fields do not support live query filters. Their logic is static.

I have done this type of thing before, but it's a bit weird to set up.

The core conundrum: to perform an aggregation without limitations on the total rows in a relationship, a!aggregationFields() in a!queryRecordType() works really well since you can setup groupings and measures. But read-only record grids don't support a!aggregationFields in their fields inputs.

A technical workaround is to put a!queryRecordByIdentifier() with a!aggregationFields() on each row of your data (or sum() with an embedded query). If the number of rows in your grid is small, and your dataset is small, you can get away with this in theory. However, there are severe performance issues in non-ideal conditions. Querying data in each row of a grid is an anti-pattern, breaks many best practices, and is not recommended in any production environment.

The trick (with caveats) is sync'ing the record grid with a separate single query that leverages a!aggregationFields with groupings on appropriate identifiers. Then your record grid can perform an index/wherecontains into your single query based upon row identifiers that match the grouping id's of the query. The pagingInfo of the grid can be saved it into a local variable for use by the query. However, record grids do not expose the selected record filters* for use by other Appian components. So for that to work, the grid filters need to be managed as UI objects separately - i.e. it really is a pain to deal with.

This a gap that Appian might be able to solve, one day, with enough pressure from customers. It's a fairly common use case for small reporting dashboards and task management queues.

*technically-speaking, there are some 'tricks' to get the filters, but I wouldn't recommend them.