Scott - In answer to your follow on question, you can do the following:
This will ensure that only those users with Administrator access can update the value, and if the scheduled event microflow is not exposed via the user interface, no one will have the capability to update this via a browser (or mobile app).
What this won't do is ensure that another developer won't write a microflow that updates the value, or that the field won't be included on a page where it can be updated. The modeler does not have this kind of security checking during development AFAIK, i.e. there are not user roles for developers. What you can do is during acceptance testing and code review for new versions, check usages of the attribute and see if there are other microflows that update it (in your domain model, right mouse click the attribute and select 'Find Changes in Microflows' from the popup menu to see what microflows change this attribute, next select 'Find Usages' in the same menu to see what pages the attribute is used on)
The quick workaround would be to create a list, iterate over all the objects and add them to the list when total > threshold. If you have very many objects you should do this in a batch.
But is there a reason not to change the calculated attribute in a normal one?
Regards,
Ronald
[EDIT]
By using the after commit event or after delete event it does not matter what other part of the application does with the object. That will also trigger the aftter commit event and thus update the value.
Scott,
I am putting this in an answer because it is too long to fit in a comment.
Calculated attributes are calculated every time an object is retrieved, even if the calculated attribute is not displayed or used on a page. As a consequence, calculated attributes can have a significant impact on performance and use lots of server resources. In the case you describe, it seems like there may be a large number of expense objects for each category (if this is an expense report model), so this calculated attribute will wind up being expensive. For instance, lets say you have 50,000 expense records. Each time you retrieve or display a category object, those 50,000 records will be retrieved and summarized. If its a larger application, you'll have that activity taking place over a larger number of records. If my assumption of a large number of expense records is correct, this attribute is not a good candidate to be a calculated attribute.
I would suggest the following alternative approaches, both involve changing the calculated attribute to a stored attribute:
Hope that helps,
Mike