Added value of the Portal where all Customers are also Agents

Question

Hi,

I'm running in to a client situation where I'm pondering what the right approach would be.

The Department that is currently using Jira (DC and no plans to move to Cloud) are all Agents.

There are no real external customers (except for a handful users that call to log an Incident) and everything that is handled (Incidents/Requests (and especially Changes)) are all created by the Agents and handled by the same or other Agents.

We're talking real Infrastructure changes, things like  Firewall adaptations, Server setup and maintenance, Network changes, .. all those things where a true customer/end-user has no hand in.

Because of that we're running in to some resistance to using the portal. The agents would need to jump back and forth all the time to create something and then (most often) handle it themselves. Hence the added value of the portal is almost non-existent and even becoming a hassle.

The main reason to use it would be to allow custom entry forms for specific changes.I'm personally not a fan of setting up specific issue types for each type of Change/Request but without the possibility to have more than 1 create/view screen per issue type (that is then dynamically loaded) we're stuck using  a lot of Behaviors.

Does anybody here face the same challenge? Some tips/tricks that I could use or how would you handle such a case?

All input is welcome!

John Funk · Answer

Well, that makes sense if you have that many different issue types and the forms are that different from each other.

But then again, why not leverage the forms, and then create automation to clone the ticket into a Jira Software project, and let them work out of that? You auto close the JSM ticket and set a notification to the reporter from the JSW project. We do a lot of that.

PD Sheehan · Answer

We have a mix of incidents/request types that are either fully customer-facing (traditional) or internal like you describe.

We go the scriptrunner behaviour route.

We have a single issue type "Technical Service Request" with a single workflow etc. 
But the first field in the create screen is:  "Type of Request" (single select).
This controls which field or even tabs is visible (or even required) using a scripted behaviour.

I suppose you could still have the portal request types based on the single issue type and use that as the driver for the behaviours.

I wrote the behaviour script such that I can easily add a new "type of request" and configure which fields are visible/required. But you could get fancier and store this data in Insight making it completely data-driven.

You wrote "stuck with LOTS of behaviors"... if you have a single issue type (or just a few if you have some workflow needs) you can map a single behavior to those issue types with a  single field (the select field that drives the logic) that points to a single script (I prefer files so I can use version control). That's not so bad from a maintenance perspective.

Dirk Ronsmans · Answer

Hey @John Funk ,

That's actually what they have been doing for the last couple of years.

The current set up is about 20-30 issue types in which they can enter their information. To make a bit more structured/service-minded approach we are looking to implement a more standardized system of processes (Incident/Change/Service Request).

Otherwise we'll just be adding and adding to the list of issue types which is just a an administration nightmare

The disadvantage to that is that you can only have a single create screen. The portal fixes that by throwing the request type form in front of it.

Our alternative is to create our 3 main issue types (Incident/SR and Change and use behaviours to hide/show the proper fields (for a certain standard change/service)

Queues are indeed use to handle the work once it enters the system, it's the entering part that is rather tricky.

Also because there are certain specific (automated) flow behind certain issue types but, these issue types are actually standard changes which I feel we would need to handle in a different way.. (currently I'm considering using subtasks instead of workflow statusses)