Character limits of default value in DevOps Multiple Lines field
Hi Developers, I intend to use multiple lines field as a text box, in which I can embed hyperlinks with <a> tag and plain text into. However, I found the default value of multi-line field has a character limitation. I am wondering what the specific character limit of default value is and if there is an alternative approach to embed hyperlink which can be clicked by users directly. Thanks a lot
State missing in column setup for board
We have recently had a clean-up of our states in DevOps, but now we're facing a strange problem: Trying to set up our boards to match our new states, we're missing a state when trying to map a column to a state. For instance, our work item type Feature has the state "In progress". This hasn't been hidden and can be used as expected when setting states on individual work items and shows up in backlogs and queries. However, when we try to create a column in our board that should be mapped to "In progress", this isn't an option: The same is true for several other work item types. The state hasn't been mapped to any other columns and I don't see any reason why the state shouldn't be selectable. Any ideas what is going on here?
Integrating Azure DevOps with Jira Service Management: Real-World Use Cases
If your development team works in Azure DevOps while support operates in Jira Service Management (JSM), you're probably dealing with manual ticket updates, information silos, and delayed responses. This friction slows down ticket resolution and creates unnecessary back-and-forth between teams. You can integrate both systems to automate data exchange and keep everyone on the same page. In this post, we'll explore why this integration matters, common use cases I've seen from teams using both platforms, and the key features you should consider when setting up your integration. Why Integrate Azure DevOps with Jira Service Management? When you integrate Azure DevOps with JSM, ticket escalation becomes automatic. A critical bug reported in JSM creates a work item in Azure DevOps with complete context—error logs, customer details, priority level, and all relevant information. Status updates sync bidirectionally. Your support team sees development progress without switching tools. Developers get full customer context without leaving Azure DevOps. The real benefits: Eliminate copy-paste errors Real-time visibility into work status Faster incident resolution Clear audit trails for SLAs and post-mortems Each team stays productive in their preferred environment Without integration, support agents need to check Azure DevOps regularly for updates to relay to customers. This creates delays, introduces errors, and wastes time on both sides. Common Use Cases for Azure DevOps + JSM Integration I have worked with hundreds of teams integrating these platforms. Here are the most common scenarios: 1. Incident and Bug Escalation This is probably the most common use case. Critical bugs reported in JSM automatically create high-priority work items in Azure DevOps with error logs, affected user details, and complete customer context. As developers update the work item, adding comments, changing status, or resolving the bug, those changes flow back to JSM automatically. Support agents can keep customers informed without constantly asking the dev team for updates. Use Case: Current Setup: Support uses JSM for customer tickets. Development uses Azure DevOps for bug tracking. Problem: Manually updating both systems is time-consuming and error-prone. Solution: Two-way sync ensures bugs and updates flow automatically between both systems. 2. Feature Request Management When customers submit feature requests through JSM and they get approved, they automatically flow to Azure DevOps as backlog items with inline images, custom fields, attachments, and more. When development completes the feature, the original JSM request closes automatically and notifies the customer. Use Case: Current Setup: Product managers collect feature requests in JSM. Developers track work in Azure DevOps. Problem: Manually creating work items for approved requests takes time, and context gets lost. Solution: Approved JSM requests automatically create Azure DevOps work items with full context. 3. Multi-Platform Sync for MSPs A central JSM instance can route tickets to different Azure DevOps projects based on work item type. This works especially well for MSPs managing multiple clients. You can connect your JSM instance with multiple client Azure DevOps environments while keeping data completely isolated per client. Use Case: Current Setup: An MSP uses one JSM instance. Multiple clients use separate Azure DevOps environments. Problem: Routing tickets manually to the right client's Azure DevOps is inefficient. Solution: Conditional routing based on customer tags or custom fields automatically sends tickets to the correct Azure DevOps project. 4. Post-Merger System Integration When two companies merge, one might use JSM for service management while the other uses Azure DevOps for development and QA. Rather than forcing everyone onto a single platform immediately, you can connect both systems to let teams continue using their existing tools during the transition. Use Case: Current Setup: Merged company with different tool stacks. Problem: Forcing immediate migration disrupts workflows. Solution: Integration bridges the gap while you plan a longer-term consolidation strategy. Key Features to Consider When Choosing Your Integration Approach Bidirectional vs. Unidirectional Sync Bidirectional sync is essential when both teams need to update shared information like status, priority, and comments. Updates flow both ways automatically without sync conflicts. For some use cases, you might only need one-way sync. For example, JSM → Azure DevOps for escalations where only support creates tickets, but developers provide all updates. Selective Filtering You don't want to sync everything. Look for solutions that let you sync only tickets meeting specific criteria: priority levels, labels, custom fields, or status values. Example filters: Only sync JSM tickets with "escalate-to-dev" label Only sync Azure DevOps bugs tagged "customer-reported" Only sync high and highest priority items This keeps Azure DevOps boards focused on actionable work rather than cluttered with routine requests. Field Mapping Flexibility JSM and Azure DevOps use different field structures. Your integration needs to handle transformations between JSM's field structure and Azure DevOps work item fields without losing data. Common mappings: JSM Status → Azure DevOps State JSM Priority → Azure DevOps Priority Custom fields require explicit mapping rules Scalability The solution should handle your current ticket volume and grow with your organization. Look for reliable performance, error handling, retry mechanisms, and the ability to add more integrations as your needs expand. Security and Compliance Essential security features: Encryption in transit and at rest OAuth or Basic authentication ISO certification Role-based access controls For MSPs: Complete data isolation between client environments Audit logging for compliance requirements Conflict Resolution You need clear rules for what happens when both sides update the same field simultaneously. Common approaches include last-write-wins logic or timestamp-based priority. Technical Implementation Approaches Webhooks + REST APIs Azure DevOps Service Hooks, combined with JSM REST API, provide real-time bidirectional sync. This is the recommended approach for most teams. The flow works like this: Change happens in Azure DevOps Service Hook triggers webhook Integration middleware receives a webhook Middleware calls the JSM REST API to update the ticket The same flow works in reverse for JSM → Azure DevOps updates. Custom Middleware For complex requirements, custom middleware gives you maximum flexibility: Custom field transformation logic Complex routing rules Conditional synchronization Workflow orchestration Error handling and retry logic Common technology stacks include Azure Functions, Logic Apps, or custom Node.js/Python microservices. Third-Party Integration Platforms Many teams opt for dedicated integration platforms rather than building from scratch. These platforms offer pre-built connectors for both JSM and Azure DevOps, significantly reducing implementation time. What third-party platforms typically provide: Pre-configured connectors that understand both JSM and Azure DevOps data structures out of the box Visual or scripting interfaces for setting up field mappings, filters, and sync rules with or without writing code Managed infrastructure so you don't need to host and maintain your own integration servers Built-in error handling and retry logic that handles API failures automatically Audit logging and monitoring dashboards for tracking sync activity and troubleshooting issues Support for complex scenarios like multi-project routing, conditional logic, and custom field transformations Regular updates to keep pace with API changes in both platforms When to consider third-party platforms: You need to get integration running quickly without significant development effort Your team lacks in-house expertise in API integration You want managed infrastructure rather than maintaining your own servers You need support and documentation for troubleshooting You plan to integrate multiple tools beyond just JSM and Azure DevOps You require complex field mappings and conditional routing that would be time-consuming to build Trade-offs to consider: Recurring subscription costs vs. one-time development investment Less control over the exact implementation compared to custom solutions Dependency on the platform's feature set and release cycle Data flows through a third-party service (though reputable platforms offer strong security and compliance) Most platforms available in the Azure DevOps marketplace or Atlassian marketplace offer free trials, allowing you to test their capabilities before committing. Choose the right approach considering the above trade-offs and advantages I have discussed. Good luck! Let's discuss if you have anything specific in mind related to this post.Optimizing Azure DevOps Jira Integration: 5 Practical Use Cases for DevOps Teams
Many teams rely on Azure DevOps (ADO) for development and Jira for project or product management. While each tool is powerful on its own, things often get messy when work items, statuses, and updates live in separate systems. Integrating the two platforms can remove a lot of friction. Below are six common use cases I have seen from real teams, with concrete problems and solutions to make the connection between Jira and Azure DevOps work smoothly. 1. Keeping User Stories and Bugs in Sync Challenge: Teams use Jira for user requests and Azure DevOps for development tasks. Manually updating both systems is tedious and error-prone. Solution: Enable two-way synchronization so that changes in Jira automatically reflect in Azure DevOps and vice versa (including comments and status updates). This keeps bugs and stories aligned without duplicate work. “Before we integrated Jira with Aure DevOps, I spent too much time manually updating task statuses in both systems. Now, with the automatic sync, my team is focused on actual coding work instead of managing project statuses across platforms.” — DevOps Engineer 2. One-Way Sync for Project Management–First Teams Challenge: Some organizations plan and track everything in Jira but manage code exclusively in Azure DevOps. Developers only need the essentials pushed across. Solution: Use a one-way sync from Jira → Azure DevOps to bring over metadata like titles, statuses, sprints, and due dates. Developers see the context they need without cluttering both systems with manual updates. “We rely on Jira for all project planning and management, but the developers need a clean workspace in Azure DevOps. A one-way sync from Jira to ADO helps us keep things efficient and ensures developers always have the latest information without double entry.” — Product Owner 3. Creating Jira Tickets from Azure DevOps Tasks or Bugs Challenge: External partners or stakeholders may only work in Jira Service Management to manage tickets. Developers in Azure DevOps often need their work mirrored for transparency. Solution: Configure automated ticket creation in Jira when certain ADO tasks are tagged. Both teams can track progress in their preferred tool without duplicating effort. “We use Azure DevOps internally, but our external stakeholders only work in Jira. Automating the creation of Jira tickets based on Azure DevOps tasks or bugs has made collaboration seamless and ensured no work is lost in translation.” — DevOps Lead 4. Syncing Epics, Features, and Work Items Challenge: High-level epics might live in Jira, while features and tasks are managed in Azure DevOps. Without integration, visibility across systems is fragmented. Solution: Sync epics and features so Jira provides portfolio-level visibility, while Azure DevOps remains the system of record for detailed development work. This keeps roadmaps and execution aligned. “Tracking epics in Jira while managing the technical work in Azure DevOps used to cause us to lose visibility. Now, everything from high-level epics to individual tasks is in sync, so we always know where we stand.” — Azure DevOps Product Manager 5. Managing Multiple Jira Projects with One Azure DevOps Project Challenge: Large organizations often run multiple Jira projects (by teams or business units) but only one Azure DevOPs project for development. Syncing everything consistently is tough. Solution: Map multiple Jira projects to a single Azure DevOps project, syncing only the key data (titles, statuses, sprints, custom fields). This creates a unified development view without losing project-specific details. “We have multiple teams using different Jira projects, but we consolidate all development work into a single Azure DevOps project. Syncing across these platforms used to be a nightmare, but now everything stays aligned, and we’re able to track all initiatives in one place.” — Azure DevOps Engineer 💬 Have you integrated Jira with Azure DevOps in your team? What worked well, and what challenges did you run into?
Adding CodeReview and Feedback WorkItems
Hi guys, I pretty new to Azure DevOps and working with agile process. I checked the documentation from Microsoft how to set up my project in DevOps and how to add work items etc. But I'm struggeling now how to track everything good in our development process. Basically I want to have I my agile process something like a code review and feedback/test item. And I the documentation from microsoft they talk about this types of work items. But how can I add this to my project? I don't have a selection for that when I add a new work item. Can anybody help and explain how this works? Thx 😊 Flo
Unable to add a parent when creating an item in Devops REST api - on premises
Adding some automation to our internal devops processes, and most things are working just fine, e.g., creating Epics, Features, Stories, Tasks. Creating iterations and adding work items to them also works just fine, as well as things like adding an Iteration to a team. However, trying to parent an new User Story to a Feature (or any other relation) keeps failing. Calling to: http://mytfsserver:8080/tfs/myfirstcollection/myfirstproject/_apis/wit/workitems/$user%20story?api-version=6 JSON [ { "op": "add", "path": "/fields/System.Title", "from": null, "value": "My First Title" }, { "op": "add", "path": "/fields/System.Description", "from": null, "value": "We can add a description to the item here if we wish." }, { "op": "add", "path": "/fields/System.IterationPath", "from": null, "value": "MyFirstProject\My First Iteration" }, { "op": "add", "path": "/relations/-", "value": { "rel": "System.LinkTypes.Hierarchy-Reverse", "url": "http://mytfsserver:8080/tfs/myfirstcollection/myfirstproject/_apis/wit/workitems/526" } } ] This yields the error: { "innerException": null, "message": "Value [ { "op": "add", "path": "/fields/System.Title", "from": null, "value": "My First Title" }, { "op": "add", "path": "/fields/System.Description", "from": null, "value": "We can add a description to the item here if we wish." }, { "op": "add", "path": "/fields/System.IterationPath", "from": null, "value": "myfirstproject\My First Iteration" }, { "op": "add", "path": "/relations/-", "value": { "rel": "System.LinkTypes.Hierarchy-Reverse", "url": "http://mytfsserver:8080/tfs/myfirstcollection/myfirstproject/api/wit/workitems/526" } }] does not match the expected type Microsoft.TeamFoundation.WorkItemTracking.WebApi.Models.WorkItemRelation.", "typeName": "Microsoft.VisualStudio.Services.Common.VssPropertyValidationException, Microsoft.VisualStudio.Services.Common", "typeKey": "VssPropertyValidationException", "errorCode": 0, "eventId": 3000 } If I submit the same thing without the relation, the user story is created correctly. Its Devops 2020, and while the URLs are slightly different to a cloud hosted Azure Devops, as far as I can tell there's no real functionality difference. All the corrections and fixes I can find so far indicate that the wrong linktype hierarchy is used, but as far as I can tell this the same as any samples I've seen. All ideas welcome. I've tried a number of variations, including pretty much copy and pasting examples and just tweaking for the server/project names. When the relation is included I get the error, without I don't. Has any one managed this with on premises? Would an upgrade to 2022 make a difference?
Azure DevOps Yaml Pipeline Build Validation Across Multiple Repos
I have multiple repos that are configured the same way for unit tests. (repo1, repo2, repo3). I then have a separate repo that includes the infrastructure for the tests (repo-tests). It has a docker-compose file, set's all the needed environment variables, image, etc. I can clone down all 4 repos, specify the repo that I want to test and run the docker-compose up and it does all the unit tests. What I'm trying to do is build out a Yaml build pipeline in ADO and save the code for the pipeline in repo-tests. I then want to setup a branch policy for repo1, repo2, and repo3, setting this pipeline as a "Build Validation" so that it will trigger on Pull Requests and run the tests. I have tested this out and I'm not having much luck. It shows up in the PR, but shows as "not run" with a "Queue" button that doesn't seem to do anything. Here is the code: resources: repositories: - repository: repo1 type: git name: Project/repo1 trigger: - main - repository: repo2 type: git name: Project/repo2 trigger: - main - repository: repo3 type: git name: Project/repo3 trigger: - main name: $(date:yyyyMMdd)$(rev:.r) pool: name: Agent-Pool-1 steps: - checkout: self - checkout: repo1 - checkout: repo2 - checkout: repo3 - task: CmdLine@2 displayName: Run Tests inputs: script: echo running tests Is what I'm looking to do even possible? Or do I have to create 3 different pipelines for each repo to accomplish this? Thanks for the help!Device In Azure AD showing as not compliant, yet in Intune the device is fine and compliant
Hello All I have several devices that are now failing SSO logins because of Conditional Access retuning as the device is not Compliant, Checking the device in Azure AD (Entra) is clearly shows the device is not compliant, which explains why the SSO logins are blocked. But when I check the device in Intune (Endpoint) it shows the device is compliant and all good (you will have to take my word the 2 screen shots are the same device as the host name is blurred) When checking the device ID in Azure AD and Intune they all match as you would expect. The Devices are checking in and Syncing with Azure and Intune on a regular basis. Azure is just not updating with the correct Compliance status from Intune. Any Ideas what is happening Cheers Colin
