Atlassian Solution Composer: Create with Rovo in JSM

Solution Composer is Atlassian's AI setup for Jira Service Management: you describe a team in plain words and Rovo builds the service space. In Jira it's called Create with Rovo. Its launch post has 10,362 views, and one of the first questions under the follow-up AMA was whether it's only for brand-new service desks. It is, for now: the support doc says it "only creates new company-managed spaces". I wanted to know what you actually get from a short prompt, and how much of it you could use on Monday.

So on 5 November we typed two sentences about a 12-person finance team into it on our test site and said yes to its proposal. About three and a half minutes later we had a new Jira Service Management space with 4 request types, 7 queues, 3 SLAs and 3 workflows. Its forms already asked for the amount and the vendor, which is the part I'd normally spend an afternoon on.

Then we filed test requests, and a 25,000 EUR purchase order never reached a manager. The plan had promised manager approval for orders over 10,000 EUR. But nothing in the build sends an order to approval or says who approves it. The Waiting for approval queue stayed empty because it looks for a status name the workflows don't use. And the urgent queue and the urgent SLA only matched requests that contained the word payment.

I think Solution Composer gives you a very good first draft of a service desk, as long as you test it with a few fake requests before you let anyone into the portal. It took us four edits to make the space do what the plan said, and every step is below.

[[steps]]

1. Open Create with Rovo and describe the team in a prompt with your rules in it.
2. Review the plan before anything is built.
3. Create the space, read back what it built, and file fake requests for each rule.
4. Point the approval queue at the real status the workflows use.
5. Base the urgent queue on priority instead of words in the text.
6. Make the urgent SLA match on priority too.
7. Add the 10,000 EUR approval rule that sends large orders to a named approver.

Before you start: plans, Rovo and company-managed spaces

Note

Prerequisites

• Jira Service Management on a Service Collection Standard, Premium or Enterprise plan, with Rovo on.
• Permission to create a space (we used a Jira admin account).
• A test site or sandbox you're happy to add fields and workflows to.
• Tested on wolfaenpak.atlassian.net, our test site, on 5 November 2026.

The plan, Rovo and permission requirements come from Atlassian's Create a service space with Rovo doc (last published 22 October 2026). In its words, "This experience is in open beta and available on the Standard, Premium, and Enterprise Service Collection plans with Rovo enabled." Your organization also needs an active Rovo entitlement. An org admin manages that in Manage Rovo access.

Who can create the space is less clear. The Rovo doc says "Jira admins or space admins", while the older Create a service space doc says only Jira admins can. We ran everything as a Jira admin. So we can't tell you which one is right today.

The sandbox is our advice. The build adds new fields and workflows to your site, and you'll want to file fake requests against it.

Atlassian's announcement and the Team '26 Europe Service Collection post call it Solution Composer. The support doc and the Jira screens say Create with Rovo, although the page's own element IDs still say solution-composer-entry. When we wrote up the Team '26 Europe announcements in October there was no support doc for it yet. There is now.

On cost, the Rovo credits doc says "AI features in beta don't currently count against your Rovo credit allowance unless stated otherwise." It doesn't say which of its rows covers this flow, and we didn't check our usage screen after the run, so I can't give you a number.

Where to find it: Create with Rovo in Jira

In Jira, open Create space (or Jira settings, then Spaces, then Create space). Under PRODUCTS on the left, pick Jira Service Management. It's the first card in the template gallery.

You can also get there from the Create with Rovo item in the left list. It shows two cards: "Get started with a prompt" (the general Jira one) and "Create a service desk", marked Beta. That second card opens the same dialog.

Set up a service desk from one prompt

Step 1: Open the composer and describe the team

Click the card. A dialog opens that says "Let's create a service space". It has a text box ("Describe your work and the type of requests your team manages"), a microphone for dictation, and a few starter prompts such as IT support and HR support.

I'd write your own prompt and put your team's rules in it, a threshold or a deadline, because those rules are what you'll test later. This is the prompt we used, word for word:

A service desk for our 12-person finance team: employees ask about expense reimbursements, request purchase orders and query supplier invoices. Purchase orders over 10,000 EUR need a manager's approval, and urgent payment problems should get a first response within 4 business hours.

