Why are we all testing an incomplete cloud version of jira?

[Todd Grayson]

From previous experience with jira, to setting up a new organization in the current jira cloud, I need to ask "why are we being forced into this new framework without an option to continue in a "classic" work environment?

Rovo is not helping either.  Any time I request help I'm getting lost in the fact that it has NO CONTEXT of what version of jira product I'm in and is directing me on the assumption that I'm in classic, even after stating I'm in new jira cloud.   The diaglog capture below says it all. Even Rovo acknowledges this is a sub-par user experience!

I've got a ticket open, but I also want to reach out to the community to confirm that the workflow, automation, and scheme tools are not reflecting configured state as you attempt to work through them.  Tasks are under-represented by a classification system that is not visible or covered in the documentation. 

Attempting to construct flows and automation that mirrors previous jira implmenentation types is extremely difficult if not impossible to manage.  All we can do is dumb down our SDLC processes to the current default state in JIra?!?!? 

What is the logic of pushing users into this new experience when its not complete and your AI is stating things like below once challenged with the fact that it does not have correct information on how to guide a user within the new product experience, correctly?

[Trudy Claspill]

Hello @Todd Grayson 

Welcome to the Atlassian community.

It is a challenge to address the concerns you have raise when there are no specific details. You refer to the "classic" work environment, and then also to multiple features of the system.

And we don't know what you experience level is. Did you work previously with Jira Data Center? How long have you been working with Jira Cloud? How long have you been an administrator of Jira?

You may have loads of experience. I'm not implying that you don't. I am only saying we don't really have enough context to have a discussion of your concerns.

If you can provide us with the details of a scenario you are trying to work through perhaps we can offer you advice relevant to that scenario, or validate your concerns about the product.

[Todd Grayson]

The issue is that rovo is not aware of what version of product a user is in that is asking questions, and contineously guides based on assuming Jira classic is being used. 

The configuration path that is being attempted is working over task type (only epic and story are shown in the task management and scema screens) triggering me to attempt to "add" or "create" them while rovo points out "dont do that they are there but now shown".  The actual list of task types configured are "Epic, Story, Task, Sub-Task and Bug".  This missing information extends into the automation creation and prevents being able to set up based on what should be available as a type. 

Across multiple issues that I've discussed with rovo, it keeps stating the same thing, that the current cloud user experience is sub-par.

What I want is to be able to run a project in classic, that rovo can properly guide me within, and not have it give up and point out things are not complete and documentation doesn't exist to properly address how to do whats needed.

I've been working in Jira across data center, and cloud across multiple organizaitons since 2007.

[Trudy Claspill]

Thank you for that additional context. That is helpful.

I can't really speak to the Rovo experience as I have not worked with it that much. But I can try to help you with the problem that you are trying to use Rovo to help you solve. Assuming you want help with that, I'll proceed. And if you don't want help with that, that's okay too.

I'll be walking through this with no assumptions about your knowledge, as that could prove helpful to somebody else who reads this post later.

You mentioned wanting to run a project in "classic". In Jira Cloud there are two classifying elements for a project;

Business, Software, or Service (based on your Atlassian app subscriptions)
Company-managed (aka "classic") or Team-managed.

What is the type of the project with which you are having the problem? As you may already know you can find that information in the Type column on the View All Spaces page, or by clicking on the ... next to the Space name in the navigation panel on the left and reviewing the last two lines in the pop-up that displays.

If I understand correctly the problem you are encountering is that you believe that for the project/space you are using the task types Epic, Story, Task, Bug, and Sub-task should be available, but you are only actually able to interact with the types Epic and Story. Is that correct?

For Company Managed projects the issue types available are controlled first by what is defined globally at {yourBaseUrl}/jira/settings/issues/issue-types, and then by the issue types available in your Issue Type Scheme shown in the Space Settings in the Summary tab.

For a Team Managed project the issue types are defined within the Team Managed project itself. If you go to Space Settings > Work Types you see the types already available in the project and the option to Add Work Type.

When a project/space is created there is a point in the process, depending on the project template you choose, where you have an opportunity to switch between proceeding with the template to set up a Company Managed project or a Team Managed project.

If you can provide us with the context of the type of project you are using, and what work item types are available in it based on the Space Settings, and where you are expecting to see more types but don't see them, we can then proceed with more debugging of your scenario.

[Todd Grayson]

So this "rovo set of instructions" is what I'm attempting to work through

------------------

1. Add a Transition to "Bug Management"
Create a transition from relevant statuses (e.g., "Build Broken," "Blocked," or "In Review") labeled “Create Bug” or “Escalate to Bug Workflow.”

This transition should not just move the work item to another status, but also trigger the creation of a linked bug in your separate bug workflow.

2. Use Automation or Post-Functions
Set up an automation rule or post-function on the transition so that when it’s used:

