Hey Atlassian Community! đź‘‹
Atlassian's Rovo already has great in-house agents that serve several needs within the Atlassian ecosystem, but what if your organization uses tools from different ecosystems and you want to integrate them within Confluence or Jira without too much manual effort?
That's why our team explored the vast possibilities of Rovo Agents built on Forge. Since many have asked about possibilities to retrieve data from external SaaS systems, we chose to try out the possibilities on a real-life use case.
We needed a use case that hit the sweet spot: substantial enough to test API integration and how well Rovo handles external data outside the Atlassian ecosystem, but manageable enough to complete within our 4-week sprint. That's why we chose to connect our external SaaS time-tracking system (MOCO) directly to Confluence. Since we could actually use it internally rather than just a proof-of-concept that sits on a shelf, MOCO-Buddy bridges the gap between our time tracking system and Confluence documentation - no more switching between tools to pull project data or check hours.
Phase 1: First Steps with Forge App We initially started by developing a Rovo Agent as a Forge App. To integrate with MOCO, we implemented its API endpoints as individual functions.
Phase 2: From Endpoints to a Universal Fetch Shortly after, we realized that maintaining separate functions for each endpoint was inefficient. Instead, we refactored the implementation into a universal fetch function and supplied the agent with relevant excerpts from MOCO's API documentation. This allowed the agent to:
Identify the appropriate endpoints on its own
Provide correct API paths
Interpret response structures to deliver precise results
This universal approach proved far more flexible and powerful than hard-coding every single endpoint.
Phase 3: The Key to Success — A Solid Prompt The most critical factor turned out to be a well-crafted prompt. To accelerate prompt improvements, we combined a no-code agent with our Forge function exposed as a no-code action. This setup allowed us to iteratively refine the prompt inside the no-code agent without having to rebuild and redeploy the app each time. Then move the perfected prompt to your Forge app. This cut our development cycles significantly.
After several iterations of refining prompts and improving the agent configuration, the results started to show real promise. Pretty impressive, actually. But more importantly, we learned where Rovo shines and where it... doesn't.
âś… What Worked:
Universal fetch functions - more flexible than hard-coded endpoints
No-Code for rapid prompt crafting - pairing a no-code agent with your Forge function is excellent for accelerating your development cycles.
External API integration is definitely possible with the right approach
⚠️ The Reality Checks:
No contextual memory between interactions - our biggest frustration. Information like specific API response data gets lost between queries. It has to be determined again for each query.
Response times can be very slow with API calls involved
Requires significant iteration - not plug-and-play despite what demos suggest
Initial result quality was inadequate without precise prompting
One surprising limitation we hit: the convenient actions available in No-Code Studio ("Page Create", "Issue Create") aren't available in Forge apps. Want to create a Confluence page from your Forge agent? You'll need manual API implementation.
Our hybrid approach: No-Code Agent + Forge Functions + No-Code Actions (e.g. “Page Create”) - not elegant, but effective for complex workflows.
What's your experience been with external integrations? Are you using No-Code, pure Forge, or a hybrid approach?
Kavitha Vaikunthavasan _Seibert-Products_
Product Owner - Awesome Custom Fields
Seibert-Media GmbH
Wiesbaden, Germany
1 accepted answer
1 comment