About 30 seconds after you submit, you should see "Thinking completed" and a short proposal. Ours promised approvals for purchase orders over 10,000 EUR and faster handling for urgent payment problems, with the 4-hour target. It also offered tailored ways to ask for help and a set of team views. It ended by asking:

Does this sound like the right starting point for your team, or would you like to adjust any of these details?

You can change things here in plain words. We only said yes, so I can't tell you how it handles corrections:

Yes, that sounds right. Please put together the detailed plan.

Step 2: Review the plan before Rovo builds the space

About 40 seconds later you'll get "Completed 6 steps" and a plan card. Nothing has been created yet. In the doc's words, "Nothing is created until you confirm."

Read it slowly. Our plan named the space Finance Service Desk with the key FIN and channel access set to Restricted, which means only people you add can raise requests. Under that it listed five sections, and the last one read: "A multi-step process for purchase orders that includes manager approval for requests over 10,000 EUR."

Step 3: Click Create space and wait about two minutes

Click Create space. Ours finished in under two minutes ("Completed 36 steps", then "Your new finance help desk is ready!" and a View space button). From opening the card to a built space took about three and a half minutes.

What Solution Composer in Jira Service Management builds

We read the new space back through the REST APIs. This is what was on the site:

Part	What we got
Space	FIN, company-managed, service desk
Request types	Expense Reimbursement, Purchase Order Request (work type Budget request), Supplier Invoice Query, plus the stock Emailed request
Portal groups	General and Finance Requests
New fields	Amount (a number), Currency (free text), Vendor Name, Expense Category, Expense Date, Invoice Amount, Invoice Date, Invoice Number, Supplier Name
Queues	7: All open, Assigned to me, Unassigned, Resolved, plus All open work, Urgent payment problems and Waiting for approval
SLAs	Time to first response 8h, Time to resolution 80h, Urgent Response Time 4h
Calendar	"Sample 9-5 Calendar": Monday to Friday, 09:00 to 17:00, Jira default time zone (Bucharest on our site), no holidays
Workflows	Budget request (with approval) for purchase orders, Expense request (with approval) with a Payment status, and the general request workflow for invoice queries
Automation	1 rule: reopen a closed request when the customer comments
Knowledge base	0 articles

We got the request types we asked for, with finance questions on each form. Both approval workflows have a real approval step, too. Approvers come from the Approvers field and "Everyone from 'Approvers' must approve". The reporter is excluded.

A few things I'd look at before going live. Currency is a free text field, so someone will type "euro" sooner or later. Every finance form shows the Approvers and Priority fields to the person raising the request, so requesters pick their own approver and their own urgency. Expense reimbursements also got an approval workflow, although our prompt only asked for approvals on large purchase orders. The 9-to-5 calendar is a sample calendar the space picked up from the site, with no public holidays in it. And the new fields we checked (Amount, Currency, Vendor Name) were created with global contexts, so they're site-wide custom fields with very generic names. If your site already has an "Amount" field, you'll have two.

Test it with fake requests first

We filed four requests as the admin, through the portal's REST API, and watched where each one went. Two of them surprised us:

Request	What we expected	What happened
FIN-1: purchase order, 25,000 EUR	Sent to a manager for approval	Stayed in To Do. Moved to Awaiting approval by hand, it had 0 approvers and no transitions left
FIN-2: "Urgent: payment to supplier failed", Highest	4h urgent SLA, in the urgent queue	Got the 4h SLA. Not in the urgent queue
FIN-3: "Supplier says our transfer bounced", Highest	Same as FIN-2	No 4h SLA, not in the urgent queue
FIN-4: train ticket, 45 EUR	Handled without approval	Went into the expense approval workflow

In the purchase order workflow, a request only reaches Awaiting approval after three manual transitions. Confusingly, their names don't match where they go: "In progress" moves it from To Do to In review, "Move to In progress" moves it to In Progress, and "Ready for approval" moves it to Awaiting approval. Nothing does this automatically, and nothing fills the Approvers field. When we pushed FIN-1 through by hand, Jira created an approval with an empty approver list, and the admin had no transitions left to use.

After the build: tune what Rovo set up in Jira Service Management

We made four edits, in the order I'd make them. Three are small edits (two queue filters and one SLA goal), and the last one is an automation rule. You should see each change in a queue count or on a test request before you move on.

Step 4: Point the approval queue at the real status