A new bug work item is automatically created in the bug management project/workflow.

The original work item is linked to the new bug (using issue links like “is caused by” or “relates to”).

Optionally, update the status or add a comment to the original work item for traceability.

3. Visual Indicators
Clearly label the transition in your workflow diagram (e.g., “Escalate to Bug”).

Optionally, use a dedicated status like “Bug Identified” before triggering the transition, if you want to track these events more granularly.

4. Workflow Example
From “Build Broken” or “Blocked,” add a transition:
“Escalate to Bug Workflow” → [Automation triggers bug creation in bug workflow]

The original work item remains in its current status or moves to a holding status (e.g., “Awaiting Bug Fix”).

5. Team Communication
Document this process so team members know when and how to use the transition.

Train the team to use the transition whenever a bug is discovered that requires separate tracking.

Summary
Add a transition from key statuses to indicate escalation to bug management.

Automate bug creation and linking for seamless handoff.

Label transitions clearly and document the process for your team.

------------------

So when stepping into the automation creation step, I ran into where there is no awareness of the Bug work type, and when going into the interface for work types only Epic and Story are listed, which then triggers (by me) attempting to add task and bug because those are needed for the logic, but I run into where its actually CREATING NEW DUPLICATE work types instead of using whats in the project defaults.  

Stepping into the "Work Type Schemes" this same limited list of only Epic and Story is relflected as well, with no ability to extend it with the other types that can be seen when creating a new issue, and when interrogating Rovo to what is going on it comes back with what you saw in the attached screenshot of the attached with the final highlighted item which is 1) suprising 2) poor system prompt management by whoever is setting up rovo to allow it to flat out just bash what the user is paying for in the way it did. 

As I stated rovo keeps falling back to instructing over Jira Classic configuration patterns and no matter what I prompt with for giving it context that I'm in new jira cloud, continues to deliver instructions that do not map to this new user experience, and then when challenged falls back into the same poor user experience acknowledgements and not having access to full documentation for the "new cloud experience".

[Todd Grayson]

I don't think we're in the same product experience... 

[Todd Grayson]

Actually I got to where you are showing, I'll see if I can get the instruction flow working from here...

[Trudy Claspill]

I cannot really speak to your experience with Rovo. The general steps you shared with us from Rovo appear valid, given that I don't know the questions you asked it.

I can continue to try to help you with the problem you were trying to solve when you asked Rovo for guidance.

In order to help you with that problem I need to know the type of the project/space where you are trying to implement those changes. This is a prerequisite to being able to provide you with advice that is applicable to your scenario.

You have asserted that the other work items types exist when you attempt to create an item. Would that be in the item creation dialog? If so, have you specified there the same project/space where you want to implement the changes?

If you have specified the correct project/space in the Space field and the Work Types are available in the Work Type list, then you should not have to add the work types to that project.

If you are not seeing the same work types when you are working on the Automation Rule, please let us know the following:

What have you specified as the Scope in the Rule Details for the rule? Does this identify the same project where you want to implement your changes?

Can you provide a screen image of he specific step in the rule where you are trying to select the missing work item type, showing how you are trying to specify that work item type so that we can see that it is not possible?

[Trudy Claspill]

I did not see your last screen images from Space Settings before posting my reply.

Based on that image you are in a Team-Managed project. In that case Work Item Type Schemes do not apply.

Let us know what questions come up next.

[Trudy Claspill]

@Todd Grayson 

If my responses have helped you resolve your problem please consider clicking the Accept Answer button above my first response. That will mark your Question as Solved.

If you still have question on this issue please let us know.

[Todd Grayson]

Thanks for your help, Trudy.

I'm product constrained here, below is the lengthy discussion that frames the limitations.  This is rovo based, but its clear (and correct) in whats its indicating, and it affirms my opening statement.  Here is question and answer after attempting to configure at the project level and why I'm seeing global configuraiton options but they can not be applied to my projects.

why am I seeing workflow settings in the global settings interface, can those not be mapped back into these space based projects? I don’t see anywhere I can create a classic project…

Is there a way to switch from team managed to company managed?

You’ve run into a real gap in the new Jira experience, and your confusion is totally justified.

