Automated Time Tracking: How to Design a Reliable Workflow

Automated time tracking is reliable only when the workflow records what its source can actually prove. A completed Asana task proves that a task reached a completed state. It does not prove whether the work took 20 minutes or four hours. A Google Calendar event provides scheduled start and end times, not verified attendance. A time-tracker entry may provide a reported duration, but it can still be edited or left running.

A dependable Make workflow therefore follows a stricter sequence: receive an event, assess its evidence, assign a duration basis, validate the required fields, and then create or update a time record. If duration, identity, project mapping, or billable status is missing, the workflow should create a review item rather than inventing a financially meaningful value.

This guide shows how to design that process with documented Make capabilities for Asana, Toggl, Clockify, and Google Calendar. The app modules, fields, connection requirements, and plan conditions can change, so confirm the current documentation and the connected account before building a live scenario.

Start by defining what the time record means

Before choosing a trigger, separate three different data grains:

• Source event or observation: a task completion, timer update, webhook event, or calendar change. It proves that the source recorded an event, not necessarily that a specific amount of work occurred.
• Time entry: an individual record with a worker, project or client, time period, duration, duration basis, and review state.
• Aggregate: a daily, weekly, or project total derived from time entries. It is a summary and should not be stored as though it were another individual event.

That distinction prevents a common design error: treating a completion timestamp as a duration. A completed task with no duration can become a review item. A Clockify or Toggl entry with a reported duration can be normalized for a downstream ledger. A calendar event can produce a draft based on scheduled duration, clearly labeled as a proxy.

Make documents integrations for Asana, Toggl, Clockify, and Google Calendar. Those integrations do not imply identical fields, permissions, authentication, or destination behavior. Treat the official app documentation as the source for current module names and requirements.

Use this operating rule throughout the design: event received, evidence assessed, duration basis assigned, validated record or review item. Do not create billable or payroll duration from a task-completion timestamp alone.

Choose the capture model that matches the work

Choose the source of truth for duration before building the scenario. A time-tracker entry is usually the relevant input when the requirement is measured elapsed time. A task event is useful as a workflow signal. A calendar interval describes scheduled time. Passive activity collection is a separate employee-monitoring and privacy decision, not a default definition of automated time tracking.

Source	What it establishes	Validation	Suitable output
Time-tracker entry	A source-reported or timer duration	Check user, project, entry status, edits, and duration	Normalized time entry
Task event	A workflow milestone or status change	Require separate duration and project mapping	Review signal or reviewed draft
Calendar event	Scheduled start and end	Check status, time zone, recurrence, and policy	Labeled scheduled-duration draft

A timer can be left running or edited. Task completion usually lacks elapsed time. Calendar duration can overstate attendance or work. Treating these inputs as equivalent creates ambiguous records that are difficult to approve and reconcile.

Define a time-data contract before building

Decide whether one normalized row means one accepted source time entry or one event that may require review. Keep the source-event ledger, normalized time entries, review items, and aggregates as distinct record types or tables.

A practical individual-record contract can include:

• Provenance: source system, source object ID, source event type, source event timestamp, source update or revision, processing timestamp, and processing run ID.
• Business identity: employee ID, project ID, client ID, and billable status.
• Time and control: duration in seconds, duration basis, mapping status, and review status.

The following is an illustrative normalized record, not a vendor-provided schema. Its row grain is one received Clockify time-entry update. It is not a project total or a daily aggregate.

{
  "source_system": "clockify",
  "source_object_type": "time_entry",
  "source_object_id": "entry_493",
  "source_event_type": "updated",
  "source_event_timestamp": "2026-10-17T15:20:00Z",
  "source_updated_at": "2026-10-17T15:20:00Z",
  "employee_id": "user_24",
  "project_id": "project_18",
  "client_id": "client_07",
  "duration_seconds": 3600,
  "duration_basis": "source_reported_duration",
  "billable_status": "needs_review",
  "review_status": "pending",
  "processing_run_id": "run_20261017_004"
}

Useful duration_basis values include timer_duration, calendar_duration, source_reported_duration, estimated_duration, and unknown. Require a stable source identity, a recognized event type, worker identity, a valid nonnegative duration when duration is required, project or client mapping, and an explicit billable decision. Route missing or ambiguous values to review instead of guessing or silently dropping them.