Go to Queues and open Waiting for approval. In the More actions (...) menu at the top right, pick Edit queue. You'll see the generated JQL:

project = FIN AND status = "Waiting for approval" ORDER BY created DESC

But the FIN workflows call that status "Awaiting approval". "Waiting for approval" exists on our site as a status from other spaces, so Jira accepted the JQL without an error and the queue stayed empty. Change it to the status the workflows really use, and Save:

project = FIN AND status = "Awaiting approval" ORDER BY created DESC

After saving, you should see the orders that are actually waiting. Ours showed this right after FIN-7 was filed (FIN-8, filed later in Step 7, joined it):

Waiting for approval: 3 work items
FIN-7  Standing desks for the Cluj office   Awaiting approval
FIN-5  Office chairs for the Bucharest office   Awaiting approval
FIN-1  New laptops for the sales team   Awaiting approval

To check your own space, open the approval workflows (Space settings, then Workflows) and compare the status names with the queue's JQL.

Step 5: Base the urgent queue on priority

Urgent payment problems got this JQL:

project = FIN AND (summary ~ payment OR description ~ payment) AND (summary ~ problem OR description ~ problem) AND priority in (High, Highest) AND resolution = Unresolved ORDER BY created DESC

A request only shows up if its text has the word payment and also the word problem. FIN-2 said "payment to supplier failed" and FIN-3 said "transfer bounced", and neither one appeared. Both were set to Highest. We changed it on the same Edit queue screen to use priority alone:

project = FIN AND priority = Highest AND resolution = Unresolved ORDER BY created ASC

You should see the open Highest requests. Ours went from 0 to 2:

Urgent payment problems: 2 work items
FIN-2  Urgent: payment to supplier failed
FIN-3  Supplier says our transfer bounced

We kept only Highest, which is narrower than the generated High or Highest, so use priority in (High, Highest) if High should count as urgent for your team. Requesters choose Priority on the portal form, so this queue now trusts them. If that worries you, hide Priority on the request types and set it during triage.

Step 6: Make the urgent SLA match on priority

Open SLAs in Space settings. Click Edit on Urgent Response Time. Its goal applied 4 hours only to this:

project = FIN AND (summary ~ payment OR description ~ payment) AND priority in (High, Highest)

Replace the JQL so it matches the queue from Step 5, leave 4h and the calendar as they are, and Save:

project = FIN AND priority = Highest

To confirm it worked, check the SLAs on a request that missed out before. FIN-3 ("transfer bounced", no word payment) had no urgent target until this edit. We used the JSM REST API with an API token:

curl -s -u "$EMAIL:$TOKEN" "https://<your-site>.atlassian.net/rest/servicedeskapi/request/FIN-3/sla" \
  | jq -r '.values[] | "\(.name): \(.ongoingCycle.goalDuration.friendly // "no goal")"'

You should see the 4h goal on it now:

Time to first response: 8h
Time to resolution: 80h
Urgent Response Time: 4h

Jira also warns that "SLA edits can take time to effect", so give existing requests a little while to recalculate. While you're on this page, click the calendar icon. If your finance team isn't on the site's default time zone, or you want public holidays excluded, set up your own SLA calendar and pick it in the goal.

Step 7: Add the 10,000 EUR approval rule yourself

This one takes longer. Our plan promised this rule and the build didn't create it. We built it through the Automation REST API, not the rule builder, so the builder labels below come from Atlassian's doc, not from our clicks. Open Space settings > Automation, select Create flow, and build it with these parts:

1. Trigger: Work item created.
2. Condition, JQL: issuetype = "Budget request" AND cf[13029] > 10000. Budget request is the work type behind Purchase Order Request, and on our site the Amount field the composer created is customfield_13029. Check the ID of yours in the field settings.
3. Action: Edit work item, set Approvers to the finance manager. We used the additional fields box (below).
4. Actions: Transition work item to the status In review, then to In Progress, then to Awaiting approval. The workflow has no direct path, so it takes all three, and here you pick the destination statuses, not the transition names from the test section.

We used this additional fields JSON for the approver. Put the manager's account ID in place of the placeholder:

{
  "fields": {
    "customfield_10003": [ { "accountId": "<finance manager's account ID>" } ]
  }
}

