Business Space limitations and Service Space lock down issues?

[Paul Cutrer]

We are moving from a Business Space (Team-Managed) to a Service Space (Company-Managed) space because of the lack of ability to make individual Sub-Tasks and control the workflows and hierarchy of the space. If I need to work with another space that is not Service spaces, will it limit the automation that I would need to do between a service and business space?

I have admin permissions within the Service space; however, I do not have the ability to edit Request Types, Workflows, Work Item types, and Schemes. I also do not have the ability to use Automation with the space.

Is this something that our IT team can open up from the global settings or do you need global Jira admin permissions to manage all these options within the company-managed service space?

If I am editing the schemes that are tied to that space does that affect global or other spaces?

What is the easiest fix to manipulating team-managed or company-managed spaces to get the most out of operational tickets, forms, screens, and sub-tasks without having to create a task for every little thing that is needed when attending to break-fix operations? 

[Trudy Claspill]

Hello @Paul Cutrer 

Welcome to the Atlassian community.

This sounds backwards.

You said you are moving from a Business Space (Team-Managed) because of the lack of ability to

1. make individual sub-tasks
2. control the workflow
3. control the hierarchy of the space

Can you clarify what you mean by #1? In a Team Managed project you can make subtask type work items if the Subtask work item type is part of the Space. If it is not currently part of the Space, a user with Administrator access for the Space can add it. The limitation is you cannot have multiple types of Subtask type work items. You cannot have, for example, a work item at the Subtask level named Bug Subtask and another work item at the Subtask level named Test Subtask.

For the second item, in a Team Managed space a user with the Administrator role can most definitely control the workflow. Can you elaborate on the problem you face in that regard?

For the third item can you elaborate also on the problem you are facing? In a Team managed project only the native 3 work item type hierarchy levels are supported; Epic > standard work item types > Subtask.

Regarding switching to a Service space Company Managed

I have admin permissions within the Service space; however, I do not have the ability to edit Request Types, Workflows, Work Item types, and Schemes. I also do not have the ability to use Automation with the space.

Work item types and Schemes are managed only by Jira Administrators for Company Managed spaces. Users who are Administrators on for the Space will not be able to manage those configurations.

Workflows can be managed by individuals granted the Edit Workflow permission within the Permission Scheme applied to the space, but there are limitations. One limitation is that permission does not work as intended in Service projects at this time..

Regarding creation of Automations within a space, that has nothing to do with the Space type. By default Jira Admins can create and manage Automation rules. They can optionally grant that to Space Administrators. If you are not able to manage Automation Rules within your Space you would need to talk to your Jira Administrators about getting that permission.

Regarding management of Request Types, what happens when you try to manage request types? Are you not able to access the Request Types screen? Do you get a message of some sort?

If I am editing the schemes that are tied to that space does that affect global or other spaces?

Yes, for Company Managed projects  because schemes can be shared among multiple spaces editing the schemes used by one space may affect others. That is why the Team Managed space option is available - so that customizations can be limited to the one space and can be managed by the administrators of that space without affecting other spaces.

What is the easiest fix to manipulating team-managed or company-managed spaces to get the most out of operational tickets, forms, screens, and sub-tasks without having to create a task for every little thing that is needed when attending to break-fix operations? 

The answer to that first depends on who needs to have the permission to manipulate the space configuration, what types of manipulations are needed, and what your definition of "a task for every little thing" is.

If you, as a Space Administrator, need to be able to manipulate the space configuration without getting assistance from a Jira Administrator, then you will need to use a Team-managed space. Whether you need a Business, Software, or Service type of space would require more details about the work you need to track in the space.

The Team-managed and Company-managed spaces do not support all the same customization options; i.e. Team-managed spaces can have only one work item type at the subtask level, but Company-managed spaces can have multiples. So additional information would be needed about your customization requirements to determine which space type would best suit your needs.

[Paul Cutrer]

Hi @Trudy Claspill  - Thank you for the reply! I greatly appreciate it!

Can you clarify what you mean by #1? In a Team Managed project you can make subtask type work items if the Subtask work item type is part of the Space. If it is not currently part of the Space, a user with Administrator access for the Space can add it. The limitation is you cannot have multiple types of Subtask type work items. You cannot have, for example, a work item at the Subtask level named Bug Subtask and another work item at the Subtask level named Test Subtask.

