Why use Services in Jira Service Management instead of Components?

[Jake Laack]

I have a bunch of Jira experience under my belt, which is helpful since I'm setting up a new Jira Service Management ITSM project. I understand what Components are but now I'm not sure whether to use them or "Services" to organize issues on some of the big products we support (e.g., Box, Salesforce, Last Pass).

In the ITSM Project default Request Types, the Report a system problem uses Services for "Affected services" while Request a new Account uses Components for "Select a system". Now, we're not using a Platinum account, so we're not going to get any "Insights" on those Services nor are we using Opsgenie.

So, what reasons would I have to use Services instead of Components? I've been crawling through Atlassian docs and haven't found much helpful. Now, I'm hoping some other users might have some helpful experience with using Services.

[Walter Buggenhout]

Hi @Jake Laack,

If you mention the Atlassian docs on services, I assume you refer to the pages listed here: Manage your services. It is worth looking into as it explains more about the capabilities of services.

If you are on the free plan, services are just a catalog in your instance. And then I totally get you when you say you don't see much benefit over using components. Because both are - well - essentially a list of things you can use to categorise tickets.

Starting from the standard plan, though, you are getting status pages for your services and the relationship between services that you can configure. As soon as you get to that stage, these become useful already to analyse the (potential) impact on an incident. If you get a report from a user that he can't access VPN and you did link up the VPN service to other stuff that's depending on that to work, your first line agents immediately have an idea of what they may expect in terms of other problems. That does lead to connecting the dots when investigating problems that are not necessarily related at first sight.

Components will always be just a list of things to categorise stuff by. So - while useful - they will never add those extra possibilities as you grow.

I think there lies the big difference between the two. It's all a matter of adding value for the way you work. Probably your team is very small right now and you don't have that need for explicit service inventory yet. But let's hope it grows over time and when the need emerges, you'll be able to handle it. 

[Jake Laack]

Thanks for the reply, Walter. Yes, I have read through those pages. We have a company of about 200 people and we're planning to roll out Service Management to 30-40 people.

When you say "status pages", what do you mean? The only reference I've found to something like that are the "Insights" available to Platinum plans. We have not converted to the Standard plan yet, although I'm planning to within the week.

The biggest confusion for me is the apparent need to double up on Services and Components for "services" we might need to use in multiple places. For example, we use Salesforce. That should probably be a Service, right? We want to know if it's up or down. But, as I mentioned, the default Request a new Account Request type uses Components so maybe now it should be a Component? Or both?!

I realize that I could change that Request type to use Services instead of Components, but then my Service Management projects are using Services to identify Salesforce things and other Work Management or Software projects are using a Component - seems to complicate reporting.