Use deterministic rules for known event types, mappings, duration checks, and billable policies. AI can suggest a project ID from free-text task details and return a confidence value for a human reviewer. It should not determine payroll hours or final billable status from ambiguous evidence.

Three Make workflow patterns with different evidence

Each pattern below has a different source grain. The sequences are implementation designs based on documented app capabilities, not a claim that one universal template is ready to run without account-specific testing.

Trigger	AI job	Validation and action	Fallback owner
Asana Watch Tasks or Subtasks configured for completed tasks	None required. A proposed project mapping may be reviewed.	Confirm completion transition, task ID, worker, mapping, and separately supplied duration. Create a draft or review item.	Project owner or time approver
Clockify webhook or time-entry watch	None required for known event normalization.	Classify create, update, stop, or delete. Validate workspace, entry, user, project, and duration, then upsert or review.	Time-system administrator or finance operations
Google Calendar Watch Events, Search Events, or Get an Event	None required for timestamps. A proposed project mapping needs approval.	Check status and end time, normalize time zones, calculate scheduled duration, and update a labeled draft.	Meeting owner or project approver

Asana: completion to a reviewed time-entry draft

Make documents Asana’s Watch Tasks or Subtasks capability. The module can be configured for task types such as completed tasks where supported, and the documentation states that it requires an Asana subscription plan. Confirm the workspace, resource filters, and returned fields in the connected account.

A defensible chain is:

Asana Watch Tasks or Subtasks, configured for an eligible completion, then map the task ID and worker, resolve the project or client, validate a separately supplied duration, and write either a review item or a destination time entry.

Completion is a milestone, not an effort measurement. If duration is absent, store the task ID, completion event, mapping status, and duration_basis: unknown in a review record. The project owner or designated time approver supplies or approves the duration before the record becomes invoice or payroll ready. A repeated delivery should resolve to the same source-event key rather than create another draft.

For this pattern, the source-event grain is one qualifying task completion transition. Do not deduplicate on task name, project name, or employee and date alone. A proposed key is source system plus task ID plus qualifying event type plus event version or source event timestamp. Prefer a destination-side unique constraint or transactional upsert when concurrent runs are possible.

Clockify: synchronize time-entry changes

Make’s current Clockify documentation lists time-entry operations including Watch Time Entries, Find Time Entries, Get a Time Entry, Run/Add a Time Entry, Update a Time Entry, Stop a Time Entry, and Delete a Time Entry. It also documents webhook capability. Confirm the current operation and event semantics in the connected account. Do not present a generic “Create time entry” label as a verified Clockify module name.

A practical chain is:

Clockify webhook or time-entry watch, then classify the event, validate workspace, entry, user, project, and duration, and upsert the normalized record or route it to review.

Preserve the workspace ID, time-entry ID, event type, source update time, and processing run ID. A creation or stop event may be suitable for a final reported duration, while a start event is not. An update should revise the existing normalized record. A deletion should follow an explicit reconciliation policy rather than disappearing from the ledger without an audit trail.

For this pattern, the row grain is one source time-entry revision. A proposed uniqueness key is source system plus workspace ID plus time-entry ID plus source revision or updated timestamp. If the destination cannot enforce that key or perform an atomic upsert, add reconciliation and document the residual duplicate risk.

Google Calendar: create a scheduled-duration draft

Make documents Google Calendar operations for watching, searching, retrieving, creating, updating, and deleting events. Its documentation does not establish a native trigger specifically named “event ended.” Use an available event operation, then check the end timestamp in the scenario.

A suitable chain is:

Watch, search, or retrieve an event, then check status and end time, apply calendar-to-project rules, calculate the interval after time-zone normalization, and save or update a draft labeled scheduled duration.

Retain the calendar ID, event ID, occurrence identifier or occurrence start, and event update information. Handle recurring instances separately. A rescheduled event should update its existing draft rather than create a second one. Apply explicit rules for canceled, all-day, personal, overlapping, and external-attendee events.

For this pattern, the row grain is one calendar occurrence revision. A proposed key is calendar ID plus event ID plus occurrence start plus event revision. Label the result calendar_duration. It represents scheduled time, not verified attendance or actual work. The meeting owner or project approver should resolve uncertain attendance, client mapping, and billable status.

Build the first scenario around one source and one outcome

