Inside TimeTac Connect: How TimeTac Handles Integrations with ETL, Recipes, and Reusable Components

The problem landscape: many great tools, no shared data

In the DevTalk session titled TimeTac Connect, How we handle Integrations by Anna Kastner (TimeTac), the spotlight was on a challenge nearly every growing company faces. Modern software landscapes are built from specialized tools. A company starts with accounting. As headcount grows, it adds a human resources system. Project management follows. Eventually, the need to track working hours arises — that is where TimeTac comes in.

Each tool may work well in isolation. Trouble starts when the tools do not exchange data. HR ends up maintaining the same information in multiple places, ensuring correctness and timeliness across systems. For small setups, this might still be manageable. For larger organizations, this becomes error‑prone, time‑consuming, and hard to scale. The obvious remedy is to establish data exchange so systems function together. In other words, build integrations.

Integrations demand more than endpoints: stakeholders, architecture, implementation, testing, support

Anna Kastner emphasized that integrations are not an afterthought. They involve coordinated activities: communication among stakeholders, architecture work, conceptual design, implementation, testing, and long‑term support. This matters because integrations are not just technical adapters; they are part of how products and teams collaborate. To do them well, requirements must be captured precisely, expectations aligned, and the resulting components designed to be robust and maintainable.

Why TimeTac built its own framework

TimeTac already had integrations in place: separate procedures and functions inside the main project for specific use cases. This worked, but as the variety of scenarios grew, it made the landscape harder to manage. The team wanted to bring these efforts together into a unified foundation.

They evaluated commercial frameworks. These turned out to be expensive and did not offer the flexibility TimeTac needed. At the same time, the team had the knowledge and resources to build components in‑house and reuse them effectively. The decision followed: create an in‑house integration framework. That framework is TimeTac Connect. Its purpose is to synchronize data between systems while reusing existing components and making new integrations predictable to implement.

Another deliberate choice was to keep TimeTac Connect separate from the main TimeTac product. This yields an agile workflow, independent release cycles, and reduced complexity in the core. Decoupling the integration layer from the product helps with maintainability and avoids burdening the main codebase with integration logic.

Architectural approach: ETL at the core

For TimeTac Connect, the team chose a familiar pattern from integration practice: ETL. Anna Kastner outlined the three phases and the corresponding building blocks.

• Extract: Read data from a source. Extractors encapsulate data fetching.
• Transform: Change data into the structure the target needs. Transformers do this work. They carry a clear single responsibility: change the structure of the data.
• Load: Write data to a target. Loaders execute the data delivery according to the chosen mechanism.

Before you can extract, transform, and load, you need to connect. That is the purpose of Connectors — components that establish connections to concrete locations. TimeTac Connect can attach to multiple types of systems, including:

• Microsoft Azure via an API
• a local Active Directory
• file systems by connecting to an SFTP server
• external databases

Each location and transport is handled by a dedicated Connector. That separation of concerns makes components reusable and keeps responsibilities crisp.

Recipes: integrations as a puzzle of building blocks

Within TimeTac, the term recipes describes individual integration flows. A recipe combines the pieces — Connector, Extractor, Transformer, Loader — into an executable pipeline. The puzzle metaphor fits: you assemble the right pieces rather than reinventing functions. The same SFTP Connector with an Extractor and a Transformer can serve multiple scenarios. That consistency makes implementations predictable and maintainable.

Common TimeTac integrations

Anna Kastner highlighted two patterns that recur across customer setups.

User provisioning from HR to TimeTac

User provisioning is an interface that synchronizes data from a company’s HR system to TimeTac. Creation, maintenance, and deactivation of user accounts in TimeTac become automated. This reduces administrative load and error risk by reflecting the HR system as the source of truth inside TimeTac.

ERP integration: projects, tasks, and time export

Many organizations maintain projects and tasks in an ERP such as SAP. That data is synchronized to TimeTac so employees can track time against specific projects. The time tracking data generated in TimeTac is then pushed back to the ERP or other systems for further processing, analysis, or payroll accounting. Exports can run daily, weekly, or monthly, depending on need.

In practice, direct access to SAP is often not possible. A typical recipe therefore works with files on an SFTP location. The flow looks like this:

1. An SFTP Connector attaches to the file system where data for synchronization is provided.
2. An Extractor reads the source files.
3. A Transformer reshapes the data to match what TimeTac expects.
4. A Loader writes the results into TimeTac.
5. In a second recipe, time data accumulated in TimeTac is read on a schedule and delivered back to SAP using an SFTP Loader.

The result is an end‑to‑end process realized with two encapsulated recipes: one for inbound data to TimeTac and one for outbound data to the ERP.

Implementation experience: reuse beats one‑off code

A key point from the session: with the recipe model, existing components are reused. That reduces implementation effort. As Anna Kastner put it, it is not necessary to invent everything from scratch every time. Knowing the building blocks and combining them intentionally makes the coding part manageable.

The heavier lifting shows up in two phases that are often underestimated in integrations: requirements and testing. Requirements are challenging because multiple stakeholder groups are involved and their interests must be aligned. Testing is challenging because integrations touch real data flows, involve multiple systems, and defects often surface only in end‑to‑end scenarios. A clear architectural frame with reusable components pays off precisely here.

Project boundaries by design: keeping TimeTac Connect separate

TimeTac chose to keep the integration framework separate from the main product. This brings several advantages:

• Agile workflow: integrations evolve at their own pace.
• Independent releases: integration changes do not have to block product releases, and vice versa.
• Reduced complexity: the TimeTac core remains lean while integration logic stays isolated.

This separation improves maintainability and responsiveness to new integration needs.

What makes integrations hard: stakeholders, alignment, and long‑term support

