awork import
Purpose
Anyone coming from awork should bring their history along — not retype it. This module takes the data over once and is built so that an interrupted run can simply be repeated. In a migration that is the normal case, not the exception.
Scope
- Areas, individually selectable: match users, clients (awork „companies"), projects, types of
work, tasks including subtasks, checklists, dependencies and comments, time entries and file attachments. On explicit choice only: create missing employees (deactivated).
- Dry run is the default. Writing happens only when explicitly requested.
- Repeatable without duplicates: every imported record remembers its awork id; a second run
updates instead of creating.
- Target brand selectable — mandatory when several brands exist.
- Report at the end listing what was skipped and why.
Operation
Settings → awork migration (permission "import data", platform.import.run; the module must be switched on). New run asks for the target brand, the scopes (empty = all standard scopes) and whether to really write — switched off, it is a dry run. The run is queued and works in the background; the list shows state, kind and totals and refreshes while a run is waiting or running. Clicking a run opens its report: per scope new, updated, skipped, plus problems, skipped records with reason and notes. Only once the report of a dry run is right, follow with the real run. The API key sits under integrations.
Interplay
Imported data lands where it belongs: clients in customer management, projects and tasks in projects and work items, times in time tracking, attachments in the document store. Comments become entries in the shared conversation.
Limits
- Users never become active accounts. awork users are matched to existing employees by e-mail
address; without a match the record is skipped and noted in the report. Only the explicitly chosen area „Create missing employees" creates them — deactivated, without password, invitation or login, so that assignees, authors and times are right. awork guests (often client contacts) and the API client never become employees. Whoever is meant to work in the target system is created there deliberately.
- Order is part of the matter: master data before transactional data. Tasks need their project,
projects their assignment. Each area additionally checks its own preconditions and reports a problem otherwise.
- The import is a setup tool, not an ongoing synchronisation: it fetches a stock of data, it does
not keep two systems aligned.