When developers evaluate a UI component library or document-processing platform, they usually ask familiar questions.

Does it support the frameworks we use? Is it fast? Can we customize it? Are the APIs intuitive? Is the documentation good? What about accessibility, support, and licensing? Will it scale with the application?

There is another question worth asking:

Does the company building the technology trust it enough to use it in its own products?

At Syncfusion^®, we do.

Technologies from Syncfusion’s own developer ecosystem, including UI components, data visualization controls, document-processing libraries, viewers, editors, and related SDKs, are used as building blocks across BoldSign, BoldDesk, Bold BI, and Bold Reports.

Those four SaaS products solve very different problems:

• BoldSign supports eSignature and document processing.
• BoldDesk provides customer-support and help-desk experiences.
• Bold BI delivers analytics and dashboards.
• Bold Reports supports report design, processing, viewing, and delivery.

That difference is what makes their use of shared technologies interesting.

A PDF-processing library inside an eSignature platform solves a very different problem from a DataGrid inside a support workspace. A TreeView inside an analytics designer serves a different purpose from the same type of navigation control inside a reporting application.

The reusable technology is only one layer.

Each product combines those building blocks with its own business logic, APIs, services, security, data models, processes, infrastructure, and product experience.

A component is a building block, not the product. Its value is in solving recurring engineering problems so product teams can focus more of their effort on the functionality that differentiates their application.

Let’s look at how that works across four very different Syncfusion products.

One technology ecosystem, four SaaS experiences

At a high level, the relationship looks like this:

The important part is not how many components appear in each product. It is how reusable technologies are combined with product-specific engineering to solve real business problems.

BoldSign: From document processing to eSignature management

Electronic signatures revolve around documents.

Users upload contracts, agreements, consent forms, offer letters, and other business files. Those documents may need to be prepared for signing, converted into an appropriate format, populated with fields, processed, signed, and ultimately delivered as completed records.

That creates two distinct layers of engineering.

• The first is document mechanics.
• The second is the eSignature processing built around those mechanics.

The reusable document layer

BoldSign uses Syncfusion document-processing technologies for operations that can include:

• Drawing text into documents.
• Extracting text.
• Accessing PDF form fields.
• Flattening interactive form fields.
• Processing supported document formats.
• Converting supported Word, Excel, and PowerPoint documents to PDF.

A simplified document flow can be represented as:

Input document → Conversion → PDF processing → Form-field handling → Signing → Completed document

The underlying document technologies handle the mechanics of working with files. BoldSign then adds the product-specific experience around them.

What BoldSign adds

An eSignature platform needs much more than PDF manipulation.

The product layer handles capabilities such as:

• Signer management.
• Signing order.
• Authentication.
• Templates.
• Notifications and reminders.
• Status tracking.
• Audit history.
• APIs and integrations.
• Business rules.
• Team operations.

This separation is useful from an architecture perspective.

The reusable document layer solves document-processing problems. BoldSign concentrates its product engineering on how people prepare, send, sign, track, and manage agreements.

Developer takeaway: Reuse document mechanics where they are not your differentiator. Invest your product engineering in the process that creates value for your users.

BoldDesk: Composing UI components into a support workspace

A customer-support platform presents a completely different challenge.

A support agent may need to work with a ticket queue, customer information, conversations, attachments, status changes, internal collaboration, dashboards, and configuration, all within the same application.

No single UI component creates that experience. Instead, the product is assembled from many smaller interaction patterns.

Ticket management

Support teams regularly work with large sets of structured records.

Components such as DataGrid, Query Builder, and editing controls can provide a foundation for viewing, filtering, searching, and updating ticket and customer information.

Conceptually:

DataGrid + Query Builder + editing → Ticket management

BoldDesk then adds the support-domain logic:

• Ticket status.
• Priority.
• Assignment.
• Customer context.
• SLA behavior.
• Permissions.
• Automation.
• Support operations.

The grid knows how to display and manipulate records. BoldDesk knows what those records mean.

Customer conversations

Support agents also need to communicate effectively with customers and coworkers.

Components such as:

• Rich Text Editor
• Mention
• File Upload

Can form part of the communication experience.

Together, they support rich replies, collaboration, mentions, and attachments.

Conceptually:

Rich Text Editor + Mention + File Upload → Customer communication

BoldDesk adds the surrounding product context: ticket history, collaboration rules, channels, customer information, and process state.

Support analytics and navigation