Our first version of this rule didn't work. It set Approvers with the field picker format. It ran the three transitions and left Approvers empty, so FIN-5 (18,500 EUR) reached Awaiting approval with no approvers. Switching the edit to the JSON above fixed it. In the rule builder, check the audit log on your first test order to be sure the approver really got set.

With the rule in place, we filed three more orders:

FIN-6  Monitor arms for the finance team    3,000 EUR   -> To Do, no approval
FIN-7  Standing desks for the Cluj office  12,400 EUR   -> Awaiting approval about 6 s after creation,
                                                           Approvers: our test manager account, approval pending
FIN-8  Server rack for the lab             15,000 EUR   -> requester picked themselves as approver;
                                                           the rule replaced it with the manager

On FIN-7, the Approvals tab showed "Everyone from 'Approvers' must approve", with the reporter excluded. FIN-8 shows that the rule overwrites whatever the requester typed in Approvers, so you may as well hide that field on the Purchase Order Request form.

This rule has limits. Amount is optional on the generated Purchase Order Request form, so an order with no amount skips the rule. If all orders need the check, make Amount required on that request type (we didn't test that change). The rule also reads Amount only, and Currency is free text, so 12,000 USD and 12,000 EUR look the same to it. If you take orders in more than one currency, turn Currency into a select list and add it to the condition. It also doesn't touch expenses: FIN-4, the 45 EUR train ticket, still goes through the expense approval workflow. We left that as it was, because some finance teams do want all expenses approved. If yours doesn't, map Expense request to a workflow without the approval step. If your purchase orders need more than one approval stage, our CAB approval tutorial walks through approval steps in JSM workflows in more detail.

Is Solution Composer worth using?

For a new desk, I think yes. In three and a half minutes it got us request types and forms that matched the team, plus queues, SLAs and approval workflows, from a prompt anyone on the finance team could have written. Our scripts made the four repairs in under ten minutes. By hand I'd budget an hour, mostly for the test requests. Starting from a template, we'd have built the same finance fields and forms ourselves.

It doesn't give you a desk you can open to people without checking it, though. Not yet. The rules in our prompt were exactly the parts that didn't fully work: the approval threshold became a workflow with nobody in it, and "urgent payment problems" became a keyword search. So I'd use it on a sandbox, with the real prompt, and treat each rule in your prompt as a test case.

If something doesn't work

1. You can't find the Create with Rovo card. It needs Rovo on and a Service Collection Standard, Premium or Enterprise plan, according to the doc. Your org admin manages Rovo in admin.atlassian.com.
2. A queue is empty while requests are clearly waiting. Compare its JQL with the status names in the space's workflows. Jira accepts a status name that exists anywhere on the site.
3. An approval sits pending with nobody on it. The Approvers field was empty when the request entered Awaiting approval. Set approvers before that transition, from a rule like Step 7.
4. Your rule moves the request but Approvers stays empty. Set the field with the additional fields JSON, then file a new test order and read the rule's audit log.
5. An urgent request shows no SLA target. Check the goal's JQL for text matches like summary ~ payment, then give the SLA time to recalculate after you edit it.

What you have now

A finance service desk built from one prompt, tested with eight fake requests, with four edits on top: the approval queue's status, the urgent queue's JQL, the urgent SLA goal, and an automation rule that sends purchase orders over 10,000 EUR to a named approver.

Some things we didn't test, so check them on yours: how the composer handles corrections before you approve the plan, whether a space admin who isn't a Jira admin can use it, the portal from a customer's seat, and whether the build used any Rovo credits. An Atlassian team member, Premanku Chakraborty, replied in the AMA thread that the composer's capabilities can also be used to modify an existing desk, for example by adding queues and request types. Today the support doc mentions adding a request type and editing its fields after creation. We didn't try either.

[[takeaways]]

• What you built. A Jira Service Management space from one prompt, tested with fake requests, with the approval queue, the urgent queue and the urgent SLA fixed, and the missing approval rule added.
• What to check first on yours. The rules in your prompt, each as a fake request. Thresholds and approvers first, then urgency and the status names in queue JQL.
• What this doesn't cover. Corrections before the plan, non-admin creators, the customer's view of the portal, and Rovo credit use. We didn't test those.

If you'd like a Rovo agent helping with triage once the desk is live, we built one step by step in this Rovo Studio tutorial. And if you try Solution Composer with your own prompt, tell me which rule it got wrong for you. I'm curious whether it's always the rules.

---

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.