Bentley Infrastructure Cloud IDEAS Portal - New
The ProjectWise Error 222 is used for managed workspace errors as well as a host of other file open problems. It would be easier to troubleshoot for our users to have an error specifically for managed workspace issues.
The generic intro text of "Cannot start application for the specified document. Check your program associations" is wrong 99% of the time.
Including the actual text from the configuration %error message is great, but it gets all jumbled together and nobody wants to read through it to see the actual problem. Adding blank lines around the message would help set it off from the other text.
I think it would be much easier to troubleshoot if:
It has a unique error number to search knowledge bases for
The error was "A managed workspace error has occured" followed by a blank line, then the %error text, then another blank line, and finally the configuration file and line number the error occurred on.
From a support standpoint, improving how managed workspace errors are surfaced would have a significant positive impact on both troubleshooting efficiency and user experience.
Today, Error 222 is overly generic, covering a wide range of issues well beyond managed workspace problems. This creates unnecessary ambiguity for end users and support staff, resulting in longer triage times and increased ticket volume. The default message (“Cannot start application for the specified document. Check your program associations”) is misleading in most cases and often sends users down the wrong troubleshooting path.
Introducing a dedicated error code specifically for managed workspace issues would immediately improve searchability in knowledge bases and allow support teams to quickly identify known issues, standard resolutions, and root causes.
Additionally, improving the format and readability of the error message would make a meaningful difference. Clearly separating the
%erroroutput with whitespace and presenting it in a structured way—followed by the configuration file name and line number—would allow both users and support staff to quickly pinpoint the issue without parsing dense, unstructured text.In summary, these changes would:
Reduce misdiagnosis and unnecessary troubleshooting steps
Improve knowledge base search effectiveness
Enable faster root cause identification
Decrease support ticket handling time and escalations
Provide a more intuitive experience for end users
This is a relatively small usability improvement that would deliver outsized operational value for both users and support teams.