Charts and layout components help present operational information, while input, navigation, dialog, toolbar, and selection controls support the many smaller interactions found throughout a help-desk application.

Rather than building every interaction independently, product teams can compose reusable components into a consistent experience.

Developer takeaway: Large SaaS interfaces are often built from many focused components rather than one enormous domain-specific control.

The individual component solves a bounded UI problem. The product gives that interaction business meaning.

Bold BI: Building a complex analytics workspace

Analytics software introduces a different level of interaction density. A dashboard is not merely a page containing charts.

Users may need to:

• Connect to data.
• Explore schemas.
• Choose fields.
• Add visualizations.
• Drag and resize widgets.
• Configure properties.
• Apply filters.
• Organize dashboards.
• Manage users.
• Share or embed analytics.

A dashboard designer can therefore behave more like an interactive workspace than a static webpage.

Designer interactions

Controls such as:

• Toolbar
• Menu
• Tab
• Splitter
• Drag-and-drop interactions.
• Resizing capabilities.

Can provide the interaction primitives needed to construct the designer environment.

Conceptually:

Toolbar + Menu + Tab + Splitter + drag-and-drop → Designer workspace

Bold BI then provides the analytics-specific layer:

• Dashboard models.
• Data relationships.
• Widget behavior.
• Filtering.
• Visualization semantics.
• Sharing.
• Embedding.
• Governance.

Data and schema management

Analytics applications also need to help users navigate data structures.

Components such as TreeView, DropDown Tree, AutoComplete, DataGrid, and ListBox can support data selection and exploration.

Conceptually:

Tree and grid controls + selection components → Data and schema management

The controls provide navigation and selection behavior. Bold BI determines what the data represents and how it contributes to an analysis.

Configuration-heavy interfaces

An analytics designer can expose a large number of settings.

Users may need to configure:

• Dimensions.
• Measures.
• Dates.
• Colors.
• Ranges.
• Labels.
• Number formats.
• Filtering.
• Sorting.
• Interaction behavior.

Reusable input components such as drop-down lists, check boxes, numeric inputs, date pickers, sliders, and color pickers can provide a consistent way to expose those settings.

Developer takeaway: Reusable UI primitives become increasingly valuable as the number of coordinated interactions in an application grows.

A single control may be small. A consistent collection of them can form the interaction foundation of a sophisticated product.

Bold Reports: From report design to final output

Bold BI and Bold Reports both work with data, but their primary product experiences are different.

• Bold BI emphasizes interactive analytics and dashboards.
• Bold Reports focuses on reporting workflows such as designing reports, configuring report elements, processing data, viewing output, and exporting or distributing finished reports.

A simplified reporting lifecycle looks like this:

Data source → Report definition → Design → Processing → Rendering → Export

Reusable technologies participate at several points in that experience.

Report configuration

Controls such as:

• DropDown List
• Numeric TextBox
• CheckBox
• Color Picker
• File Upload

Can support report-property configuration and image management.

Conceptually:

Input components + File Upload → Report configuration

Bold Reports then interprets those values as report-specific properties, parameters, formatting rules, and definitions.

Report structure and visualization

A TreeView can provide hierarchical navigation for report structures and elements.

Charts and gauges provide visualization building blocks.

Conceptually:

TreeView → Report hierarchy

and:

Charts + Gauges → Report visualization

Again, the reusable controls solve the interface and visualization problems.

Bold Reports provides the reporting semantics, processing model, data relationships, rendering behavior, and delivery operations around them.

Developer takeaway: Keep reusable UI primitives separate from domain-specific application semantics.

A TreeView should not need to understand a report definition. A chart should not need to understand how an enterprise reporting process is governed.

Clear boundaries make both the reusable technology and the product easier to evolve.

What four different products reveal about reusable technology

Looking across BoldSign, BoldDesk, Bold BI, and Bold Reports reveals a consistent pattern.

The underlying principle is straightforward:

Reusable components solve recurring engineering problems. Products create value by combining them with domain-specific behavior.

• A DataGrid does not need to know what a support ticket is.
• A PDF library does not need to know why a customer is signing a contract.
• A TreeView does not need to understand an analytics schema or report definition.

That separation is useful because it allows both layers to improve independently.

What we learn by using our own tools

Using shared developer technologies inside our own SaaS products creates another valuable dynamic. It puts those technologies into complete application environments.

That is different from testing a component only in isolation.

