Azure DevOps integration | FeatureOS

Connect FeatureOS to Azure DevOps to turn customer feedback into work items your engineering team can plan and ship. Posts can become work items automatically, statuses stay in sync in both directions, and FeatureOS data such as votes and submitter details can flow into your work item fields.

What you can do

Push posts to Azure DevOps automatically. Create a work item when a post matches rules you set.
Sync statuses both ways. Update the work item's state when a post's status changes, and update the post when the work item's state changes.
Create or link work items from a post. Send a single post to Azure DevOps, or link it to a work item that already exists.
Sync post details into work item fields. Map FeatureOS attributes like upvotes, submitter email or ETA onto Azure DevOps fields.

Before you begin

You need admin access to your FeatureOS organization.
Your FeatureOS plan must include the Azure DevOps integration.
You need an Azure DevOps Services organization (dev.azure.com). Azure DevOps Server (on-premises) isn't supported.
You must sign in with a work or school Microsoft account that is a member of that Azure DevOps organization. Personal Microsoft accounts can't connect.

We recommend creating a dedicated Azure DevOps user for this connection. Work items, comments and tags that FeatureOS creates appear as that user, so permissions are easier to audit and revoke.

Connect Azure DevOps

In FeatureOS, go to Dashboard → Organization Settings → Integrations.
Find Azure DevOps and click Connect.
Enter your Azure DevOps organization name. This is the part after dev.azure.com/ in your Azure DevOps URL. For example, for https://dev.azure.com/fabrikam, enter fabrikam.
Sign in with your Microsoft work or school account and approve the permissions FeatureOS asks for.

FeatureOS asks for permission to read your projects, create and update work items, and manage service hooks. It uses service hooks to hear about state changes on the work items you link. You can connect one Azure DevOps organization to each FeatureOS organization.

Push posts to Azure DevOps automatically

A push rule tells FeatureOS which posts to send to Azure DevOps and where to put them. You can create more than one rule. For example, bugs can go to a Bug work item in your engineering project and feature requests to a User Story in your product project.

For each push rule, set:

Project: the Azure DevOps project where new work items are created.
Work item type: the type of work item to create, such as User Story, Bug or Task.
FeatureOS boards: only posts on these FeatureOS boards are pushed.
Status: only posts in this status are pushed.
Push on creation: push a post as soon as it's created, if it matches the rule.
Push on approval: push a post when it's approved, if it matches the rule.
Tags (optional): only push posts that have at least one of these tags.
Performed by (optional): only push when one of these team members makes the change.

When FeatureOS pushes a post, it:

Creates a work item with the post's title and description in the project you chose.
Tags the work item with linked-from-featureos.
Adds a comment to the work item with a link back to the FeatureOS post.
Links the work item to the post so status sync can start.

A post is pushed to Azure DevOps only once. If more than one rule matches a post, FeatureOS uses the first rule in your list. Posts that were updated from Azure DevOps aren't pushed back, which prevents sync loops. Automatic pushes send only the title and description, so choose a work item type that doesn't need other required fields, or one where those fields have default values.

Sync statuses

Status sync rules keep FeatureOS posts and Azure DevOps work items in step. Each rule works in one direction.

Work item types

In Azure DevOps, each work item type has its own states. For example, a User Story might move through New → Active → Resolved → Closed, while a Bug uses a different set. Every sync rule has a Work item type:

Pick a specific type, such as Bug, for a rule that only applies to that type.
Pick Any for a rule that applies to every type.

If both a type-specific rule and an Any rule match, the type-specific rule is used.

FeatureOS → Azure DevOps

When a post moves to a status in FeatureOS, FeatureOS updates the state of every Azure DevOps work item linked to it.

When the post status is: the FeatureOS status that triggers the rule.
Set the work item state to: the Azure DevOps state to apply.
Work item type: the type this rule applies to, or Any.

FeatureOS only changes a work item's state if that state exists for the work item's type. If a linked item's type doesn't have that state, the item is skipped.