Integrations involve a bunch of stakeholders. On the customer side and inside the company, interests can diverge. That makes gathering information for new integrations a critical and sensitive process. Working closely with customers and internal teams is daily practice, as is combining and aligning their interests.

Long‑term support is part of the job. Systems evolve. Data models change. New needs appear. Integrations are not a single sprint but an ongoing responsibility. As Anna Kastner noted, working in integrations is diversified: it is about continuous improvements, learning about new technologies, and getting to know various systems.

Guardrails for engineering teams, distilled from the session

Based squarely on the talk, here are principles teams can apply without going beyond what was presented:

• Lean on ETL: separate extraction, transformation, and loading as distinct responsibilities. This clarifies structure and enables reuse.
• Treat connectivity as first‑class: model Azure, local Active Directory, SFTP, file systems, and external databases as Connectors.
• Build with recipes: think of integrations as chains composed of Connector, Extractor, Transformer, and Loader. This makes flows predictable and testable.
• Prefer reuse: use existing components rather than crafting single‑use logic per integration.
• Invest in requirements and testing: plan time for precise scoping and for exercising end‑to‑end flows where issues surface.
• Decouple from the main product: keep the integration layer as its own project to decouple releases and control complexity.
• Respect operational reality: define export cadence (daily, weekly, monthly). Use SFTP where direct system access is not possible.

Understanding the primary use cases

The two common integrations — user provisioning and ERP synchronization — illustrate the range of needs:

• Master‑data‑centric: in user provisioning, the HR system provides the source of truth. TimeTac mirrors accounts. The key is correctness and completeness, including deactivation.
• Process‑ and analysis‑oriented: in ERP integrations, projects and tasks live in one system. TimeTac enables time tracking against them and delivers the resulting time data back for further processing such as analysis or payroll accounting. Export cadence must fit the business rhythm.

Both scenarios benefit from reusable recipe components. Once a Transformer and Loader are defined cleanly, they can be applied across customers and setups without re‑encoding every nuance.

Why ETL is a good fit here

ETL does more than structure the code; it reduces failure modes. The Transformer has explicit ownership of data shape. When a target structure changes, it is clear where to apply adaptations. Extractors and Loaders remain stable as long as interfaces and transports do not change. This yields integrations that evolve incrementally without breaking the whole flow.

At the same time, ETL maps well to operational reality. Direct access to systems like SAP is often not possible. SFTP becomes a frequent transfer method. The Connector abstraction embraces this reality without complicating the architecture.

What we, as DevJobs.at, took from the session

• Integrations are organizational work: stakeholder management, requirements, and testing are central.
• An in‑house framework pays off when flexibility is required and components can be reused.
• ETL provides a clear backbone, especially with Transformers carrying the single responsibility for structural change.
• Recipes as puzzle pieces are a practical mental model to design and operate integrations.
• Operations matter: SFTP is often the workable path. Export cadence is part of the specification, not an afterthought.
• Separate projects keep the product lean and integration development nimble.

Practical steps to apply the approach

While every environment is unique, teams can translate the talk into direct steps:

1. Map systems and data flows: identify sources and targets, where master data lives, and which transports are realistic (for instance, SFTP rather than direct access).
2. Identify components: determine which Connectors are needed (Azure, local Active Directory, SFTP, file system, external database) and which Extractors, Transformers, and Loaders can be made generic.
3. Define recipes: create one recipe per direction. Separate inbound flows to TimeTac from outbound exports back to the source system.
4. Set cadence: daily, weekly, or monthly — make the schedule part of the specification.
5. Nail requirements: bring stakeholders together early to surface and align diverging interests.
6. Plan testing: validate data quality, failure modes, and end‑to‑end behavior with realistic handoffs.
7. Set project boundaries: run the integration layer as a decoupled project to keep releases and responsibilities clean.

These steps mirror the approach described in the session and are readily applicable to teams tackling similar integration work.

From ad‑hoc scripts to a platform mindset

The evolution from scattered, separate procedures to a reusable framework is typical in maturing product organizations. With TimeTac Connect, TimeTac shows how to structure integrations so they meet immediate needs and remain sustainable over time. The ETL choice, the disciplined separation of building blocks, the use of SFTP where direct access is not feasible, and the deliberate separation of the integration project from the main product all reinforce each other.

Ultimately, the takeaway is pragmatic. Reusable components make coding easier. The real challenge lies in defining requirements and in testing. Integrations are a team effort with many participants, and the work is diverse. It is about continuous improvement, learning new technologies, and getting to know various systems.

Conclusion

TimeTac Connect, How we handle Integrations by Anna Kastner (TimeTac) offers a clear, practical view on making integrations manageable. The ETL model, the idea of recipes, and the crisp separation of responsibilities are tangible, transferrable principles. Treating integrations as an ongoing capability rather than a one‑off project pays dividends in speed, quality, and reliability. TimeTac Connect illustrates how that capability can live as a flexible, standalone integration layer.

• 

  

  How to pick the next Front End Framework

  Tomi Močnik von TimeTac zeigt in seinem devjobs.at TechTalk wie die Entscheidung für ein neues Front End Framework im Unternehmen gefallen ist und welche Erfahrungen dabei gemacht wurden.

  Watch now
• 

  

  Challenges in mobile application development

  Ludwig Blaikner von TimeTac spricht in seinem devjobs.at TechTalk über den Weg, wie das Team ein Design Proposal zu einer funktionierenden Mobile Software gebaut hat.

  Watch now
• 

  

  Are you using debugger and why not?

  Borislav Lazendic von TimeTac zeigt in seinem devjobs.at TechTalk die Vorteile von Xdebug und überprüft, ob an den üblichen Vorurteilen zu diesem Thema auch etwas dran ist.

  Watch now