Components have to work together

Real product screens often contain several controls at once.

A workspace might include:

• A grid.
• A dialog.
• A toolbar.
• Input controls.
• Navigation.
• An editor.
• File upload.
• Charts.

This exposes integration questions that an isolated sample may not.

Do keyboard interactions remain predictable? Do overlays behave correctly? Are visual patterns consistent? Does the application stay responsive? Do the APIs compose naturally?

Performance becomes an application-level concern

A component can perform well in a focused demo.

A SaaS product introduces:

• Real datasets.
• Multiple components.
• Long user sessions.
• Frequent API updates.
• Complex navigation.
• Real customer content.

That environment creates another opportunity to evaluate how shared technologies behave under realistic application conditions.

Usability issues become easier to recognize

An API can be functionally correct while still being inconvenient to use.

Internal product teams encounter many of the same questions external developers do:

• Is the configuration intuitive?
• Is customization straightforward?
• Does a common scenario require too much code?
• Is an API missing an important hook?
• Is documentation clear enough?
• Does a default behavior work well inside a larger process?

Using shared technologies in complete applications provides another perspective on those questions.

Accessibility becomes a design concern

Accessibility is rarely limited to a single component.

A complete application must coordinate:

• Focus movement.
• Keyboard navigation.
• Dialog behavior.
• Dynamic updates.
• Error handling.
• Screen-reader semantics.

Using components together exposes accessibility considerations at the application level.

Framework and platform changes become real

Production applications have to keep moving. 

Frameworks change. Browsers change. Dependencies change. Design requirements evolve.

A real SaaS product therefore provides another environment in which shared technologies experience ongoing integration and upgrade requirements.

That does not mean every request from an internal product automatically becomes an Essential Studio feature. Product-specific requirements should remain product-specific when appropriate.

The broader feedback loop looks like this:

Product requirement → Engineering challenge → Real-world evaluation → Potential technology improvement → Developer ecosystem

Internal products therefore become another source of practical experience alongside customer feedback, support cases, automated tests, documentation, samples, and product engineering.

Three lessons developers can apply to their own products

The same ideas apply beyond Syncfusion.

1. Reuse the primitives. Differentiate in the domain.

Applications contain both recurring technical problems and business-specific problems.

• A customer-support platform needs tables, editors, dialogs, and charts.
• An eSignature application needs document processing.
• An analytics application needs trees, inputs, and layout controls.

Those capabilities may be necessary, but they are not always where the product creates its unique value.

Using mature building blocks can allow a team to spend more time on its own operations, business rules, customer experience, and integrations.

2. Evaluate components inside real applications, not only demos.

A demo can tell you whether a component supports a feature.

A real application reveals different questions:

• Does it compose well?
• Is customization practical?
• Does it perform with real data?
• Is it accessible as part of a larger process?
• How does it behave on mobile?
• How difficult are framework upgrades?
• Can several components maintain a consistent experience together?

Evaluate libraries against representative product scenarios, not only feature matrices.

3. Design for composition.

Large applications are rarely built around one component.

They are systems of:

• Data displays.
• Editors.
• Forms.
• Navigation.
• Dialogs.
• Visualization.
• Document processing.
• Interaction patterns.

The more components an application uses, the more important consistency becomes.

Reusable components should therefore be judged not only by how much each one can do, but by how effectively they work together.

Look beyond the feature list

Framework support, APIs, performance, documentation, customization, accessibility, support, and licensing should absolutely be part of any component-library evaluation.

But they are not the only signals available.

Developers can also ask:

1. Is this technology being used in substantial applications?
2. Can different components work together to support complete business processes?
3. Does the vendor encounter real integration and maintenance challenges while using its own technology?
4. Has the technology been exercised outside carefully constructed demos?

No single answer determines whether a platform is right for your application. But first-hand product usage provides another useful perspective.

We use what we build

• A component demo can show whether a DataGrid sorts correctly.
• A sample can show whether a chart renders.
• Documentation can demonstrate how to configure an editor.
• An API reference can show how to process a PDF.

What those things cannot fully demonstrate is what happens when reusable technologies become part of products with their own users, processes, integrations, constraints, and years of continued development.

That is where internal product usage becomes valuable.

• BoldSign brings document-processing technologies into eSignature management.
• BoldDesk composes reusable UI technologies into a customer-support workspace.
• Bold BI brings interaction, data-management, and visualization components together around analytics.
• Bold Reports combines reporting, visualization, UI, and document technologies across report design and delivery.

