Your Azure boards, on a real timeline.

At a glance

Provider

Azure DevOps Services — REST API 7.1

Accepted hosts

HTTPS on dev.azure.com or *.visualstudio.com

Authentication

Personal Access Token, encrypted at rest and never returned by the API

Pull direction

A reviewed Azure DevOps → GanttFather comparison. Conflicting local dates/statuses are kept by default

Push direction

A reviewed GanttFather → Azure publish. Eligible date/status conflicts are selected with a clear overwrite notice

Per project

One Azure connection, any number of sync sources

A source is

One saved query, or one team + backlog board

Schedule

None. Setup starts the initial import; after that, there are no webhooks or background scheduler

Who can manage it

Project Owner or Admin. Other members see the section read-only

Token permissions

GanttFather authenticates with a Personal Access Token you create in Azure DevOps. Give it the narrowest scopes that cover what you intend to do — you can widen them later by saving a new token.

A read-only connection stays read-only. GanttFather never quietly upgrades a pull token into a write token. If the push review says the connection is read-only, save a token that carries Work Items (Read & write) before publishing.

Where the token lives. It is encrypted on the server the moment you save it, decrypted in memory only to call Azure, and never sent back to the browser or included in any API response. Only the project Owner or an Admin can reach any of this; other members see the section but cannot change it.

Connect in seven steps

In the app open Settings → Integrations → Connect Azure DevOps. The wizard separates connection, project, source, types, dates & effort, statuses, and destination so every choice is reviewed before the initial pull.