A bounded first scenario is an Asana completion event that creates a review-queue item when duration or mapping is missing. If the business requires an actual time entry, require a separately supplied actual-duration field or a human-reviewed value before using the selected time-tracking app’s current time-entry operation. Confirm the destination’s required fields, permissions, connection method, and update behavior in its official documentation.

1. Connect the relevant Asana workspace and configure the documented task-watching module for eligible completed tasks where supported.
2. Run the scenario once and inspect the actual bundle. Identify the stable task ID, worker, project context, completion event, and any duration field genuinely supplied by the source.
3. Apply deterministic filters and mappings. Validate identity, project or client mapping, event type, duration, and billable policy.
4. Write one outcome: a validated draft entry or a review-queue record. Store the source identity and processing provenance with it.
5. Test a valid task, missing project mapping, missing duration, repeated delivery, and a failed destination write before scheduling or activating the scenario.

A correctly configured scenario can act on qualifying events, subject to event delivery, permissions, mapping, validation, and successful destination writes. For teams that need support mapping source events, controls, and downstream systems, see ConsultEvoMake automation consultingSupport for mapping source events, validation rules, and downstream systems.→

Design for retries, edits, and duplicate events

A lookup followed by a create is not a race-safe deduplication strategy. Two concurrent runs can both find no existing record and then insert duplicates. Prefer a destination-side unique constraint and atomic upsert where available. If the destination cannot provide transactional uniqueness, document the residual risk and use a reconciliation process that compares source revisions with destination records.

Make a key that matches each source:

• Asana completion: source system, task ID, qualifying event type, and event version or event timestamp.
• Clockify revision: source system, workspace ID, time-entry ID, and source revision or updated timestamp.
• Calendar occurrence: calendar ID, event ID, occurrence start or occurrence identifier, and event revision.
• Aggregate: employee ID, project ID, local date, and aggregation version. Keep this separate from source-event and time-entry keys.

Define update, deletion, rescheduling, and post-invoice edit behavior before launch. The Make retry error handler and incomplete executions can help recover from configured failures, but they do not guarantee exactly-once delivery. Retry temporary connection, timeout, or rate-limit failures where a repeated write is safe. Route malformed data, missing mappings, and invalid durations to review instead of retrying a permanent validation error.

Scenario rate limits and queues can affect when a high-volume workflow is processed. Ordered processing may help when chronology matters, but it is not a database transaction and does not replace uniqueness controls. Assign ownership clearly: the scenario operator monitors transport failures, the time-system or finance operations owner handles validation exceptions, and the project owner or authorized time approver decides whether a disputed record can affect billing or payroll.

Measure whether the process improved

Compare a pilot with your own baseline. Track completion latency, valid project and client mapping rate, duplicate rate, unresolved exception count, correction rate, and the share of entries with an explicit duration basis. A fall in unresolved entries or faster review is a more useful success criterion than an assumed industry benchmark.

Preserve provenance with every downstream record: source object and event, source update or revision time, processing timestamp, scenario or run identifier, mapping-rule version, and review outcome. Keep capture, review, and downstream approval distinct when an entry could affect an invoice or payroll export.

Questions to resolve before production

• Does the source measure elapsed time, report a duration, or only signal an event?
• What happens when a task, time entry, or calendar event is edited, canceled, rescheduled, or deleted?
• Can the destination update an existing record and enforce uniqueness at the correct grain?
• Who owns exceptions, and who approves records before invoice or payroll use?
• What employee-data collection, access, retention, notice, and monitoring rules apply to the selected capture method?
• What event volume, rate limits, retry policy, and maximum acceptable processing delay apply?

Make’s app documentation confirms integration capabilities, not a tested, field-by-field end-to-end workflow. Module availability, fields, authentication, and account requirements may vary and change over time. The verified documentation covers Asana task watching, Toggl time-entry capabilities, Clockify time-entry and webhook capabilities, and Google Calendar event operations, but the exact mapping must be tested in the selected accounts.

Recordkeeping and employee-monitoring obligations also vary by jurisdiction and context. Verify applicable rules before relying on captured activity for payroll, billing, or compliance. A reliable automated time-tracking workflow is not the one that creates the most records. It is the one that preserves evidence, makes uncertainty visible, prevents duplicate writes, and gives an authorized person a clear approval path.