Four products. Four different business problems. One shared technology ecosystem.

At Syncfusion, we do not only build tools for developers. We also use those tools while building products ourselves.

To be useful, an AI trace should explain what the agent decided, what data it used, what it cost or whether the output was any good. Progress AI Observability Platform does this for teams building in Python, .NET. and JavaScript/TypeScript.

TL;DR

If your AI trace doesn’t explain decisions, it’s just noise. Most engineering teams ship AI agents with traces that confirm requests completed. They don’t explain what the agent decided, what data it used, what it cost or whether the output was any good.

This is the difference between trace volume and trace hygiene: having spans versus having spans that explain decisions. The Progress AI Observability Platform closes that gap for teams building in Python, .NET. and JavaScript/TypeScript. Start observing, free to start, 5-minute setup.

The Problem

After any AI incident, investigations start the same way: open the observability dashboard and look at what happened. What most teams find is a timeline of spans that confirm the request ran without errors. But they often can’t explain why the agent produced a bad answer, which piece of external data misled the model or what the interaction cost.

The traces aren’t absent. They’re answering the wrong questions.

Standard observability was designed for deterministic systems. Its core questions are infrastructure questions:

• Did the request complete?
• How long did it take?
• Was there an exception?

Those are necessary but insufficient for AI agents, where the difference between a working system and a broken one is often invisible at the protocol level. An agent can return HTTP 200 and still have reasoned over stale data, misunderstood the user’s intent, or consumed five times the expected tokens.

The questions that matter for AI agents are:

1. What did the user ask, and what context did the agent have?
2. What did external tools and APIs return—the exact data the model reasoned over?
3. What exact input did the model receive?
4. What exact response did the model produce?
5. What did this interaction cost in tokens and dollars?
6. Was the output actually good?

A trace designed to answer these is an investigative asset. One that can’t is infrastructure noise.

Trace Hygiene, Not Just Trace Volume

The AI observability community has been working through a specific version of this problem. When teams apply standard OpenTelemetry auto-instrumentation broadly, LLM spans get mixed with HTTP client requests, authentication calls, database queries and framework internals—all technically valid telemetry, none of it useful when investigating a quality failure.

Teams across the AI observability ecosystem have documented the same failure mode: a single agent trace can contain the meaningful LangChain or LLM spans alongside Microsoft Graph authentication calls, generic HTTP client activity and other unrelated infrastructure events because OTel auto-instrumentation does not distinguish AI-relevant spans from infrastructure spans.

The usual workaround is some form of instrumentation-scope blocklist or trace filtering layer, but that surface area tends to grow as more libraries get added. Across the market, vendors have responded by adding span kind selectors, annotation-based filtering, name-based filters and similar narrowing controls because isolating AI signals inside infrastructure telemetry is a recognized, ongoing problem.

The consistent pattern: trace volume is easy to produce; trace hygiene—capturing the right signals, in the right structure, with the right context—requires deliberate design.

Trace hygiene depends on five implementation principles. Those principles are what enable a trace to answer the six investigative questions above:

• Scope: Instrument LLM calls, retrieval and tool invocations—not background HTTP and infrastructure events
• Structure: Spans organized into a hierarchy that reflects agent logic, not library internals
• Content: Prompt text and completion text captured where debugging requires it
• Attribution: Tags that let you filter to a specific tenant, release or experiment on every span
• Quality: Evaluation scores connected to the traces they assess

When a trace is built on these five principles, it can answer all six questions. When it can’t, it’s noise, not signal.

Business Impact

The six questions map directly to the business capabilities that matter for AI systems in production:

Teams that answer all six questions trace AI incidents to root cause in minutes. Teams that can’t may spend hours correlating logs, reconstructing context and writing post-mortems that cite “unexpected model behavior.”

Approach

The Progress AI Observability Platform captures all six elements through automatic and manual instrumentation.

LLM calls, token counts and costs are captured automatically by the SDK. Model input and output (Questions 3 and 4) require enabling content capture—one configuration flag. External tool data (Question 2) is captured when tools are wrapped with observability. Request context (Question 1) attaches via tags. Quality scores (Question 6) come from evaluation tasks configured in the platform.

The platform supports SDKs for the most common AI development stacks:

• Python (progress-observability): One initialization call instruments OpenAI, LangChain, Anthropic, LlamaIndex and 20+ other providers automatically.
• .NET (Progress.Observability.Instrumentation): Wraps IChatClient from Microsoft.Extensions.AI and IAgent from the Microsoft Agent Framework.
• JavaScript/TypeScript: Instruments Node.js-based AI applications and frameworks.

Full documentation and setup guides for all SDKs are in the documentation.

See also: If your immediate concern is detecting AI agents that silently return wrong answers despite reporting success, see When Status OK Is Still a Failure. For managing token spend before the invoice arrives, see AI Cost Visibility Before the Invoice.

Expected Outcomes

Once traces are built on the five implementation principles—and can therefore answer all six questions—teams gain capabilities that weren’t available before:

• Root cause in minutes: The trace contains the answer—the exact prompt, the exact tool output, the exact model response. Log reconstruction is no longer required.
• Verifiable prompt changes: Validate new prompts against historical traces before deploying.
• Granular cost attribution: Spend is tied to specific workflows, tenants and model versions, not just a monthly aggregate.
• Proactive quality monitoring: Evaluation scores surface regressions before users encounter them.

Key Takeaways

• Most teams have trace volume. Fewer have trace hygiene—traces designed to answer the six investigative questions that matter after an incident.
• The gap between infrastructure observability and AI observability is a design gap made at instrumentation time, not incident time.
• Trace hygiene for AI is built on five implementation principles: Scope, Structure, Content, Attribution and Quality. Those principles are what make it possible to answer the six questions.
• The six questions every AI trace should answer: what the user asked, what tools returned, what the model received, what the model produced, what it cost and whether the output was good.
• Start observing with the Progress AI Observability Platform. A Quickstart Guide is available, it’s free to start and a 5-minute setup.

AI Observability Reading Path

1. You are here: The Six Questions Every AI Trace Should Be Able to Answer
2. Coming next: What a Useful AI Trace Should Actually Contain (And How to Build One)—for implementation walkthrough
3. NickIliev/support-agent-demo — hands-on demo on GitHub

Learn the pipeline pattern in C#, its core stages, execution models, tradeoffs, and how to choose a stable .NET 10 implementation for production systems.

If your T-SQL is buried under layers of nested REPLACE() calls just to swap out a few characters, there’s a simpler way. SQL Server’s TRANSLATE() function — introduced in 2017 but still rarely used — lets you replace multiple characters in a single string with one function call instead of stacking several REPLACE() functions inside each other.

This guide covers how TRANSLATE() works, how it compares to REPLACE(), and where it falls short compared to other SQL dialects like PostgreSQL and Oracle.

Anyone who has worked with SQL Server and T-SQL will have seen code where REPLACE functions have been nested, sometimes endlessly. The code ends up hard to read, hard to understand and, worse still, easy to make mistakes with during maintenance. It’s often a mess – and in many cases, a mess that can be avoided.

That’s where the TRANSLATE function – introduced to SQL Server back in 2017 – comes in. Nearly a decade on from its introduction, I rarely see the function used in code, but it’s excellent for this use case.

What is the SQL Server TRANSLATE function?

Imagine I have incoming data with phone numbers in the following format:

[02] 9232:4232

In Australia, I’d like to see those phone numbers formatted like this:

(02) 9232-4232

That seems simple enough, but note the code required if I use the REPLACE function:

DECLARE @PhoneNumber varchar(20) = '[02] 9232:4232';

SELECT REPLACE
       (
           REPLACE
           (
               REPLACE(@PhoneNumber, '[', '('), 
               ']', ')'
           ), 
           ':', '-'
       );

If it was just one or two replacements, I’d put it all on a single line. Then, as the number of replacements increases, I’ll start to spread it out over a series of lines. This is to try to keep the parentheses matching – and to have some hope of following the code.

The TRANSLATE() function takes three parameters: an input string, a set of characters that should be replaced, and a set of characters to replace them. Here’s how we can use it for the example above:

DECLARE @PhoneNumber varchar(20) = '[02] 9232:4232';

SELECT TRANSLATE(@PhoneNumber, '[]:', '()-');

The characters being matched and replaced are determined by their position in the string.

That’s not all, though. You might now wonder what happens if the characters are matched multiple times. For example…

DECLARE @PhoneNumber varchar(20) = '[[02]] 9232:4232';

SELECT TRANSLATE(@PhoneNumber, '[]:', '()-');

…will return ((02)) 9232-4232.

