Home TechWhen UiPath Content Suddenly Vanished: The Truth About the Change

When UiPath Content Suddenly Vanished: The Truth About the Change

by conciergewire
0 comments

The Great UiPath Disappearance: What Happened to the Specific Content Feature?

A major change in UiPath recently disrupted many workflows, including mine — the removal of the Specific Content feature. This feature once made it easy to access and manage detailed data within queues in UiPath Orchestrator, and its sudden disappearance caught many by surprise.

Initially, I didn’t realize what had happened. The issue coincided with a broader UiPath incident across Europe in mid-March 2024 involving a communication mining outage in the EU region. I assumed this outage was affecting my processes, but after a few days, even as systems stabilized, the Specific Content was still missing. That’s when I decided to investigate further.

After browsing the UiPath Forum

I discovered that many other users were facing the same problem. When retrieving transactions through the “Get Queue Items” activity, the reference would still return properly, but Specific Content always appeared as null. A UiPath employee later confirmed in the forum that the platform had stopped supporting retrieval of Specific Content via the “Get Queue Items” activity. This decision had actually been announced back in December, though the change wasn’t deployed to community tenants until mid-March. For enterprise tenants, the update will take effect in July 2024.

What Exactly Changed?

On December 15th, UiPath announced new rate limits as part of industry best practices designed to maintain better performance, security, and system stability.

Benefits of these changes include:

  • Ensuring predictable system behavior
  • Improving application performance
  • Strengthening security
  • Promoting fair resource usage

New rate limits applied:

  • Each tenant is limited to 100 API requests per minute on these endpoints:
    • GET/odata/Jobs/?<filters>
    • GET/odata/QueueItems/?<filters>
  • Any excess calls beyond this threshold result in an HTTP 429 (Too Many Requests) response.

Notably, these limits do not affect adding or processing queue items or running jobs. You can still add, remove, and process as many queue items as necessary without performance penalties.

Fields That Have Been RemovedBeyond Specific Content, several other data fields have also been removed from the “Jobs” and “Queue Items” endpoints.

For Jobs (GET/odata/Jobs):

  • InputArguments
  • OutputArguments

For Queue Items (GET/odata/QueueItems):

  • SpecificContent
  • OutputData
  • AnalyticsData

As a result, workflows that previously relied on these fields will now encounter null values where data once existed.

How to Retrieve Specific Content Now

Here’s an example of how the current “GetQueueItems” activity returns data:

text

List(1) { 

  QueueItem { 

    AssignedTo=null, 

    DeferDate=null, 

    DueDate=null, 

    Id=XXXXXXXXX, 

    ItemKey=[XXXX-XXXX-XXXX-XXXX-XXXX], 

    QueueName=”X_Queue”, 

    Reference=”XXXXXXXXX”, 

    SpecificContent=null, 

    Status=Successful 

  } 

}

As shown, Specific Content now always returns as null. UiPath recommends using the endpoint GET/odata/QueueItems({key}) to fetch the full data for each item instead.

At first, this was confusing. I initially tried using the ItemKey and ran into errors, but after some testing, I realized that requests must be made using the Id value instead. To handle this, I updated my dispatcher to loop through all queue items, send a GET request using each item’s ID (/odata/QueueItems(” + currentItem.Id.ToString() + “)), and then deserialize the JSON response to restore the Specific Content data back into the workflow.

Final Thoughts

The loss of Specific Content has impacted many of the automation processes I built and maintained. While I understand UiPath’s motivation — improving reliability and performance — I wish such a significant change had been communicated directly to Orchestrator administrators via email. Like many others, I only learned about it through a forum discussion.

Although the official documentation updates are technically sufficient, important product changes like this deserve clearer outreach. The current workaround, which involves sending separate API requests for each queue item, significantly increases processing time and complexity — a point that clients found hard to accept.

You may also like