We are an operations team that gets "Work Order Requests", the idea here in the change was to have the ability to make a general parent Work Order that then has the ability to have multiple different sub-tasks built in with forms and screens. This would give us the ability to have all the individual sub-tasks captured and directed based on locations and tasks within the team structure. I was trying to avoid a bunch of unrelated stories or tasks built out. We would at some point in the near future have SLAs implemented. From my understanding this is not available outside of a service company-managed space.

Regarding creation of Automations within a space, that has nothing to do with the Space type. By default Jira Admins can create and manage Automation rules. They can optionally grant that to Space Administrators. If you are not able to manage Automation Rules within your Space you would need to talk to your Jira Administrators about getting that permission.

From past experience label or button automation to auto create a work order to another space with auto comments and closure is not available outside of a company-managed space, is this still the case?

Yes, for Company Managed projects  because schemes can be shared among multiple spaces editing the schemes used by one space may affect others. That is why the Team Managed space option is available - so that customizations can be limited to the one space and can be managed by the administrators of that space without affecting other spaces.

When I reference schemes, I am specifically talking about schemes that have the direct space name associated with the scheme. 

The answer to that first depends on who needs to have the permission to manipulate the space configuration, what types of manipulations are needed, and what your definition of "a task for every little thing" is.

If you, as a Space Administrator, need to be able to manipulate the space configuration without getting assistance from a Jira Administrator, then you will need to use a Team-managed space. Whether you need a Business, Software, or Service type of space would require more details about the work you need to track in the space.

The Team-managed and Company-managed spaces do not support all the same customization options; i.e. Team-managed spaces can have only one work item type at the subtask level, but Company-managed spaces can have multiples. So additional information would be needed about your customization requirements to determine which space type would best suit your needs.

We created a test Team-Managed service space and the options for the space are very limited, is there ways to correct this? By limited here is the options.

1. Details
2. Access
   1. Customer permissions
3. Request management
   1. Forms
   2. Fields
4. Rovo Service
5. Rovo Ops
6. Apps

With the direction within operations and the amount of work orders we get with so many different options needed to redirect I worry the Team-Managed space is not going to scale with the growth, especially if we need to implement SLAs. If most teams can stay on the team-managed spaces and works with their need and I can add automation to their issues to auto cut and assign orders on our end, then we are ahead of the curve.

In the past the way we needed to build out our operations Jira deployments there was a lot of granulated tasks that needed to be created and when all the small procurement, RMA, asset tracking, asset moving, processing request come in I want to make sure we build this correctly. I have open ears and desire if the community can help me solve these issues without having to move over to a company-managed space and ask for the Jira global permissions to build the site.

[Trudy Claspill]

Hello Paul,

I'm going to start with some of the shorter responses.

When I reference scheme...

It does not matter that the scheme name includes the space name. They may still be used with other projects. Schemes and their member artifacts can be edited only by Jira Admins.

Automation rules...

A space admin can create a rule that creates a work item in another space. The Create action is one of the few cross-project actions that a space admin can include in a single-space scoped rule.

Adding comments to an issue in another space or transitioning an item in another space are not actions that a space admin can include in a space scoped rule. 

Only Jira admins can create rules that include other cross-project functionality, such as having a comment added to an item in Space A trigger the addition of a comment or the transition of an item in Space B.

That doesn't have anything to do with whether the space is Team managed or Company managed.

I'm going to stop there for the moment and provide another reply to address the other items in your last response.

[Trudy Claspill]

With regard to the options you see in the Team Managed Service project I have two questions.

1. Have you confirmed that you have been grated a JSM Agent license? That is a separate application access role than the one you get to work with Software and Business spaces. If you don't have the Agent role granted to you that will affect what you can see in Service spaces.

2. Which template did you choose to create the Service Team Managed space?

[Trudy Claspill]

Hello again @Paul Cutrer 

Regarding this:

