Connect Azure DevOps

How to get there: Go to Settings in the sidebar → Integrations tab (under Other) → Azure DevOps section.

Integrating ProductLift with Azure DevOps lets you push feedback into your engineering work tracking, link existing work items, and keep statuses in sync. This guide covers connecting Azure DevOps Services, pushing a post, linking an existing work item, and configuring two-way status sync.

Only Azure DevOps Services (the cloud version at dev.azure.com) is supported. Azure DevOps Server (on-prem) is not.

1. Create a Personal Access Token

ProductLift authenticates with a Personal Access Token (PAT). Scope the PAT to the minimum required.

  1. In Azure DevOps, open https://dev.azure.com/{your-org}/_usersSettings/tokens.
  2. Click + New Token.
  3. Set:
    • Name: ProductLift
    • Organization: pick the specific org you want to integrate (e.g. myorg). Do not pick "All accessible organizations". Those are Global PATs, which Microsoft is deprecating on December 1, 2026, and many tenants already reject them with Could not authenticate. Always scope the PAT to a single organization.
    • Expiration: pick a duration; you'll need to rotate the token before it expires.
    • Scopes: Custom defined → Work Items → Read & write.
  4. Click Create and copy the token. You will only see it once.

2. Connect Azure DevOps in ProductLift

  1. Open the integration: Settings → Integrations → Azure DevOps section. Click to expand.
  2. Enable Azure DevOps integration and fill in:
    • Organization, the {organization} in dev.azure.com/{organization} (e.g. myorg).
    • Project, the project name within the organization (e.g. MyProject).
    • Personal Access Token, paste the PAT you just created.
    • Default work item type, usually Task, User Story, Bug, or Issue.
    • Area path (optional), the area path to assign new work items to, e.g. MyProject\\Backend.
  3. Click Save.
  4. Click Test connection. A green message confirms ProductLift can reach Azure DevOps with your PAT.

The PAT is encrypted at rest. To rotate it, paste the new PAT over the masked **** placeholder and save.

3. Push a post into Azure DevOps

On any post detail view, an admin can push the post to Azure DevOps as a new work item.

  1. Open the post.
  2. Click Push to → Azure DevOps under the integrations widget.
  3. ProductLift creates a new work item in your configured project, using:
    • Post title → System.Title
    • Post content + post URL + requester email → System.Description (HTML)
    • The configured Default work item type and (if set) Area path

After the push, the post shows the linked work item id and live state. The button is disabled for a post that is already linked.

If the work item already exists, you can link it instead of creating a new one.

  1. Open the post.
  2. Click Link existing, pick Azure DevOps, and paste the work item id (e.g. 4567). ProductLift accepts either a bare id or a URL fragment containing one.
  3. Click Link. ProductLift verifies that the work item exists and stores the link.

5. Set up status sync

Status sync is two-way:

  • When a post's status changes in ProductLift, ProductLift updates System.State on the linked work item to the mapped value.
  • When a linked work item's System.State changes in Azure DevOps, ProductLift moves the post to the mapped ProductLift status.

To configure mappings:

  1. In Settings → Integrations → Azure DevOps, scroll to Status mapping.
  2. Click Add rule. Pick a ProductLift status on the left and type the matching Azure DevOps state on the right. State names depend on your process template, for example:
    • Agile: New, Active, Resolved, Closed
    • Scrum: New, Approved, Committed, Done
    • Basic: To Do, Doing, Done
  3. Tick Notify voters when status changes via inbound webhook if you want voters to receive an email when Azure DevOps pushes a state change back into ProductLift.
  4. Click Save mappings.

6. Configure the inbound service hook in Azure DevOps

ProductLift exposes a per-portal webhook URL for Azure DevOps to call when a work item is updated.

  1. In ProductLift, copy the Inbound webhook URL shown in the Azure DevOps integration card. It looks like https://your-portal.example/api/integrations/{id}/webhook?secret={uuid}.
  2. In Azure DevOps, go to Project Settings → Service hooks and click + Create subscription.
  3. Pick the Web Hooks service.
  4. Trigger: Work item updated. Optionally filter by Area path or Work item type.
  5. Action: Web Hooks. Paste the URL into the URL field.
  6. Test and save.

When Azure DevOps fires the service hook, ProductLift looks up the linked posts, applies the mapped status, and (if enabled) notifies voters.

What's not (yet) supported

  • OAuth (only Personal Access Tokens in v1)
  • Comment sync (one-way or two-way)
  • Attachment sync
  • Custom field mapping beyond the defaults above
  • Bulk push ("send all posts to Azure DevOps")
  • Multi-project: one Azure DevOps integration per portal targets one project. Use the area path to scope.

Troubleshooting

  • "Could not authenticate" when testing: by far the most common cause is a PAT scoped to All accessible organizations (a Global PAT). Microsoft is deprecating these on December 1, 2026 and many orgs reject them today. Recreate the PAT and pick this specific organization in the Organization dropdown. Also double-check the organization and project names exactly match the dev.azure.com/{org}/{project} URL, and verify the PAT has Work Items (Read & write) scope and hasn't expired.
  • Push fails with 400: most often a required field on the work item type. Some process templates require fields like Reproduction Steps for Bug or Acceptance Criteria for User Story. Either pick a work item type without required fields, or fill them in directly in Azure DevOps after push.
  • State didn't change after a ProductLift status change: confirm there's a mapping rule for the ProductLift status, and that the target state name exactly matches one in your process template (case-insensitive).