Aconex sync

If your project is already on Aconex, you don't have to choose between systems. IssuesId can sync defects bidirectionally with Aconex on a per-project basis — captures from the field land in Aconex, status changes pulled from Aconex update IssuesId, and the audit trail stays intact on both sides.

How sync is configured

Aconex sync sits on two configuration layers:

Organisation-level credentials. Each organisation stores one set of Aconex credentials — username, password, and API key — encrypted at rest using AES-256-GCM with per-field initialisation vectors and authentication tags. The encrypted values are kept under tenant-isolated row-level security; only the platform's encryption keys can read them. The Aconex base URL is configurable too, supporting Aconex's regional instances (au1, us1, eu1).

Per-project configuration. Each project that wants Aconex sync enables it separately, and carries:

→The Aconex project ID to sync with.
→A type mapping — which IssuesId defect types correspond to which Aconex issue types.
→Sync rules — which IssuesId statuses trigger a push to Aconex (so e.g. drafts don't sync until they're assigned).
→A poll interval for pulling updates back from Aconex (default 15 minutes).

You can have one project syncing to Aconex and another not — or two projects in the same org syncing to different Aconex projects.

Location mapping

Aconex tracks issues against areas; IssuesId tracks them against locations (which are usually finer-grained). Per-project location mappings tie each IssuesId location to the corresponding Aconex area ID and name. If a defect is captured in a location that hasn't been mapped, the sync queues the defect with pending_location_mapping status — you map the location, the queue retries, and the defect lands in the right Aconex area.

What syncs bidirectionally

→Defect creation and update — push to Aconex with type mapping, area mapping, photos, and status.
→Status changes — push when the IssuesId-side status changes, pull when the Aconex-side status changes. The two state machines are reconciled by mapping rules.
→Dispute state — explicitly bidirectional; IssuesId's in_dispute ↔ Aconex's InDispute round-trips cleanly.

What's logged

Every sync event is recorded in a per-inspection sync log:

→Direction — push or pull.
→Status — success, failed, pending, or pending location mapping.
→Aconex issue ID — the corresponding issue on the Aconex side, once known.
→Error message — if the sync failed, the reason.
→Attempt count — how many times the sync has been tried.
→Timestamp.

The log is the source of truth for "did this sync happen?" questions and is what the admin dashboard surfaces when a project's sync isn't behaving as expected.

Async and resilient

Sync runs through a queue, not inline with user actions. That means:

→A slow Aconex API doesn't slow down your field team — they create the defect, get on with their work, and the sync happens in the background.
→Failed syncs are retried automatically.
→A temporary Aconex outage doesn't lose data — the queue holds and drains when service returns.