1. 1

   Organization URL and PAT

   Paste your organization URL (for example https://dev.azure.com/myorg) and a Personal Access Token, then run Test Connection. The wizard will not advance until the test passes.

   The token is held in the browser only until you save; the server stores it encrypted.

   Open GanttFather →

   

2. 2

   Pick the Azure project

   GanttFather lists the projects your token can reach. Pick the one you want this GanttFather project to follow.

   

3. 3

   Choose the source and its scope

   Choose a Saved Query — browse the query tree or paste a query URL and test it — or a Team plus a Backlog Level (Stories, Features or Epics). A board can bring in only that level or its full tree.

   

   

4. 4

   Choose work-item types

   Review the planning types returned by the source and include only the types you want on the timeline. Non-planning types remain available behind Show anyway, and existing explicit selections are preserved.

5. 5

   Map dates and effort

   Per included work-item type, choose which Azure fields become Gantt Start and Gantt End. Custom fields are supported. An optional section maps Original Estimate, Remaining Work and Completed Work to derive % complete.

   

6. 6

   Map Azure states to project statuses

   For every discovered Azure state, choose the exact GanttFather project status used on Pull and review the Azure state that Push uses for that status. Types with no returned states stay visible with retry guidance.

7. 7

   Choose the destination and save

   Choose the task the imported work lands under — or leave it at Gantt Root Level. Review the source, type, date and status summary, then save. Saving creates the integration and starts the initial pull.

Adding more later. Use Add Source to attach another query or board to the same connection. It reuses the stored token and Azure project, then runs the same five source steps: Source, Types, Dates & effort, Statuses, and Destination. Configure fields uses that five-step model but intentionally opens at Dates & effort (step 3 of 5); Back reaches Types and Source when those choices need review.

What lands on the Gantt

Each work item becomes one task. Start, end, optional effort progress and status come from the mappings reviewed in steps 5 and 6; everything else follows the fixed rules below.

System.TitleTask name

Falls back to Work Item {id} when the title is empty.

System.DescriptionDescription

HTML tags are stripped, so the text lands as plain text.

System.StateStatus

Through the state map below.

Microsoft.VSTS.Common.PriorityPriority

1 → High, 2 → Medium, 3 and 4 → Low. Missing or unrecognised → Medium.

Your mapped start fieldStart date

Defaults to Scheduling.StartDate. With nothing usable: the work item’s created date, then today.

Your mapped end fieldEnd date

Defaults to Scheduling.TargetDate. With nothing usable: start + 1 day.

Your mapped estimation fieldEstimation

Defaults to Scheduling.StoryPoints. Also eligible: Original Estimate, Effort, Size, and custom numeric fields.

System.AssignedToAssignment

Resolved in three tiers — see below.

System.ParentParent task

Applied after all items are processed, when both items came from the same source.

The work item itselfAzure DevOps icon + deep link

Imported tasks link straight back to _workitems/edit/{id}.

States become statuses

The default map is case-insensitive, and you can override any state per source.

Custom statuses are respected. If your project defines its own statuses, an imported item lands on your status in the matching category — an Azure Active item becomes your "In Development", not a generic built-in. Anything that resolves into the Done category is set to 100% complete.

Optional: derive % complete from Azure effort

The Dates & effort step can also map Original Estimate, Remaining Work and Completed Work per work-item type. Map at least two and GanttFather calculates each task's progress on every pull, in this order:

1. Completed ÷ (Completed + Remaining)
2. (Original − Remaining) ÷ Original
3. Completed ÷ Original

Nothing is pre-selected — this is opt-in, and a source with no mapping keeps the progress behaviour it has today. When fewer than two usable values exist, or the divisor is zero, the task's existing progress is left alone rather than reset. A status in the Done category still wins: an item Azure reports as Closed reads 100% even if its effort fields disagree. These fields are read on pull only and are never written back.

Scope and destination

Board scope is chosen with the source in step 3. The destination parent is reviewed separately in step 7, immediately before Save and pull.

Target parent task. Choose an existing task and the imported work is nested under it, which keeps two sources from colliding at the top of the chart. Leave it at (Gantt Root Level) to import at the top level. If the chosen task is later deleted, the next pull falls back to root instead of failing.

Board sources skip finished work. The generated query excludes items in Removed, Closed and Done, so connecting a long-lived board does not drag years of history onto your timeline. A saved query, by contrast, returns exactly what you wrote it to return.

Reviewed Pull and full source reconciliation

Pull from Azure compares mapped fields on existing items before changing the timeline. Azure-only values are selected; conflicting local dates/statuses stay local under the default Keep my changes choice. Opening Pull normally keeps the summary compact with Advanced collapsed; Keep my changes and Restore from Azure appear under Advanced. Review Pull from a Push conflict notice opens Advanced immediately. Sync source remains the separately named full membership reconciliation used for new, changed, and removed source items.

Zero is still inspectable. Pull opens even when the count is zero. If an expected change is missing, Check mapped fields opens Settings → Integrations and temporarily highlights that source's Configure fields action.

• Unchanged work items are skipped

  GanttFather stores the Azure revision it last saw. If the revision has not moved, the task is not touched at all.

• Changed work items are overwritten

  Sync source is the full reconciliation operation: a newer Azure revision overwrites mapped task fields. Reviewed Pull is more selective and keeps conflicting local dates/statuses by default unless you choose Restore from Azure.

• Nothing is ever duplicated

  Each work item is bound to its task permanently. A second source that meets the same work item re-binds to the existing task instead of creating a copy, and reconnecting after a disconnect re-binds too.

• Items that leave the source are closed, not deleted

  When a work item stops coming back from the query or board, its task is set to Closed — unless another source in the same connection still tracks it. Imported tasks are never deleted by a sync.

• Parent rows are recalculated

  After every successful pull, parent tasks recompute their dates, progress and status from their children, exactly like any other write in GanttFather.

How assignees are resolved

1. 1

   A project member with that email

   Matched case-insensitively against the members of the GanttFather project. The task is assigned to that person.

2. 2

   An existing resource with that name

   When no member matches, GanttFather looks for a virtual resource with the same display name. A trailing "(Company)" style suffix is ignored during the match.

3. 3

   A new virtual resource

   When neither matches, a virtual resource is created — hourly cost model at 0, initials and colour derived from the name — and reused for every later item with the same assignee.

Assignee names and email addresses are treated as personal data: they are used to match, never written to logs.

Reviewed Push to Azure

Push is a read-only comparison followed by a publish you confirm. Eligible local date and status changes are selected by default. If a selected item also changed in Azure, a blue information badge explains that Send keeps the selected GanttFather values and overwrites those newer mapped Azure values.

Pull first is optional. The badge's Review Pull action changes direction in the same dialog and opens Advanced so Keep my changes and Restore from Azure are visible. Opening Pull normally keeps Advanced collapsed. Confirmed Push respects the user's decision to overwrite Azure; the conflict can still be excluded in Advanced or Details.

These dates cannot be sent together. If a selected start or finish would form an invalid range with the current companion date in Azure, Send is disabled before publishing and no Azure write is sent. Review Pull opens Pull with Advanced expanded so you can restore a coherent date range, or you can close the dialog and adjust the local dates.

What can be published

Gantt Startyour mapped start field

The task's start date.

Gantt Endyour mapped end field

The task's end date, converted to the inclusive date Azure expects.

StatusSystem.State

Resolved through the same state map as pull. If the current Azure state already maps to the task's status, it is kept as-is rather than rewritten.

Estimates stay Azure-owned. Original Estimate, Remaining Work, Completed Work and the configured estimation value can be read on Pull but are never selected or patched by Push.

Derived parent values are protected. A parent whose planning values are computed from children remains visible as unavailable rather than silently publishing a derived date.

How the review sorts your changes

Publishing patches only the selected fields and reports exact completed items, dates and statuses. A partial, failed, stale or uncertain result stays explainable and reopenable; completed work is not resent.

Fresh comparison required. If the comparison changes before confirmation, the same dialog refreshes with “The comparison changed. Review the new counts before continuing.” Old selections are discarded and the current defaults are rebuilt.

One clean exit. Keep my changes · Close starts no operation and closes the complete sync flow instead of returning to a source chooser. Successful Pull and Push actions close their owning dialog after the result is confirmed.

Where to run a sync

Fresh counts on every return. From Settings, the project shortcut, or Data & sync, opening Pull or Push after the previous comparison finishes requests a new server-authored comparison so the review includes the latest Azure changes. Only another opening for the same source while that check is still in progress shares the in-flight request.

Full Sync source maintenance runs in the background. Choosing Sync source in Settings accepts that maintenance trigger right away; the app polls the source until it flips out of In progress, then reloads the project and tells you how many work items changed. Reviewed Pull and Push still wait for explicit confirmation in their dialog. Sources run one at a time, and one failing source does not stop the others.

Limits and good to know

No automatic syncby design

No scheduler, no webhooks, no background polling of Azure. Every pull is triggered by a person.

One connection per projectmany sources

To point a project at a different organization or Azure project, remove the integration and connect again. Sources, mappings and destinations stay editable.

Syncs are silentno history, no live push

A sync writes no activity-history entries and does not broadcast to other open clients. Teammates see the result on their next refresh.

Pull is reviewedconflicts stay local by default

Use Restore from Azure to replace conflicting local dates/statuses. The separate Sync source operation performs the full mapped-field reconciliation.

Deletes never propagateeither way

A work item that leaves the source closes its task. Deleting a task in GanttFather does not delete anything in Azure.

No agent accessMCP

AI assistants connected over MCP cannot configure, trigger or read integrations.

Troubleshooting

When a pull fails, the source shows one of these codes. GanttFather deliberately never surfaces the raw provider response — it can contain organization details and token material.

Connection test fails but the PAT looks right. Check the organization URL first: it must be the organization root on dev.azure.com or *.visualstudio.com, not a project or board URL. A token from a different organization authenticates as nobody and reads as a failed test.

Azure changed but Pull says 0. Open Pull anyway and choose Check mapped fields. Verify the source includes that work-item type and that its Start, End and status fields match the Azure fields your team edits.