Integration log

See everything mTime sent to your other systems, and everything they sent to mTime, with the outcome of each.

Overview

When mTime talks to an external system — a payroll system such as Dataløn, Intega Løn or SLS, the payroll file, Google Calendar — or receives an update from one such as VOM, it records an entry in the integration log. Use it to answer “did this reach the other system, and if not, why?”

Go to Admin › Integration Log.

The list updates by itself while it is open: new entries and status changes appear without reloading.

Who can see it

When parts of an entry are hidden from you, its details say so: Parts of this row are hidden because your role cannot see them… An empty section then means “hidden”, not “nothing was sent”.

How it works

mTime records one entry per thing it delivers — typically one per employee, per day and per registration. The entry is created before mTime contacts the other system, and updated with the outcome once the call is done. If something changes later (a time off is edited or cancelled), mTime updates or deletes the registration in the other system, and that is recorded too.

For each outbound call, the entry records:

• which integration and which employee it concerns,
• a reference identifying what was delivered, such as a code and a date (or the file name, for a payroll file),
• the action taken in the other system: create, update, delete, or none,
• the status of the delivery,
• who caused it and when it was created and last updated,
• the requests sent — the exact web address, request and, for failures, the other system’s answer,
• mTime’s own delivery details, such as the registration code, the units sent and the error message.

Passwords, keys and other credentials are never stored in the log.

Statuses

Outbound entries (calls mTime made):

Inbound entries (updates mTime received):

Failed deliveries are retried

For the integrations that support it, a daily retry job sends again the deliveries that failed or were interrupted during the last 3 days. You don’t need to do anything for a temporary failure, such as the other system being briefly unavailable. A delivery that keeps failing — because of a wrong code or a locked payroll period, for example — needs a fix in mTime or in the other system.

Find entries

The toolbar narrows the list:

The list shows the 200 most recent matching entries, newest first. If you are looking for something older, narrow the period or the filters.

Your filters are kept while you work, and are part of the page address, so you can send a colleague a link to the same view.

Read an entry

Click a row, or use View Details , to open Integration Call Details . From top to bottom:

1. A highlighted note, when there is something to explain:
   • Re-created after external deletion — someone deleted this registration directly in the other system, and mTime re-created it.
   • Nothing to send or Already deleted upstream — why a skipped entry sent nothing.
   • Not applied — why an inbound update was ignored.
2. The summary: Reference , Employee , Created At , Updated At , Created By , Updated By , Direction , Source Event , Action and Status .
3. Delivery details — what mTime recorded about the delivery, such as the registration code, the units and, for a failure, the error message. The error message is the one-line reason the entry failed.
4. Requests sent — what actually went to the other system, in order. Each request shows its URL , Headers , Request and, when it matters, the Response . The last request is the one that decided the outcome and is opened; earlier ones (for example a delete before a re-create) are collapsed — click to open them. An entry with no requests sent nothing: it is still pending, nothing was needed, or it failed before the call.
5. Event — the change in mTime that caused the delivery, with its timestamp, type, author and payload. The owner can click the heading to Open in Event Log .

An entry about a whole payroll file, rather than one person, shows a dash under Employee .

How long entries are kept

Entries are not deleted automatically. They stay in the log, so you can look back at what was sent at any time. The entries about an employee are removed together with the rest of their data when the employee is permanently deleted under employee data retention.

Troubleshooting

Use the log to work out where a registration got stuck:

1. Filter on the integration and the employee (search by name), and set the period to when the change was made in mTime.
2. Include all statuses, so you also see what was sent successfully.
3. Open the latest entry for the day in question and read its status.