Community resources
Community resources
Community resources
Why Is It So Hard to Use Rovo for JSM Portal Request Type Guidance? [Champions Slack Insider]
This thread sparked by @Paulo Ramalho gets at a very practical question: if a customer wants to surface Rovo in the JSM portal, what can it actually do well today?
Paulo tested one of the most obvious quick wins: helping users choose the correct request type. The challenge is that Rovo does not reliably generate valid portal request type links, and it does not properly understand JSM Forms, only exposed fields. That means some of the most intuitive portal use cases sound good in theory, but break down quickly in practice.
What is going wrong with request type recommendations?
The first issue is deep linking.
Rovo may return a request type URL, but the link can be invalid because it uses the wrong portal ID or otherwise constructs the path incorrectly. That makes direct linking too unreliable for a clean customer experience.
The second issue is scope.
If the agent is instructed to scan every request type across many projects, the task becomes too large and too brittle. The model has to compare a large volume of live options, which increases the chances of drift, missed matches, or inconsistent answers.
The third issue is request creation.
If the request type depends on JSM Forms, Rovo cannot reliably work with that structure yet. It can reason over fields that are exposed, but not the form logic as users experience it in the portal.
What is the best current use case for Rovo in the JSM portal?
Right now, the strongest portal use cases are guidance and triage, not execution. That means Rovo works best when it helps users:
- clarify what they need
- narrow down the right request category
- recommend a request type by exact name
- summarize policies or instructions
- answer common questions that prevent unnecessary tickets
This is much more reliable than trying to make it raise requests or navigate users directly into the correct form.
How should you improve the request type recommendation agent?
The biggest improvement is to reduce scope. Instead of telling the agent to exhaustively review every request type across ten projects for every request, narrow the logic.
A better pattern is:
- ask clarifying questions first
- identify the likely domain or project
- then compare request types within that smaller set
This reduces cognitive load and usually improves the quality of the recommendation.
It also helps to give the agent examples. Instead of relying on exhaustive scanning alone, provide examples of common user intents mapped to the most likely request types. That gives the agent better behavioral guidance than a giant retrieval task.
Finally, recommending request types by exact name rather than by link is the right workaround for now. It is less elegant, but more dependable.
What else can a portal-surfaced Rovo agent do well?
If the customer has limited Confluence content, you can still show value with lightweight use cases such as:
- request type guidance by name
- policy and process explanations
- basic ticket deflection
- intake triage through clarifying questions
- summarizing what information the user should prepare before submitting a request
These are lower-risk and easier to demonstrate than request creation.
Champion takeaway
Rovo in the JSM portal is currently better at helping users decide what to do than actually doing it for them. If you treat it as a triage and guidance layer, you can get a useful early win. If you treat it like a form-aware portal assistant that can deep-link and submit requests cleanly, you are likely to hit frustration quickly.
Was this helpful?
Thanks!
Dr Valeri Colon _Connect Centric_
3 comments