Skip to content

Custom Rule Issues in Azure DevOps Services: Enforcing Process Rules Without Inbuilt Support

Exploring ways to tailor Scrum processes within Azure DevOps, we face challenges reminiscent of our TFS experience—specifically when preventing state transitions on Product Backlog Items without inbuilt rules. Here’s a breakdown:

Process Customization and Limitations

While Azure DevOps offers process customizations (adding/modifying work item types, fields), complex conditional logic based on roles or field values is not directly supported within state transitions of the out-of-the-box Scrum template. To understand this further:

FeatureAvailability in Azure DevOpsNotes
Role-Based State Transition RulesNot natively supportedDirect process rules limited; requires extensions or custom code.

To enforce our unique Scrum rule—preventing certain state transitions if a specific field (e.g., “Developed_By”) doesn’t meet criteria —we can implement service hooks or webhooks, which trigger external services upon work item updates:

  1. Service Hook Integration - Use Azure DevOps Services’ native integration with third-party tools to create a feedback loop when backlog items change states; for example integrating this flow into an application that validates transitions based on internal logic and your specifications about the “Developed_By” role.

  2. External Application/Script Development - Create or leverage existing scripts using Azure DevOps REST API to monitor changes actively: these can be scheduled tasks, services (like an ASP.NET Core application), cloud functions on platforms like AWS Lambda with serverless architecture support for HTTP triggers that validate state transitions against your criteria programmatically and intervene as necessary based upon the “Developed_By” field’s value in a work item’s context.

Practical Approach: Custom Application or Scripting Solution

Here is an example approach using Azure Functions, which are lightweight hosted environments ideal for running short-lived code triggered by events such as backlog state changes detected through the REST API:

  1. Create a Triggered Event Loop - Build triggers in your function app that listen to work item updates from within Azure DevOps Service hooks or webhooks, ensuring real time responsiveness and minimal latency for process rule validation.

  2. Define Validation Logic Inside Function App – Write logic inside the triggered functions which checks: if a developer marked as “Developed_By” has attempted to transition an item from ‘Quality Control’ state backward, reverting changes or triggering alerts could be implemented through API calls within Azure DevOps Service.

  3. Feedback Loop for Development Teams – Develop comprehensive feedback loops which might involve notifications sent out via email when a violation of process rules occurs due to unauthorized state transitions, fostering self-regulation among teams adhering closely with the scrum framework while maintaining necessary flexibility and integrity.

In practice: A combination approach using service hooks along with custom scripts or application logic (ideally in Azure Function App for scalability) would effectively replicate your specific rule, ensuring that state transitions are enforced as per requirements even without direct support from the native Scrum template of Azure DevOps.


Previous Post
Prometheus Configuration Unifying Job Settings in
Next Post
Does glab glab cli Support Creating Project Acce