Database schema changes update Entities "Modification Date"

Hi – I’ve built an automation based on the “Modification Date” of entities to automate the update of a Kanban board we review on a weekly basis.

The goal is to focus on the past week progress and plan the current one. Inactive items are progressively moved to older columns.

I worked around – see LastHumanModifcation field – the fact that my automation itself updates the modification date of the items but now my problem is that whenever we change the structure of the Database of these items, their modification date gets modified and thus identified as “active” items…

Is it a design choice to update the “Modification Date” of each entity or just a “side effect”?

Thanks!

2 Likes

Could you elaborate what you mean by change the structure of the Database?

If I understand correctly, you have created a field “Last human modification”. If you set up your automation such that it updates this date field whenever fields of your choice get updated, the hard programmed modification date should be irrelevant.

I have a very simple, similar automation which updates the “Updated” date field to today, whenever a status info is updated.

1 Like

This did not seem to be a specific Feature Request so I’ve moved it to “Get Help”. If it evolves into a more clear needed new feature (or bug), it can be moved again. Apologies if I’ve misinterpreted, I am happy to move it back right now if you’d like.

1 Like

Hi Eren – thanks for taking the time.

For instance, adding a new “Checkbox” field results in 2 “operations” – adding the field & setting it to false. I suspect the last operation to be the source of the new Modification Date

As I want to capture any changes on fields and links – like new commits, PRs, etc… – I figured it would be easier to base my logic on the Modification Date :sweat_smile:
But you approach could be better than the ugly hack I’m putting in place :laughing: – I would need 3 automations to make it work but at least I would have full control.

image

Thanks for your help!

There’s still the update of “Modification Date” when adding or removing fields but not really sure it’s an issue.

What would you like to achieve that you think would need 3 automations?
Perhaps we can help with some ideas for optimisation…

I guess so yes, that’s why I hide that field and use an extra field. Just add all triggers you want to update your field and you should be good to go :smile:
Working with the modification date for this use makes it unnecessarily complicated.

1 Like

As I said, I’d like to detect when an Entity – Feature, Task, whatever the name :slight_smile: – is “updated” or get some activity, like:

  • Someone added a comment
  • A rich field is updated
  • The State is updated
  • Something related on Github happens – new branch, commit, PR
  • Another entity – e.g Meeting note – is linked or unlinked

Maybe I can get rid of tracking “unlinking” events, but anyhow I can’t track with the same automation events coming from 2 triggers: Field Update & Link Creation. Or can I? :sweat_smile:

Actually, I can track multiple Fields changes with 1 automation, but it seems that I need 1 automation per linked entity :sob:

Unfortunately it is not possible to combine linking, unlinking, and updating automations, so you would definitely need quite a few automations (and yes, one per relation :frowning: ).
Also, there is no way to directly monitor ‘rich-text field’ updating I’m afraid (you could make an ugly workaround that checks for changes on a schedule, but it’s not easy/pleasant).

There used to be a ‘modification date’ but making it aceesible introduced too many risks of endless loops. Also, there is no universal agreement on what counts as a modification when there is so much connectivity.
If A is linked/unlinked to B, have they both been ‘modified’? What if formulas are defined that recalculate based on other field / relation changes? Does an update to a formula count as a modification?

2 Likes

Understood and I totally appreciate the complexity of it.
Thanks everyone for the :zap: responses :pray:

Just to summarize everything:

  • Modification Date can be updated for many reasons both internal and user-based
  • Prefer a dedicated field to record the “last update” of an entity
  • And one or multiple automation(s) to track the relevant changes
  • :warning: Rich-Text fields changes can’t be tracked
1 Like

After further testing, it appears Rich-Text changes do not trigger an update of the Modification Date

Hi all!
Just a gentle update here that all your requests were noted and linked to the feature we have in the backlog :wink:
Your votes made that feature a couple of step closer to delivery :sweat_smile:

2 Likes

Indeed.
Rich text (and documents) are kinda managed separately from ‘normal’ fields.

1 Like