Azure DevOps → FeatureOS

When a work item's state changes in Azure DevOps, FeatureOS updates the linked post.

When the work item state is: the Azure DevOps state that triggers the rule.
Set the post status to: the FeatureOS status to apply.
Work item type: the type this rule applies to, or Any.
When: choose Any to update the post as soon as one linked work item reaches this state, or All to update it only when every linked work item has reached this state.
Notify customers: choose whether voters and subscribers get the usual status-change notification.

You can have only one rule for each trigger state and work item type in each direction. If your organization uses custom statuses, turn on Sync by custom status so your rules match those custom statuses instead of the default ones.

Sync custom fields

Custom field rules copy FeatureOS post details into Azure DevOps work item fields. You set them up per Azure DevOps project: choose a project, then map each FeatureOS attribute to a field on that project's work items.

You can map these FeatureOS attributes:

Submitter email
Submitter name
Board name
Upvotes, downvotes and comments count
Created date
ETA
Value and effort

You can map them onto your own custom fields (Custom.*) and the built-in Start Date and Target Date fields. Only fields of a matching type are offered for each attribute. For example, upvotes can go into a number field, and ETA into a date field.

FeatureOS fills these fields when a work item is created or linked, then keeps them up to date as the post changes.

Create or link work items from a post

You can also connect a post to Azure DevOps yourself, from the post's page in FeatureOS:

Create a new work item: choose a project and a work item type, then set the title and description. If the type has required fields, FeatureOS asks you to fill them in.
Link an existing work item: search your Azure DevOps work items and link the one that tracks this work. FeatureOS adds the linked-from-featureos tag and a comment linking back to the post.
See linked work items: each linked work item shows its title and current state. Click it to open it in Azure DevOps.
Unlink a work item: remove the link. The work item isn't deleted, and the linked-from-featureos tag stays on it.

Show linked work items to customers

By default, linked Azure DevOps work items are visible only to your team. To show them on your public posts, turn on Show links to users in the Azure DevOps integration settings.

Disconnect Azure DevOps

Open the Azure DevOps integration in your FeatureOS Integrations settings and click Disconnect. FeatureOS stops creating work items and syncing statuses and fields. Your existing work items aren't deleted.

Troubleshooting

FeatureOS says it can't reach my Azure DevOps organization.
Check that the organization name matches your dev.azure.com URL exactly, and that the account you signed in with is a member of that organization. If your company uses Conditional Access policies in Microsoft Entra ID, ask your IT admin to allow access to Azure DevOps for FeatureOS.

I can't sign in with my Microsoft account.
The integration needs a work or school account. Personal Microsoft accounts (such as outlook.com or hotmail.com) can't connect Azure DevOps.

The integration asks me to reconnect.
Your Azure DevOps sign-in has expired or was revoked. Click Reconnect in the Azure DevOps integration settings and sign in again. Your rules and linked work items are kept.

A post wasn't pushed to Azure DevOps.
Check that a push rule is turned on and that the post matches all of its conditions: the FeatureOS board, the status, the tags and the team member who made the change. Also check that Push on creation or Push on approval is on for the event that happened. A post that was already pushed won't be pushed again. If the work item type has required fields without default values, automatic pushes can't create it. Pick a different type, or add default values in Azure DevOps.

An Azure DevOps state change didn't update the post.
Make sure there's an Azure DevOps → FeatureOS rule for that state and for the work item's type (or Any). If the rule uses All, every linked work item has to reach that state first.

The work item's state didn't change after I updated the post.
Check that the FeatureOS → Azure DevOps rule points to a state that exists for the work item's type. States differ between work item types and process templates, so add a type-specific rule if needed.

A custom field isn't updating.
Check that there's a custom field rule for the work item's project, and that the field you mapped is a custom field or Start Date / Target Date of a matching type. The field must also be on the work item's type in Azure DevOps.

Need more help?

Reach out to our support at [email protected] or submit a request on our support board! 😃

Was this helpful?