We are an operations team that gets "Work Order Requests", the idea here in the change was to have the ability to make a general parent Work Order that then has the ability to have multiple different sub-tasks built in with forms and screens. This would give us the ability to have all the individual sub-tasks captured and directed based on locations and tasks within the team structure. I was trying to avoid a bunch of unrelated stories or tasks built out. We would at some point in the near future have SLAs implemented. From my understanding this is not available outside of a service company-managed space.

Who are the users of the screens and forms of the subtasks? Are these going to be used by licensed Jira Users/JSM Agents? Do they need to be visible/accessible to customers through a customer portal?

An alternative to having multiple types of subtasks would be:

Upon receipt of the Work Order Request automatically create an Epic for that Work Order. Then use a variety of custom child items for the various tasks under that Epic-level Work Order. In a Team Managed space a Space admin can make more work types in the middle level and you can have different screens/fields associated to those.

Regarding SLA features those are available in both Company-managed and Team-managed Service spaces.

[Paul Cutrer]

Hi @Trudy Claspill 

Automation rules...

A space admin can create a rule that creates a work item in another space. The Create action is one of the few cross-project actions that a space admin can include in a single-space scoped rule.

Adding comments to an issue in another space or transitioning an item in another space are not actions that a space admin can include in a space scoped rule. 

Only Jira admins can create rules that include other cross-project functionality, such as having a comment added to an item in Space A trigger the addition of a comment or the transition of an item in Space B.

That doesn't have anything to do with whether the space is Team managed or Company managed.

This is good to know, I would have to research what to hand over to the IT team to help get that done but at least it can be done under the TM space.

1. Have you confirmed that you have been grated a JSM Agent license? That is a separate application access role than the one you get to work with Software and Business spaces. If you don't have the Agent role granted to you that will affect what you can see in Service spaces.

I do believe I have been granted an agent license, but this is good to know to go back and ask. Would this license need to be granted for both CM and TM service spaces?

2. Which template did you choose to create the Service Team Managed space?

It wasn't I that created the space, so I am not sure what template was used. In the TM Service space, you can have all the same options you would in a CM Service space?

Who are the users of the screens and forms of the subtasks? Are these going to be used by licensed Jira Users/JSM Agents? Do they need to be visible/accessible to customers through a customer portal?

It would be internal team members and other teams. There could be a time where there is a need to have an external support a ticket and these be visible through the portal.

An alternative to having multiple types of subtasks would be:

Upon receipt of the Work Order Request automatically create an Epic for that Work Order. Then use a variety of custom child items for the various tasks under that Epic-level Work Order. In a Team Managed space a Space admin can make more work types in the middle level and you can have different screens/fields associated to those.

This is what I was trying to avoid but if it is possible to have the ability to create separate workflows, screens and automation in the TM space than I am okay with doing this. Would we still need to move from a business space to a service space?

I really appreciate your help through this.

[Trudy Claspill]

Hello Paul,

I do believe I have been granted an agent license, but this is good to know to go back and ask. Would this license need to be granted for both CM and TM service spaces?

The Agent license is granted at the app level, and is needed to be an agent for either Team or Company managed spaces.

In addition you need to be added to the Service Desk Team role in the specific Service spaces. Being in the Administrator role in the space does not necessarily automatically mean you are also an Agent for that specific space.

It wasn't I that created the space, so I am not sure what template was used. In the TM Service space, you can have all the same options you would in a CM Service space?

It is important to know which template was selected. In the past not all Service templates could be used to make both Company and Team managed spaces. For some templates only one or the other could be made. And different templates may provide different options. And there may be some differences in features depending if a Team or a Company managed space was created.

It would be internal team members and other teams. There could be a time where there is a need to have an external support a ticket and these be visible through the portal.

Be advised that it currently is not possible to show subtask type items through customer portals, because a Request Type cannot be associated with a subtask item type.

Would we still need to move from a business space to a service space?

This depends on the features you want.

1. The native SLA features are available only in Service spaces. But there are third party apps for adding SLAs to non-Service Spaces.
2. Native Customer portals are available only in Service spaces.
3. Native Queues are available only for Service spaces
   
4. Native Customer Satisfaction Surveys are available only for Service spaces. But there are third party apps that can add that feature to non-Service spaces.

That is just a partial list.

The best project to suit your needs would require a deeper understanding of the business process, your stakeholders, your reporting needs, any licensing constraints you might have, etc.