REPLACE vs remove in SQL Server

Another reason why I often ended up using nested REPLACE functions in SQL Server was to remove a particular set of characters out of a string.

Perhaps I want to replace the square brackets with round ones – but also want to remove the colon, not replace it. Unfortunately, the SQL Server implementation of the TRANSLATE function doesn’t support this – as much as I wish it did!

Here’s a good example of why this functionality is needed. If I execute this query…

DECLARE @PhoneNumber varchar(20) = '[[02]] 9232:4232';

SELECT TRANSLATE(@PhoneNumber, '[]:', '()');

…the following error is returned:

Msg 9828, Level 16, State 1, Line 3
The second and third arguments of the TRANSLATE built-in function must contain an equal number of characters.

In T-SQL, the string of matching characters and the string of replacement characters must be the same length. That’s not the case in other SQL dialects. For more on this, see the official T-SQL documentation (where they are called translations.)

In PostgreSQL, Snowflake, Databricks/Apache Spark SQL, Amazon Redshift, and InterSystems IRIS, if the replacement string is shorter than the matching string, the extra characters are removed. You can even have an empty string for the replacement and just use TRANSLATE to remove a set of characters.

Oracle also allows the shorter replacement string, but you can’t have an empty string for the replacement. That’s treated as NULL so, if you do that, the function returns NULL instead. In my experience, people tend to put a ‘dummy’ matching character first, then use the same character as a replacement.

I do wish SQL Server implemented the TRANSLATE function better, but at least it has the function in the first place – unlike Google BigQuery and MySQL.

Summary

If you’re still writing lots of nested REPLACE functions in SQL Server, it’s time to see if any of them could be replaced (pun intended) by using the little-known TRANSLATE function instead. It’s great for this use case.

All I’d really like to see now is the SQL Server team remove the restriction on requiring the characters and the translations parameters that force them to be the same length.

The post How to avoid nested REPLACE functions with TRANSLATE in SQL Server appeared first on Simple Talk.

After our fix yesterday, we got our Renovate pipeline up-and-running. However the next hurdle showed up quickly. Right after the SSL certificate fix, I got the pipeline green, but the log showed this warning:

WARN: Azure: work item type does not exist in project (or the token lacks permission to it); skipping issue. The Dependency Dashboard needs a process that defines this work item type. Set one your project defines via the `azureWorkItemType` repo config option. (repository=Framework en Tooling/SOFACore)
       "workItemType": "Issue",
       "availableTypes": [
         "Bug",
         "Task",
         "Quality of Service Requirement",
         "Scenario",
         "Risk",
         "Code Review Request",
         "Code Review Response",
         "Feedback Request",
         "Feedback Response",
         "User Story",
         "Test Case",
         "Shared Steps",
         "Test Plan",
         "Test Suite",
         "Epic",
         "Feature",
         "Shared Parameter"
       ],

What's the Dependency Dashboard?

The Dependency Dashboard is a Renovate feature that opens (and keeps updated) a single issue in your repo, normally titled "Dependency Dashboard". It's not a PR, it's a living overview of everything Renovate is tracking: which updates are pending and why, PRs that are open or need rebasing, updates that errored out, and checkboxes to manually trigger specific updates on demand.

Azure DevOps doesn't have "issues" the way GitHub does, it has work items instead. So Renovate creates the dashboard as a work item, and by default tries to use the type Issue.

What's going on?

That type doesn't exist in every Azure DevOps process template. Our project runs a customized process, and Issue simply isn't one of the available types there. The log helpfully lists what is available: Bug, Task, User Story, Feature, Epic, and so on.

Renovate doesn't fail the pipeline over this. It just skips creating the dashboard issue and logs a warning. Easy to miss, easy to leave broken for weeks.

The fix

Renovate has a repo config option for exactly this: azureWorkItemType. You point it at a type your process actually defines.

I first tried to add it to the repository's renovate.json, but the pipeline didn't pick up the setting as expected. So I took a different approach and passed it as a CLI argument instead, via --azure-work-item-type:

trigger: none

pool:
  name: default

variables:
  NODE_EXTRA_CA_CERTS: 'd:\vlm-root.pem'

steps:
- task: RenovateMe@1
  inputs:
    renovateOptionsVersion: 'latest'
    renovateOptionsArgs: '--azure-work-item-type Task'
  env:
    RENOVATE_TOKEN: $(System.AccessToken)
    LOG_LEVEL: debug

