Hi Helga,

A simple solution to this would be to use a before commit microflow and check whether the client state of the object and the database are the same with a decision. If not, create a simple notification object for the owner of the task. But this solution is not the best, especially with a lot of attributes and different actions for each of them when they are changed. 

The parameter is the state of the object in the client, with a retrieve you can get the object before it was potentially changed and check this in a decision.

Helga,

You can accomplish this using Java Action MemberHasChanged from Community Commons module in a microflow that is called as a Before Commit event handler on an entity.  Here is an example of what that looks like:

I will walk through each step:

We get the GUID of the object so that we can use that ID to store all changes to a specific object in the database

This Java action tells us if a member has changed.  In this case it is a Date attribute.  You can use this Java action for attributes of any type.

If the attribute has changed, the updated value will be available via standard microflow expressions

This Java action will give us the original value of the attribute.

We then create a description

Finally, we record the changes in a tracking entity.  Note that because we store the GUID in attribute ObjectID, we can create a generic microflow and page to retrieve and display all attribute changes for a specfic object.

Hope that helps you out,

Mike