I need to keep track of daily maintenance activities from my Assets (Manufacturing machines).
To improve our maintenance tasks, would be great to have a daily repeating tasks and create kind of a checkbox if that day an spare part was replaced, or if on that day the machine had X failure and how often it happens. Like keeping a machine Journal that includes different activities.
I think the easiest way to visualize it might be a heatmap or in the calendar view, I tried to create a similar view of a repeating event, but I am not sure if it is possible or not. Any ideas out there?
I don’t want to create every day a new entity, I want to know if that entity is able to save a track record over the time.
If something like this is not possible, I can change the topic to Ideas & Features.
Let me see if I understand you correctly. You have a database (table) of machines and possibly other assets, and want to keep a digital maintenance log/journal per asset/machine.
If I understand it correctly, then having one entry per day per asset, is the only correct approach from a data model standpoint, in my opinion. Even if a system allowed you to visually put these all inside one field, it would still be using a table in the backend to track them, but it would be less adapted to your specific needs.
I would recommend:
Creating a maintenance_entries database (table), with fields such as:
a date/time field
a select for type of log entry, e.g. routine, error, repair, etc.
a select that goes into more (still normalised) detail, e.g. the actual error pr success codes
a select that shows the outcome of the logged event, e.g. scheduled, active, finished, issue, skipped
a note field for audits later, e.g. why was it skipped, what happened, etc.
a user fields showing who carried out the event and recorded its log.
anything else you would want to report on, later.
Connecting the assets database (table) to the maintenance_entries via a relation field with one-to-many cardinality, i.e. each asset can have many log entries. You can even add a button or automation to create log entries for maintenance staff to check off later.
Now, you can aggregate and report on the log entries to get the info you need per asset or across multiple assets in several ways:
Using formula fields on assets, with lookups of related log entries inside the formulas.
Using different views with groupings, filters, nested levels and aggregations.
Note: you can decide to only track critical events, which would mean that you would only have entries for when there is a problem or need for reporting, though in my opinion, having prescheduled entries assigned to users is a much safer way to ensure the maintenance checks are indeed handled.
I hope this helps. Feel free to let me know if I misunderstood your use case.
thanks for the well described solution approach, indeed I need a Database for the maintenance logs separated on different categories like repair, error, planned maintenance, etc. This DB will be related to the Asset DB like you mention.
Maybe I am missing the structure point, let me try to structure it the way you mention and elevate it with formulas or buttons.
Based on my poor description you understood pretty well my needs, thanks again
I indeed tried with AI, my promt was more or less what I described on my post “Create a log/journal for the maintenance tasks, I want them to be categorized on 5 Different records like X,Y,Z..”
A new Workspace called Maintenance tracker was created with the following Databases with fields:
Maintenance task DB.
Name
Description (Rich text field)
Task log (Relation, One Task has many logs)
State (Workflow, but I did not need that one)
User
Task log DB.
Name
Date
Description (Rich text field)
Files
Maintenance Task (Relation)
User
Overall well executed. After that, I created a calendar view with the Logs DB and the Date field so I could see when and what happened.
The calendar has a lot of potential to analyze this data, not just like a Graph, but like I mentioned a Heatmap of the occurrence. You might already have it on your plans to polish it, maybe adjust the views, zoom out to the Months or in to the days, etc. But that is another topic.
Of course I just typed in some basic data, along more machines and more activities, this will be daily high populated. Then I can filter based on activity or to asset/machine, even both!
I am glad the AI builder helped out. It is quite good at its duties!
However, in that setup above, I see a few things I wanted to point out before you end up using it and getting locked in to its structure:
Maintenance task DB:
Based on the lack of a date field, I presume these are maintenance task types, and not the actual tasks, which is why I would rename it to Maintenance Task Types or even just Maintenance Types. This means that this DB is being used instead of just a simple select, so that a task type can have a description, user, state, etc.
You would need something like state (which it has created, but you mentioned that you did no need it), imagine:
You come up with a new type of maintenance task, but it cannot be used yet, since you are reviewing it. You could set its state to “under review”.
You decide that a certain type of maintenance task should not be used any more. You could set its state to “deprecated”.
Task log DB:
Presuming that the first DB is for task types (which have no context/relation to assets/machines in the current setup), then a task log entry should somehow be connected to your assets/machines DB, so that you can know on which specific asset/machine is a task type being carried out in a specific task log. You would do this through a relation field from assets/machines DB to this task log DB with one-to-many cardinality.
Missing normalised fields for later filtering, grouping, aggregation and reporting, except for “Maintenance Task”. I would suggest selects (or relation fields to a central DB holding options) for state, outcome, codes, etc.
I hope the above helps. I apologise, if I am mistaken in my analysis of your specific structure/needs.
