How it works
The connector moves approved time from Clockify, a product of CAKE.com, into Microsoft Dynamics 365 Business Central, a product of Microsoft. When a time entry is approved in Clockify, the connector writes it into your Business Central as a project journal line and posts it to the project ledger, so project cost and profitability live where your accounts live. The connector is built by Spainlink and is not a product of CAKE.com or Microsoft.
This page explains the three parts of the system, follows one entry through it, and states the guarantees the design makes.
The three parts
| Part | Where it runs | What it does |
|---|---|---|
| Clockify | Clockify cloud | Your team tracks time; managers approve it. Approval is the trigger for everything |
| Spainlink sync service | Microsoft Azure | Receives the approval signal, reads the entry from Clockify, applies your mapping, validates, and writes to your Business Central. Stateless serverless functions: a webhook receiver, a queue worker, and a 15 minute timer |
| Connector extension | Your Business Central | Adds the Clockify entry id fields, a staging table, the custom APIs the sync service talks to, posting date validation, the append-only sync log, and the role center your team uses |
The journey of one entry
Take a concrete case. Maria tracks 1.5 hours on the Clockify project mapped to PR00010, Installation of S-200 Server, and her manager approves it.
- Approval in Clockify. Nothing syncs before this point. Pending or rejected entries never touch your Business Central.
- The webhook fires. Clockify notifies the sync service the moment the approval happens, and the entry typically posts within seconds. A scheduled sync every 15 minutes is the backstop: it re-reads a trailing window of days, so an entry that a webhook missed is picked up by the next scheduled run.
- Validation before writing. The mapping must resolve: Maria to a resource such as CL001, the Clockify project to PR00010, the task to a posting task such as 1000. The posting date must be allowed: the connector checks the posting ranges in General Ledger Setup and User Setup and the open accounting periods through a dedicated validation endpoint before it writes anything. The posting date is Maria’s own calendar day in her time zone, not the server’s day.
- The journal line is written. The line carries the Clockify entry id, the quantity as decimal hours, and the cost. Clockify owns cost in version 1: each line carries the member’s cost rate, or the billable rate if no cost rate is set. Prices and billing to customers are not set by version 1, and version 1 is USD only.
- The line is posted to the project ledger. The Clockify entry id travels with it onto the posted entry.
- Every step is logged. The write, the post, and anything unusual each leave a timestamped row in the sync log.
Zero duplicates, structurally
Every entry carries its Clockify entry id into your Business Central, on the journal line and carried through to the posted ledger entry. Before writing, the sync service asks your Business Central what it already has. And even if the same entry were sent twice, your Business Central itself refuses the second copy, because the extension rejects any line whose entry id already exists, unposted or posted.
The guarantee therefore does not depend on the sync service remembering anything. Re-running a sync is always safe, and a replayed webhook cannot double an entry.
Held, never guessed
If an entry arrives whose person or project has no mapping, the entry is stored and shown as waiting. The connector never invents a resource, a project, or a task, and never posts to a best guess. A held entry costs you a short review; a wrong posting costs far more to unwind. See The mapping model for how mappings are defined.
Immutable postings, and how corrections work
Posted entries are immutable. That is a Business Central accounting principle, and the connector respects it completely.
If someone edits an entry in Clockify after it has posted, the connector flags the entry for review and never silently alters the books. A person decides what to do. Corrections are made as reversal entries that net to zero, so the original posting, the reversal, and the replacement are all visible and the trail is complete.
The append-only audit log
The extension keeps a sync log inside your Business Central that records every write, every post, every modification flag, and every staging deletion, with timestamps. It is append only: nothing in it can be edited or deleted, by anyone, including administrators. It is built for finance review and compliance, and it stores business keys rather than personal data.
What your team sees
Everything day to day happens inside your Business Central, in the standard interface:
- A role center with tiles: Received, In Journal, Posted, Failed.
- Charts: hours per person, and hours and amounts by project.
- A time entries list where every failed entry shows its own error message, so the fix is named rather than hunted for.
- The sync log, filterable to a single entry.
There is no separate portal to learn for daily work.
Data handling
The sync service is stateless. It keeps no database of time data: it reads Clockify, validates, and writes your Business Central. Your time data at rest lives in Clockify and in your Business Central, and nowhere else.
The only configuration the sync service stores is the mapping document. Telemetry and operational logs are redacted: no names and no entry descriptions appear in them.
Security
- No Clockify or Microsoft credentials are ever stored inside your Business Central.
- The extension ships a least-privilege permission set that grants exactly what the connector needs.
- The webhook endpoint verifies a cryptographic signature on every call, per registered webhook.
- The operations dashboard is used by Spainlink operators only and sits behind Microsoft Entra sign-in. Your team monitors everything inside your Business Central.
For how the connection is set up in practice, see Getting connected.