You’re seeing global workflow settings because you’re a Jira admin and workflows still exist at the system level. But in the new space‑based Jira Software model (what ENG is using at https://synnepha.atlassian.net/jira/software/projects/ENG/list), those workflows:

• Cannot be mapped into these new “space projects”
• Do not appear anywhere in the space’s settings UI
• Are effectively only usable by classic / company‑managed projects

So:

• Yes, you can still define workflows globally.
• No, you currently cannot attach them to these new space‑based projects.

Why you can’t find “classic / company‑managed” project creation

In your site, Atlassian has effectively pivoted to the new “spaces” model for Jira Software. In many newer or simplified deployments:

• The “Create project” flow only gives you this new type of Jira Software “project in a space”.
• The older company‑managed (classic) projects option is:
  • Either not exposed at all, or
  • Hidden behind feature flags / plan level / migration state.

That’s why you’re not seeing:

• A toggle for Team-managed vs Company-managed during project creation
• Classic project settings such as:
  • Project settings → Workflows
  • Project settings → Screens, Field Configurations, etc.

In other words, in your current deployment, there is no supported way in the UI to spin up a classic company‑managed project, so there’s nowhere to “use” the global workflows you see.

Is there a way to switch from team‑managed to company‑managed?

In the new space‑based Jira model:

• You cannot convert an existing space‑based / team‑style project into a company‑managed project.
• There is no “switch type” button or migration toggle like:
  • Team‑managed → Company‑managed
  • Space‑based → Classic

Historically, even when both types existed side by side:

• The only supported pattern was:
  • Create a new company‑managed project.
  • Bulk move issues from the team‑managed project into the company‑managed one.
• Direct conversion was never supported, because the underlying configuration model is totally different.

In your current environment, the situation is stricter: you likely don’t have access to create company‑managed projects at all, so even that workaround isn’t available.

So what can you do right now?

Given the current constraints of your site:

1. Accept that space‑based projects use fixed / opinionated workflows
   • You configure columns and status mappings on the board.
   • But you don’t get:
     • Custom transitions
     • Per‑issue‑type workflows
     • Conditions / validators / post functions.
2. Use automation rules for some logic
   • While not a full replacement for workflows, project‑ or space‑level automation can:
     • Transition issues on specific field changes
     • Enforce some pseudo‑conditions (e.g., “if X isn’t filled, move back to Y”).
3. Keep an eye on Atlassian’s rollout
   • Atlassian is clearly mid‑transition between old and new models; it’s possible they’ll later:
     • Expose more configuration in spaces, or
     • Provide a new “advanced configuration” option that bridges the gap.

Why global workflows are still visible

The global admin experience is still “shared” across:

• Legacy classic projects (company‑managed) on your site or other products
• Potentially other products like Jira Work Management, etc.

So Atlassian hasn’t removed global workflow management even if:

• Your current Jira Software “spaces” don’t consume those workflows.
• You have no UI path to attach workflows to what you see as “projects”.

That’s why the global admin view and the space‑level view feel inconsistent.

[Trudy Claspill]

That information is not entirely correct.

Jira Cloud supports both Company Managed and Team Managed projects.

"Space" is simply a terminology change. There have been a few terminology changes. "Issues" are now "work items" and "Projects" are now "Spaces".

What Rovo is saying about there being a "space-based Jira" is wrong.

Jira App Admins can create both Company Managed (classic) and Team Managed project/spaces.

There is no method in Jira Cloud to prevent Jira app Admins from being able to create Company Managed Spaces. Since you can see the schemes you have the necessary access to create such projects.

It is true that it isn't possible to "toggle" a project from Company Managed to Team Managed, or vice versa. If you want to switch you have to create a new project of the desired type.

It sounds like you may not be familiar with Team Managed projects/spaces.

So, what do you want to focus on at this point?

We can work through how you can create a Company Managed project/space.

We can work through how you can make the desired changes in the Team Managed project you already have.

We can talk more about how any AI, including Rovo, can provide incorrect information, and how such information should always be checked against other resources.

[Todd Grayson]

Are you running within a standard or premium/enterprise license level?

I am familiar with team managed projects/spaces, and have worked in company managed project contexts before (and migrating everyone out of team managed and into atlassian professional services managed "company managed" deployments at the large enterprise level and all the gnashing of teeth that ensued). 

I'm locked in by the license level of standard to only being able to access the add spaces context.  Global settings does not let me change anything to handle this either.  

There is no "create new project" context in my menus, anywhere. I only have "Create new Space", even under customize sidebar there is nothing there that helps.

Note the elipse just takes me to manage spaces and create new space ends up on the same selection "Mode for you" page

Show me your menu context that offers it and your create new project screen, here is mine:

[Todd Grayson]

Trudy, I found it, it was a few configuration levels below that, the selection was not apparent when I went through it setting up the projects.  I've created a test project to validate I can get everything configured, thanks for pushing on the fact that Rovo lies like a dog.  

[Trudy Claspill]

Happy to help. Don't hesitate to ask more questions through this community. Better to ask than to feel like your beating your head against a wall.

Yes, the option to choose between creating a Team Managed vs. Company Managed project/space is not obvious.

And keep in mind again that the term "Spaces" in the UI is synonymous with what you think of as Projects. You will see both terms used in the UI and in documentation and throughout the posts in this community.

https://community.atlassian.com/forums/Jira-articles/Jira-Spaces-have-landed/ba-p/3117620