Azure DevOps integration setup

1. 1Open Integrations in the Lineman dashboard and choose Azure DevOps.
2. 2Give your organisation. A bare name such as acme, dev.azure.com/acme or a full URL are all accepted. If you run Azure DevOps Server on your own hardware, paste your collection URL instead and that wins over the hosted default.
3. 3Sign in with Microsoft and approve access. Lineman uses OAuth deliberately, so there is no personal access token to mint, paste, store or rotate, and revoking Lineman from Azure DevOps is enough to cut off access.
4. 4Tick the projects you want written to. Nothing is written until at least one project is enabled, because this integration edits your work items and that should be a deliberate choice rather than a side effect of connecting.

The connection acts as the Azure DevOps account that authorised it. That account needs permission to edit work items in every project you enable, or the writes are refused.

This is the step that catches people out. The cost goes into a custom field, and Azure only accepts a write to a field that already exists on the work item type. Process templates differ, so Agile, Scrum, CMMI and any inherited process your organisation has customised each start with a different set of fields. A field missing from your template is the most likely reason a cost never appears.

1. 1In Azure DevOps, open your organisation's settings, then Process, and select the process your projects use. A system process cannot be edited, so if yours is stock Agile, Scrum or CMMI, create an inherited process from it and move your projects onto that first.
2. 2On each work item type you track (Task, User Story, Bug and so on), add a Decimal field named Lineman AI Spend. Azure builds the reference name by removing the spaces, which gives Custom.LinemanAISpend, and that reference name is what Lineman writes to.
3. 3Adding the field to the work item form layout is optional. Queries, charts, the analytics views and the API can all read it whether or not it is shown on the form.

• Attribution keys off AB#123 in the branch name or the commit message. That is Azure's own convention for linking work to a board rather than anything Lineman invented, so a team already following it has nothing to change.
• No project prefix. Work item ids are unique across the whole organisation, so AB#4211 is unambiguous wherever that item lives.
• What matches. A branch named feature/AB#4211-retry-backoff and a commit message ending Fix the retry backoff AB#4211 both attribute to work item 4211. A bare 4211 does not, because the AB# sigil is the whole convention.
• Unreferenced work is not lost. Spend on a branch with no AB# reference still appears in Cost Explorer. It simply has no work item to be written back to.

• The figure is US dollars, to two decimal places. Lineman shows money in dollars everywhere and never in cents, so the value in the field is the value you would read on a bill.
• It is a running total, not the cost of the latest change. Each write replaces the previous value with the work item's cumulative cost so far.
• It can go down. Cost records are purged as they age, so a total can fall. Lineman corrects the field downwards rather than leaving a stale higher figure in place.
• An empty field is not an error. Lineman will not write $0.00 onto a work item that has never cost anything, because a zero reads as a measurement when it is really an absence. The field stays empty until there is real spend.

• The field is not on that work item type. By far the most common cause. Check every type you track, not just the one you tested with.
• The project is not enabled. Lineman writes only to the projects ticked on the integration page.
• The work item was never referenced. Check that the branch name or commit message really does contain AB# followed by the id.
• The connected account cannot edit the item. Writes are refused if the Azure DevOps account that authorised the connection has lost edit permission on that project.
• Write-back runs on a schedule. A cost lands on the next run after the spend is recorded, not the instant the work happens, so give it a run before treating it as broken.
• Unchanged totals are skipped. Lineman writes only when a work item's total has moved, so a field that has not changed since yesterday is normal rather than a sign the connection has stopped.