Task exists in our process, so that's what I picked. Pick whatever fits your own workflow — Bug or Feature would work just as well if that matches how your team triages dependency updates.

Remark: the availableTypes list in the warning is our project's actual process definition. Renovate uses the Azure DevOps API to extract this data.

After this change, the warning is gone and the Dependency Dashboard work item shows up as a Task in the project.

That's it!

More information

• Renovate docs: azureWorkItemType
• Dependency Dashboard - Renovate Docs

The conversation around AI is often dominated by models, tooling and the latest advances in generative and agentic AI. Organisations are understandably keen to understand how these technologies could improve operations, unlock efficiency or create new opportunities.

However, in many cases the biggest challenge isn’t choosing the right AI solution. It’s ensuring the foundations are in place to support it.

The organisations seeing the greatest value from AI are not necessarily those with access to the latest models. More often, they are the organisations with solid data foundations: discoverable, high-quality, and safely accessible. This is particularly important as businesses begin exploring agentic AI, where systems move beyond generating content to reasoning, making decisions and initiating actions.

Start with the business problem

One of the most common mistakes organisations make is approaching AI as a technology initiative rather than a business initiative.

Before considering models or platforms, it’s important to understand the problem being solved and what information is required to solve it. Only then can organisations determine whether they have the necessary data of sufficient quality.

In our experience, AI readiness often comes down to three fundamental data questions:

• Do we have the right data?

• Is that data sufficiently trustworthy and complete?

• Can it be accessed in a way that enables AI systems to use it effectively?

Answering these questions may not be as exciting as experimenting with the latest AI tooling, but it is often the difference between success and disappointment.

Agentic AI raises the stakes

Many organisations are now looking beyond traditional machine learning and generative AI towards agentic systems.

These systems have the potential to be highly valuable because they can be given a broad goal and work out the best way to achieve it (within security bounds) across disparate systems. However, they also place greater demands on the underlying data.

A chatbot that provides an inaccurate answer is a problem. An autonomous system acting on inaccurate information can create much larger challenges.

As organisations increase the level of autonomy, they are willing to give AI systems, the importance of trusted, accessible and well-governed data increases accordingly.

This is why successful AI programmes often spend as much, if not more, time focusing on data architecture, governance and integration than they do on developing and evaluating agents themselves.

Data silos remain one of the biggest barriers

For many large organisations, data exists across a complex estate of operational systems.

These systems have often evolved over many years, serving individual business functions well but making it difficult to create a holistic view of information across the organisation. Data may exist in multiple formats, be duplicated across platforms or be subject to different ownership and governance controls.

This creates challenges not only for analytics, but also for AI.

We’ve seen examples where valuable information exists within an organisation but cannot easily be used because it is fragmented across multiple systems. Bringing that information together in a governed and accessible way can be a significant step towards enabling future AI capabilities.

The prototype is only the beginning

Many organisations have already built promising AI prototypes.

Demonstrations can often be created quickly and can generate considerable enthusiasm among stakeholders. The challenge typically emerges when organisations attempt to move those solutions into production.

Production AI systems require security controls, operational safeguards, monitoring, testing and governance. They must perform reliably under real-world conditions, not simply in a controlled demonstration environment.

The same is true of the data underpinning these systems. Inconsistent, inaccessible or poorly understood data may not prevent a prototype from functioning, but it can create significant obstacles when trying to scale.

Legacy data platforms often become an AI challenge

Many organisations pursuing AI initiatives eventually discover that the greatest barriers are not related to AI at all.

Legacy data platforms, data quality issues, and fragmented architecture can all limit the ability to adopt new capabilities effectively.

This is not surprising. If information is difficult to find and access, poorly quality or held within systems that are expensive to change, introducing AI on top of those foundations is unlikely to solve the underlying problem.

In many cases, successful AI adoption and modernisation go hand in hand.

Focus on fundamentals

The AI landscape will continue to evolve rapidly. Models will improve, tooling will mature and new approaches will emerge.

What is unlikely to change is the importance of data.

Organisations that understand their data, invest in its quality and create architectures that make it accessible will be better positioned to take advantage of whatever comes next. Those foundations support analytics, machine learning, generative AI and agentic systems alike.

The organisations that succeed with AI won’t necessarily be those that adopt the newest technology first.

They will be the organisations that have done the work to make their data usable, trustworthy and accessible.

Because ultimately, AI success depends on data foundations.