Skip to main content

Start Field Added to Time Entries

Patrick Bakker
Time Entry

The time that people spent on requests, problems, changes, and projects is important
input for any support organization. For Managed Service Providers (MSPs) this data may
even be used to charge their customers, generally by using it as input for an invoicing
tool. Effort classes can be used to add an additional classification to time entries, for
example to distinguish rates between business hours and overtime. When a time entry
overlaps two or more of such rate periods, the specialist would add multiple entries with
the appropriate effort classes. By adding the Start field to the time entry record, this is
no longer necessary.

To be clear, for most users this enhancement has no impact at all. The Start field is
populated automatically and may be ignored if an organization has no use for it. The way
it is populated depends on the situation.

When a specialist worked on a request, task, or other assignment and adds a time entry,
the value in the Start field is calculated by subtracting the time spent from the current
time. Imagine for example that Howard worked for 20 minutes on request #70445 and
writes a note with that time entry at 10:00 in the morning:

Request note time entry

If he then clicks on that time entry, he sees the edit form of the time entry pop up, showing
the time he worked on the request and the presumed start time of his work, being 09:40
am. He is then still able to edit those fields.

Edit time entry start

When a specialist adds a time entry via a time allocation, the Start field is set to the
start of the working hours of the person on that day. The reasoning behind this is that
when using this method, time entries are often entered some time after the work was
done. The specialist can of course still edit the start time.

The Start field is always displayed in the user’s time zone and is also accessible by
APIs and import/export, as started_at.